Big Swinging Developer

Options, Options, Options!

There are almost no advantages to being the son of a world renowned economist. One thing that keeps it from being a total wash, however, is that I got introduced to the concept of optionality at an early age. I honestly don’t remember when I became aware of it, although I can remember thinking the term “synthetic puts” sounded cool when I was 12 or so.  Even though I didn’t understand the underlying math until much later, I grew up with at least a subconscious realization that the ability to choose was worth something.

In my early 20s, I started trading stock options online.

I was horrible at it. 

I was buying options, which meant I was paying someone for the ability to make a choice. 

I was in my early 20s, which meant that I made really bad choices. 

So there I was, paying someone to let me make bad choices.  I stopped in my mid 20s after I grew tired of losing money.  The concept of optionality stuck with me, however, and I’ve incorporated it into my approach to both software and clients. 

On the software side, this often means decoupling.  I don’t favor decoupling because it’s cool, I favor it because I’m wrong a lot and want to be able to fix my mistakes as quickly and easily as possible. Decoupling gives you options because it reduces the impact of changes, meaning that you can make more changes. Particularly in business software (and espectially in large enterprise systems), you can bet that change is coming.  Requirements change.  Systems that need to be integrated change.  Business processes change.  If your system can keep up with this change, it's a lot more valuable than one that can't.

On the client side, I sell a wide array of options and clients like it even if they don’t realize that that's what it is.  Instead of saying, “Here’s the deal: You pay me X and I’ll deliver Y” I almost always offer choices.  The actual choices aren't important here, the important thing is that no matter what they choose the work they need will get done.  Sometimes that means paying for my own hardware, software, hosting, etc.  Other times it means travelling to be on-site with them or their clients.  The point is, that by offering them the option(s) to do things their way, I get to charge a premium over someone who simply sells billable hours sitting in front of a screen.

If you can provide optionality that's valuable, you can sell it and collect the premium.

As a bookend to the previous mention of options trading, I returned to it recently for a bit (now in my mid-to-late 30s) and did pretty well.  The difference?  Instead of buying options, I sold them through credit spreads since I now realize that my value is in providing optionality rather than using it.

Reflector Recap (with Lessons Learned)

If you're unfamiliar with Reflector and its history, you can catch up in under a minute with the bulleted list in my previous post.  Since the announcement, I've read every tweet that had "redgate" in it.  I read the Red-Gate forum posts.  I read the links that are in the tweets and the forum posts.  And, I read all of the 132 comments that I received after offering to buy 10 licenses at $35 per (which Red-Gate then matched with 100 more and bumped them up to the $95 Pro version).

As I mentioned in the previous post, there is a lot of information surrounding this event that is valuable to any entrepreneur, executive, marketing person, or product manager.  Here are some of the lessons that I've learned from the experience:

Free Is Unlike Any Other Price

I had read that "free" is a unique price in Predictably Irrational by Dan Ariely, but there's a big difference between reading about it in a book and watching people freak out over it.  Almost all of the negative posts that I read centered around "Red-Gate said it would stay free and now it's not".  I'm guessing that there wouldn't be as much noise if the situation had been "Red-Gate said that it would stay affordable and now it's a little less so" . . . it just doesn't have the same punch, does it?  To be clear, I understand that "free" does have some unique properties: zero risk, zero acquisition friction, etc. and I'm not suggesting that people shouldn't feel they way they feel.  The lesson learned here is that "free" needs to be treated differently and that it's risky to price anything as free that can't stay that way.

All Information Gaps Will Be Filled

If you've read most of what's been written about this event, you'll notice 2 things about the information:

1. It's incomplete.
2. People will fill in the gaps with their own beliefs.

I read everything from "since Lutz got paid" and "Lutz may not have done the deal if it wasn't going to remain free" to "Reflector should go back to being open source" and  "Red-Gate installed a timebomb in it".  To the best of my knowledge, the details of the deal were never made public.  That means that unless you're Red-Gate or Lutz, you don't know the details.  As for the open sourceness and timebomb: Plenty of people have pointed out that it was never open source and the timebomb had been there for years before Red-Gate acquired it.  The lesson learned here is that any information gap will be filled by someone, at some point and that you might want to consider a defensive move of laying out relevant facts when it's time to announce an unpopular decision.

Non-Physical Products Are Different

