Building high quality software fast and cheap

James Currier at Ooga Labs posted a blog entry that starts as follows:

"I’ve heard people tell me “We can build product fast, good, or cheap.  You can’t have all three.  Pick two.”  I believe this is a corrosive mindset, used by bureaucrats to justify mediocrity, or used by people who are afraid of failure to set the bar low enough so they feel comfortable in their daily lives."

I disagree with James and think you can only lock down two on a large, complex software development project.  While it's possible to build good software fast and cheap, I think that happens only under certain circumstances where the engineering risk is inherently low.  Also, sometimes you get lucky and nail it - I've seen that happens a few times. Projects having any of these characteristics generally can be delivered fast, good, and cheap:

1.  Young code base (generally a few months of development or less)

2.  Small team size (generally 1 or 2 senior developers, sometimes up to 3 or 4 if things are going well)

3.  Relatively simple feature set

As you get to bigger teams with more complex software that takes longer to create, your risk goes up.

The underlying principle at work here is "shit happens" - sometimes an engineer quits or gets sick, or you discover a fatal flaw in a library you're relying on and you need to retool, or you discover that a feature doesn't work as designed and you need to redesign it, or the market changes and you have to react.  When such a thing happens, the bottom line is that it's usually going to take you more time to do what you wanted to do.

So let's say such a thing happens AND you hold all three values fixed.  You can deal with such unexpected events by building in a "slop factor" to your schedule, so you eat into your slop time.  But essentially what a slop factor does is pull in the release date by saying "we expect this much shit could happen".  So you really are slipping in a way so the "fast" part is actually varying.  Or you could ask your team for overtime - that's one option.  But that's really tweaking the "cheap" part because you are putting more time in - if you paid for that hourly, your cheap just went up.  You could shave your feature set and simplify things and still ship, but then you're tweaking the "good" part.

Sometimes bigger shit happens than you budgeted for with your slop factor- we all get constipated from time to time - and if that happens, then what?  It's naive to believe that big shit won't ever happen.  Then what, if you hold all three fixed?

I call these three values by different names that more closely connote the values being managed:

1.  Release date
2.  Features & Quality
3.  Resources (people and hardware/software)

My basic form of project risk management is to look at these three values as dials that you can twiddle or tweak at the beginning of each sprint.  So I've folded this form of risk management into the way I practice Agile project management, by constantly reassessing the feature set, team velocity and composition, how the product is shaping up, and the importance of the release date relative to other business priorities, which may be more fluid than we'd like.