People have a different view of non-physical products compared to physical products.  If you buy milk from the store, you don't expect it to last forever.  You know that it's an exhaustible resource that disappears as you use it.  As a physical object, it can't be 2 places at the same time.  Non-physical products have non of these limitations.  Because of this, limitations built into a non-physical product are often seen as taking something away from the end user.  DRM for music, games, and movies is a good example since it so clearly takes away capabilities from the non-physical product.  People hate DRM for a variety of reasons, but one of the most common is that it makes the non-physical product behave in unexpected ways.  All of a sudden you can't listen, play, or watch - not because your network connection went down but because someone made the media require a continuous connection.  That was a limitation that was consciously built into the product.  The timebomb in Reflector is similar.  Except for trial software, most people don't expect software to expire.  When the expiration comes, it's not only unexpected but it's clear that it was put there consciously which can lead to feelings of "you did this to me".  The lesson learned here is that if you're going to do something unexpected, make sure people are aware of it and consent to it in order to avoid an emotional response down the road.  As a point of clarity, "aware" means that they actually know what's going on which means it can't be buried in a EULA.

Developers Are Even Differenter

I lumped music, games, and movies together above when talking about non-physical products because they all have a similarity that separates them from software: most consumers can't create their equivalent.  Once you get into the realm of software, then things get a little stickier . . . all of a sudden you're talking about things that could be created by the end user, although it's often impractical for them to do so.  If you narrow things down to "developer utilities" then you're on really thin ice.  You are actually targeting a market segment that is often qualified to create the thing you're selling them.  Most of the time they'll be very rational about purchasing tools: "This will make me better.  It would take longer to create this myself then the price divided by my salary/rate.  I should buy this."  If something happens to suppress the rationality (like messing with "free"), then they can quickly go into "I don't care what it takes, I'll build it myself!" mode.  The lesson I learned is that when targeting developers as a market, it's important to avoid doing anything that might flip the rationality switch.

Conclusion

To cause the reaction we saw over the last two weeks, it's safe to say that Red-Gate made a mistake.  What's not clear is exactly where the mistake was made and what should have been done differently.  It's not clear because we don't have all of the information.  Don't let this opportunity go to waste, though.  There are some folks who paid steep tuition for the lessons that you can learn from this experience.

Think .NET Reflector Is No Longer Free? You Might Be Wrong...

There's been A LOT of discussion about Red-Gate's decision to start charging for .NET Reflector.  For those of you tuning in, here's a really compressed history:

• Lutz Roeder created .NET Reflector many years ago (full history: http://en.wikipedia.org/wiki/.NET_Reflector)
• I venture to guess that the majority of professional .NET developers use the tool.
• Red-Gate bought Reflector in 2008 (I remember because I saw Neil Davidson at the Business of Software Conference in Boston and asked him about it).
• Reflector has been free, or had a free version available for its life thusfar.
• Red-Gate announced yesterday that they'd start charging for Reflector in March with no free version available (as far as I can tell).  The price that replaces "free": $35.
• Lots of people are going apeshit about a tool that used to be free no longer being free.

That brings us up to speed.  For some fascinating reading, check out the Red-Gate Reflector Forum.  I'm being serious here.  It isn't often that you get to see so many diverse thoughts, opinions, and expressions of outrage in one place.  ANY marketing person, product manager, executive, or entrepreneur would be wise to read the forum posts and comments for a mixture of warnings, lessons, and insight into the community/customer mind.

For my part, I don't have a strong opinion about whether Red-Gate is right or wrong on this matter and that's actually not what this post is about.  This post (like many other posts) is about behavior and action.  While I can't make Reflector free for everyone, I figure I can make it free for 10 people.  I've made enough money doing development work and consulting while using Reflector that $350 seems like a reasonable price for me to pay.  At the same time, I know that there are lots of folks out there doing good work that can't pay $35.

Post a comment about why you want a copy of Reflector by Sunday, Februrary 6th.  I'll pick 10 and buy each a $35 license of Reflector 7 upon its release.

If Red-Gate (or anyone else) should decide to match the offer, then the freebies go up from there.

UPDATE: Just got off the phone with Red-Gate and they've offered to match with 50 licenses (I'm still paying for the first 10 so I now have a total of 60 to give away).  As such, I'm extending the deadline through Friday, February 11th.

FINAL UPDATE: I was pleasantly surprised when Red Gate initially offered the additional 50 licenses, but I was blown away when I talked to them again and they offered another 50 for a total of 100.  Not only that, but they said that rather than wait for V7 to be released that they are going to be giving Reflector Pro licenses (the $95 one), which will convert to the Reflector VS license when version 7 is released!   I'll be emailing the folks who get a license on Saturday 2/12 and Sunday 2/13.  Licenses should arrive on Monday 2/14 or Tuesday 2/15. Thanks to everyone who commented!  BTW, if you missed the cutoff I see that Dan Maharry is giving away Reflector 7 licenses on his blog.

The Difference Between Software, Platform, and Infrastructure in SaaS, PaaS, and IaaS

*-as-a-Service is all the rage these days.  Everywhere you turn you see Software-as-a-Service, Platform-as-a-Service, and Infrastructure-as-a-Service.  It reminds me of the late 90s when everything was Internet, Intranet, and Extranet - you know, back when it was so new and important that we capitalized the words.

Even though we're seeing some serious overuse, my problem isn't with the terms it's that the root words are incorrectly swapped around so much that folks have a hard time thinking about them correctly.  Sometimes everything is lumped into SaaS since it was first.  Other times Platform and Infrastructure are used synonymously.  My goal here isn't to introduce you to SaaS, PaaS, and IaaS . . . chances are you have an idea of what these are if you read this blog.  Instead, my goal is to show you a way to think about them to know what fits where including a 2-part value proposition of each.  This is especially important if you're building software that falls into one of these 3 groups.

Infrastructure-as-a-Service

Unless you work for Amazon, Rackspace, GoGrid, or one of the other big providers chances are good that you're not building IaaS.  Infrastructure is just that: the foundation where you run your system.  This service is all about providing you infrastructure components like servers and networking goodies such as load balancers, firewalls, and VPNs.  The "service" part of it is the management software that lets you click (or programmatically call) to provision new resources.  Click: new server.  Click: new network segment.  You get the idea.  The important takeaway here is that you are renting infrastructure that lets you do what you want, but it's pretty much up to you to make it do something valuable.  The 2-part value proposition of IaaS is that you can rent infrastructure instead of buying it and that someone who is better than you will be running it, provided you go with a quality provider.

Software-as-a-Service

At the other end of the spectrum, we have Software-as-a-Service.  SaaS should do something of value immediately after you sign up for it.  Sure, there may be some customization involved but the bulk of a valuable problem should be solved by the software that you're renting.  If you work for a software startup, then there's a good chance that you're working on a SaaS product or that there will be a SaaS version of your product offered in the near future (either by your company or a new competitor).  The SaaS 2-part value proposition is that you only have to pay for software you use and you have a solution to the problem that's better than what you can build in the time you have.  That last part is especially important since if you can't find something worthwhile to rent, then you've just stumbled upon a great market opportunity (or you're awful at using Google, but I'll give you the benefit of the doubt).

Platform-as-a-Service

This is actually the term that's been stuck in my head and led to this post.  PaaS should let you build something of value after signing up.  It's a step away from infrastructure in that you don't have to worry about the underlying servers and networking, but it's also a step from being SaaS because it doesn't do anything of general value until you get to work.  I think that a lot of the confusion around the term can be credited to the success of Salesforce.com.  They started as a SaaS offering and then created the first really successful PaaS offering (while continuing to offer plenty of SaaS goodness).  Their hosted Customer Relationship Management system is often cited as the first successful SaaS product.  Later they created Force.com which lets developers build new applications on top of their infrastructure.  Another factor that contributes to confusion about what constitutes PaaS is the use of the word "platform", one of the most nebulous terms in the tech industry.  I think that Architecture-as-a-Service may be a more accurate (though not necessarily better) description because what you're paying for is someone else's solutions to common development tasks. Instead of worrying about collecting data, storing it, retrieving it, searching for it, etc., you use the provided platform - its architecture.  The 2-part value proposition is that you can use the platform to build software without having to solve all of the problems common to software development.

To give a little perspective, I'm currently working on a PaaS system that will be used to create several SaaS products.  I'm using IaaS (Amazon EC2) for testing and production deployment.  So I rent from Amazon and others rent from me.  The spread between what I pay and what I charge is dependent upon my solutions to both development problems (the PaaS layer) and business problems (the SaaS apps).

The Accidental Architect (Part 2)

In the previous post I talked about software architecture and software architects in general.  In this post, I get into some specifics along with recommendations if you find yourself in a similar situation.  It is important to note that the advice that follows is for people who want to build good software in a good organization that supports your effort.  If you feel (or find) that you don't have the support necessary to get your architecture adopted, you may want to read Terrance Ryan's book Driving Technical Change

Have an opinion

If I could give only one piece of advice to a software architect it would be to have an opinion. Wishy-washy architects who speak vaguely in buzzword driven platitudes are the worst because they are inherently un-fixable. You can fix "wrong", but you can't fix "unclear".  Since there are so many possibilities with software the only way you can achieve clarity is through having an opinion and being able to describe/defend it. As an example, it was important to me that the system I designed be asynchronous from the beginning since I knew that we'd need to integrate with some slow external systems.  The opinion I formed is:

When the user clicks Save, their part is done.  The system should allow them to keep working and then notify them (if necessary) when the processing of their action is complete.

This led to a bunch of design decisions that wouldn't have been nearly as clear if I had a generic "the system needs to be fast" bullet point.

Be wrong early

You have your opinion and you start discussing it with others - your peers, your manager, your team, or whoever else will listen.  Be prepared to find out that you're wrong.  "Wrong" can come in a bunch of flavors: You've chosen a technology that's going to be difficult/impossible to get deployed, you've designed for a problem that doesn't exist, you failed to consider something that's critical.  The "be prepared" part means listening to feedback and watching reactions to find out that something could be wrong even if you're not being told exactly what.  It also means separating out general push-back from specific problems, especially from developers.  I once found myself in a surprising discussion with a developer over the design of my auditing strategy because he was worried that the database administrators wouldn't handle the data growth well.  Notice that that's a general fear that has less to do with the system (after all, auditing requires data growth by definition) and more to do with the environment.  We ended up keeping the design after discussing the various ways in which we could address data growth both with and without database administrator support.

Don't ship PowerPoint

If you're an architect, there is a strong possibility that you'll need to put your thoughts and designs into a slide deck to present to others.  This is a great exercise as long as you don't see it as your final deliverable.  The architecture I found myself designing needed to support several business units and perform a wide range of functions.  I had my opinions, I had my designs, but I didn't consider the architecture complete until I'd built at least a prototype.  In this case, that actually meant building the first module and I can tell you that things changed substantially from the time the paper design was done to the time we completed that module.  Even if you can't build an actual portion of the finished product, you should at least build a representative example of what you've designed and demonstrate that it exhibits the properties for which you've designed.

Know your environment

In the opening paragraph I noted that the advice was for people who wanted to build good software in a good organization.  If you're reading this blog, you probably have an idea of what "good software" is (i.e. meets user needs, can be extended, etc.), but you may not know what I mean by "good organization". The cornerstone of a good organization is honesty and most of the organizational problems I've encountered stem from a lack of honesty - anywhere from people kidding themselves to folks outright lying. In the context of development and architecture, you'll know you're in a good place if your opinions are met with open discussion and debate. It's surprisingly satisfying to have someone show you that you're wrong and then watch your design improve as you hash out a better solution together. You'll know you're in the wrong place if your opinions are met with silence, unproductive bickering, or passive aggressive avoidance. If you find yourself in such a place, then once again check out Driving Technical Change or dust off your resume and start to look around.  There are too many good places to let the bad ones grind you down.

The Accidental Architect

2 Years ago today, I wrote about centralized architecture groups in organizations.  A few months after I wrote that post, I was commissioned to write a whitepaper about enterprise architecture by a local boutique consulting firm.  The idea of software architects has been on my mind a lot lately.  While I've been selling myself as a Big Swinging Developer for the past several years, I recently found myself in an architect role accidentally.  I'll go into some specifics in the next post, but first I want to throw out some of my thoughts on software architecture in general and software architects in particular.

WTF is Software Architecture?

It's one of those terms that seems to mean something different every time you hear it.  In the realm of consulting it often translates to "the most expensive PowerPoint slides you've ever seen".  My personal definition is:

"software architecture is the collection of hard-to-change decisions about a system" 

Decisions like whether to use an ORM, or an Enterprise Service Bus, or how security is going to be handled.  These aren't impossible-to-change decisions, but if you've ever been on a project where something of this magnitude was either overlooked or chosen poorly, you know that this kind of mistake threatens to sink a system.

What Does an Architect Really Do?

That depends on two things: The individual and the organization.  The problem with the title "Software Architect" is that there isn't a strong connotation of what will be delivered.  A "Software Developer" better deliver software.  A "Graphic Designer" better deliver designs.  A "Software Architect", however, has no corresponding delivery requirements.  This is left largely to the individual and it's then often left to the organization to decide whether or not to tolerate what they do all day value the role.

In the past 5 years, I've been fortunate enough to work with the full spectrum of architects and the full spectrum of organizational attitude.  My favorite type of architect is one who has a good grasp of how software fits into an organization, the technical ability to address the challenges, and feels a responsibility for the success of the developers who will be implementing the vision.  Former colleague Mike was a great example of this.  He know his stuff, had strong opinions on the things that were important to him, and always provided a reference implementation to show that his design was practical.  My least favorite type of architect is one who generates nothing but documents (PowerPoint being a favorite), dictates "how things should be", and then blames the developers when the vision turns out to be impossible or useless or both. 

But architects don't exist without an environment in which to practice, which is why organizations are almost as accountable for architect quality as the individuals.  The quality of the environment is more easily determined by what it won't tolerate than by what it encourages.  Sure, you want a place that encourages quality work and personal accountability, but that's not enough.  What separates the good from the bad is that the bad organizations will tolerate (or even value) the Big Talkers who spend days preparing for a presentation without ever once vetting the practicality of what they're proposing.  You probably know who I'm talking about, the folks who will show you super-complicated diagrams of their Service Oriented Architecture but can't answer a single question about how to version or end-of-life any of the listed services.  Casting things into "good" and "bad" is a little simplistic, though.  There are really 3 types of environments:

The Consciously Good Organization

These are the folks who have their act together.  Somewhere along the way, they've committed to creating first-rate systems.  If you find yourself in an environment like this, they'll likely have a really good architect who you can learn a lot from.  If you're brought into to be an architect in this type of organization, you are being brought in explicitly for the role and you'll have a good idea of what it means to succeed.  There is money to be made in a consciously good organization since they tend to pay for quality, but note that the competition for the role will be fierce and you'll have to be really good to land the gig.

The Cluelessly Bad Organization

These are folks who want to be good, but don't know how.  Or maybe they don't even know that they want to be good, but they have a feeling that things could be better and are receptive to ideas on how to improve.  Honestly, this is my favorite type of environment.  There is a lot of money to be made in these types of organizations because they are often leaving so much of it on the table with bad systems.  Not only is the money good, but the work will be very pure in that you'll spend much of your time showing them how things can be better and then implementing it.  If you are correct in your analysis and solid in your implementation then your work will easily pay for itself and you can continue until you've built them into a sustainable technology powerhouse.

The Delusionally Bad Organization

This is the danger zone, because these folks think they're good but they aren't.  Remember when I mentioned that you can more easily determine the quality of the organization by what they tolerate?  This is where that little nugget comes in handy.  The delusionally bad organization does some things well (and will point them out as evidence that they're "good"), but they tolerate mediocrity to the point where the good stuff almost doesn't matter.  The way you can tell the delusional from the clueless is that the delusional will actually know a lot about what it means to design and build first-rate systems . . . but then they won't do it.  Instead of building good stuff, everything turns into a messy collection of compromises that's explained away by factors beyond their control.  The good news is that there's money to be made in this type of environment because they will, in fact, need help.  The bad news is that they will make you earn every freakin' penny of it.  The work isn't really the work, the work will be trying to get things done in an environment that thinks it's okay even while things are crumbling around them.  You'll suggest a way of doing something, get told that it's not necessary, and then see the negative effects of not having it . . . all before lunch.

Is an Architect Role Right For You?

As you might imagine, the job of software architect isn't for everyone.  One of the best programmers I know has no desire to be an architect even though he certainly has the technical qualifications.  So how do you know if the position is right for you?  I think that before even attempting the role, you need the following:

• Wide technical experience with some pockets of depth - you should be able to build everything yourself, even though you won't.
• Network operations or sysadmin experience.
• Defensible opinions on how software should be built.
• The ability to convey complex ideas in simple language.
• Ideas about how software and technology can make organizations more successful.

Have I missed any big ones?  If so, leave a message in the comments below!

 

 

The Developer & The Toy Store - Part 2

Have you ever played Battleship?  It's a game where 2 players put their ships on a grid and start guessing coordinates.  If you guess a coordinate where your opponent's ship is located, that counts as a hit.  Each ship takes up 3, 4, or 5 coordinates and once you've guessed all the coordinates of a ship, it's sunk.  The commercial when I was kid had the kid on the losing side exclaim, "You sunk my battleship!".  Good times, good times.

This is part 2 in a series.  If you have no idea why I'm talking about board games from the 1980's, start with Part 1.

Battleship taught me most of what I need for troubleshooting.  I have a bounded set of possibilities, I only get a certain number of attempts, and there's an uncomfortable period during each attempt when something bad may happen to me.  When playing Battleship, you can simply guess at random, or you can employ a directed strategy.  The same is true in troubleshooting.  If you're all over the place, sometimes you'll get lucky and sometimes you'll miss for what seems to be an eternity.

As you're implementing your search strategy, it possible to become too focused.  In the game, for example, it makes little sense to test a coordinate immediately adjacent to your previous guess since the ships are at least 3 units long.  Better to space out the testing and then "walk it in" by focusing in the surrounding area once you get a hit.  The same is true in troubleshooting.  If each test run is simply a close variation on the previous hypothesis, you're in for a long night.  If, however, you take a wider approach and test based on variations that are reasonably separated, you have a much better chance of getting a hit, and then you can hyper-focus on the surrounding areas.

I seem to recall that Battleship was never as much fun as I thought it should be.  When you think about it, there isn't all that much excitement and it doesn't have much to do with the Navy.  Troubleshooting: same story.  It's one of those things that you do that has its ups and downs, but overall you kind of wish you had done something else instead.

The point here is that when you're confronted by a troubleshooting problem, don't just fire at random and hope that you get a hit.  Approach it with a plan, execute, and as you get some success then focus on that area for all it's worth.

The Developer & The Toy Store - Part 1

I'm a big fan of analogies.  Analogies are the Swiss Army knife of the brain (note: I'm also a fan of recursion).  A good analogy gives you a clear mental model of something complicated.  This is the first in a series of posts that was inspired by a walk through a toy store where I saw some of my favorite childhood games and for each one thought, "Wow, that game is just like . . . " about some facet of my job.

Jenga

Jenga is a game where you start with a bunch of rectangular blocks stacked in an orderly manner into a tower.  The game progresses by each player pulling a block out of the structure and stacking it on top.  In this way the tower becomes taller and less stable over time.  Sound like any systems you know?

By day I specialize in brownfield development which is like walking into a Jenga game near the end.  Actually, it's like walking into a game where most, if not all, of the original players have left because no one wanted to touch the unstable mess in front of them.  In Jenga, the one who knocks the tower over loses.  There are 2 ways to knock the tower over: by pulling out the wrong piece or by putting the piece in the wrong place.  In other words you can lose by removing the wrong thing or adding the wrong thing.

So how do you play well?

To be a good Jenga player you need 2 things: An understanding of the tower's current state and a steady hand.  If you ever have the chance to play against a mechanical engineer, civil engineer, or architect (the real kind) then realize that you will most likely be playing on the basis of your steady hand.  These folks will look at the structure, see some crazy Beautiful Mind type equations floating around, and pull a piece that you'd never touch.  In the same vein, the more you understand about how your current system is built, the better off you'll be when it comes time to remove sections of it.

The steady hand in Jenga is analogous to the work habits of a solid developer.  If you're focused, consistent, and just a bit fearful, then you'll probably do better than someone who just adds stuff in willy-nilly.

To take the analogy beyond game play itself, if you do knock the tower over then what you do next is very important.  If you quickly reset the game to play again, chances are you get to play again.  If you look at the mess, say, "Sucks to be you!", and walk away then it's likely that no one will want to play with you ever again.  Also bad: losing a piece.  

In short: You can win by taking the time to understand things well, being careful, and cleaning up quickly when things fall apart.

What To Do When You F Up Big Time

This post will probably strike you as either common sense or absolute crazy talk.  It is especially written for those in the latter group.

I write a lot about working safely.  After lots of posts on branching, test environments, kitchen analogies, etc. I'm here to recommend some behaviors for those times when you totally screw up.  After all, you may very likely find yourself in an environment without all of the safety nets you want because you were specifically brought in to build the safety nets.  I'm going to assume that you messed up while doing the right thing in the wrong way rather than something criminally stupid like, say, encoding your DVD collection to Divx on the production database server because "it has those really fast drives and all that RAM".

First, and foremost, as soon as you realize that you've screwed up, let someone know.  Do not be tempted to keep things quiet and fix it before anyone notices.  I have yet to see a production issue that didn't get worse with time (and quickly).  Keeping things quiet is outright selfish because you're putting your own comfort ahead of the good of the group.

Secondly, fixing your mistake needs to become your top priority.  Fixing means not only getting things working again, but getting them back to the way they would have been.  Does data need to be re-keyed?  It's now your job to re-key it.  Do numbers need to be verified?  If you're not the one who can do it, be prepared to generate special reports or data dumps to make the job as easy as possible.

Next, take responsibility for your mistakes.  Full responsibility.  You don't get to say, "I deleted the production website, but the slow restore process is what caused the outage to be so long."  Being up the creek without a paddle means that you own the upstream and downstream problems as well.

After things are back to normal, do your own private After Action Review (note: there's a good chance you'll be asked for either a public one or one with your manager).  Take this opportunity to learn from what just happened while it's still fresh.  For a big enough mistake, you'll probably also reflect on it for a day or two.  Having said that, hear me now and believe me later: do not utter the words, "Well it's kind of lucky it happened because...".  Even if there's some fantastically beneficial outcome, you don't get to celebrate the effect, you are still responsible for the action.

Lastly, get over it.  If you've made the kind of mistake that I'm writing about, it will almost certainly affect you emotionally, mentally, and physically.  That's to be understood and will actually help with internalizing the "Don't do that again" lesson.  But don't let it affect you too much for too long or you'll kill your productivity.  If making a huge mistake makes you skittish to the point that you are no longer a high performing contributor, then things aren't back to normal are they?

As a final thought, while things are at their worst you may start wondering, "Are they going to fire me for this?"  I can't answer for certain, but I can tell you this:  When I had headcount, I never fired someone for making a mistake . . . and they pulled some doozies.  If you do get fired for a blunder that you feel comfortable defending (i.e. Doing the right thing the wrong way), then chances are it wasn't the place for you anyway.  The only way you can do truly incredible work is by being willing to take some risks and if your employer squashes any chance of that happening by firing people for mistakes, then you're better off elsewhere.  Just don't make a habit of it: it's easy to explain a one-off, but the second time you get fired for f'ing up big time it starts to look like a trend.

Brownfield Development: How To Peel The Onion Without The Tears

In the Spring of 2008, I decided to become a brownfield development specialist.  Greenfield development is when you're starting a project from scratch and get to design everything with only minimal constraints.  Brownfield development is the opposite of that: it's when a project is n months into development and most of the constraints have been cast in stone.  My guess is that if you were to ask every developer you know whether they'd prefer to work on a greenfield project or a brownfield project that they'd all say greenfield.  Heck, I'd bet that a quarter of them would laugh so hard that Red Bull shot out of their nose just at being asked the question.  Therein lies one of the secrets of becoming a Big Swinging Developer:

You can make money being good at things that other people hate to do.  A lot of money.

When people hate to do something, they don't do it very much.  Since they don't do much of it, they never get particularly good at it.  This makes it harder for them to do it and the cycle starts all over again.  Some common values of "it" for development include: writing tests, documentation, and creating installers.  You can safely add brownfield development to the list since a job description of "Support the big ball of mess that runs our business while adding features and fixing bugs" doesn't usually have folks banging down your door. Throw in the fact that you'll have no relevant documentation and few, if any, tests to guide your way and you can picture weeks of pestering your co-workers with questions just to get to the point where you can fix a simple defect.

But what if brownfield was easy for you? What if, rather than pestering your co-workers with basic questions, you could understand what the code was doing and then ask why it was doing things that way rather than asking what it actually does?  That's what my secret weapon, Visustin, gives you.  You paste in your source code and it'll generate a flowchart for you:

It supports 31 languages including the popular .NET, open source, and SQL variants.  I spent last week throwing hundreds of lines of Python into the tool and tracing through an incredibly complex financial trading system to learn how portfolio valuation is calculated.  I was able to correctly describe the process to my team lead, including a couple gotchas buried in the code even though I don't know Python.  Since I know how the system works, though, I can find the path the code will take and identify where problems are likely to occur while coming up to speed on the language at night.

If you're a developer, I'd highly recommend Visustin.  It's great for code reviews, documentation, and for diving into existing systems.  Developer or not, look around your industry and find the important things that no one wants to do because there's a real opportunity there.  You can become better (or more tolerant) than anyone else simply by identifying the key aspects to the unpleasantness and solving that problem first.