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’ve often seen the reverse, that many of the best consumer products were fast, good and cheap to create. Those products were created by people who were very talented or very focused, and certainly none of them were dragging around this self limiting belief that you have to pick only two.
Ooga Labs 
Hi James, Do any examples or counter-examples come to mind?
Fast, Good and Cheap: Facebook, Twitter, Bebo, FourSquare, Groupon, MySpace, Fickr, PhotoBucket, Texas Hold ‘Em on FB (which lead to Zynga), (lil) Green Patch on FB (which launched the social gaming category and could have lead to Zynga), and then the Web 1.0 winners like CraigsList, Match.com, Monster, and eBay.
Slow, expensive and good: Amazon, Google, everything Apple, the F8 platform on FB.
Slow, expensive and crappy: most other stuff, like Zune, A9, all of KPCB’s stealth companies, all of EA’s attempts at social gaming on FB, LinkedIn (even though it won through lack of competition), all of Yahoo’s startup attempts in the last 3 years.
James,
You are comparing apples and oranges.
The common thread in your “Slow, Expensive, Good” examples is that there is more to the product/service (technical complexity, financial regs., logistics whatever) that what you see from a user’s standpoint.
The “Fast Cheap Good” is all WYSIWYG (mostly) and largely web/mobile applications that piggy-back on other infrastructure.
No excuses for the crappy stuff…
I would bet that something like SquareUp would take time to build given all the regulations and infrastructure that needs to be built. Some things can only be built so fast (good or crappy).
-Rajesh
It’s not the tech that’s the point of the post, it’s the means.
Bureaucrats justifying mediocracy. Place markers building their little empire. Mel Conway explained it in 1968.
I’m a scrum master. To me scrum is the only rational way to control chaotic projects; that’s software to you.
The good, fast and cheap is a natural consequence of scrum’s focus on ROI.
actually, i don’t think it’s impossible to build fast, good, AND cheap, however i DO think it’s difficult to prioritize all 3 at the same time (or even 2, really).
most things are built with only 1 of these as priorities, with possibly a 2nd constraint as a minimum rqmt. (ex: PayPal was pretty crappy at first, and was PRIMARILY built with an emphasis on viral distribution (Fast & Cheap), while maintaining basic functional use as a payment mechanism, and while limiting overall system fraud activity to a manageable % (not Good, but Good Enough).
thus, while Twitter is arguably fast, good, & cheap now, it certainly wasn’t great when it started, and it wasn’t very fast either (and not very reliable at all, as noted by almost everyone). it was built cheap & simple, and because it did it well *enough*, it was good (enough).
at the same time, most of Apple and Amazon products were built with GOOD as primary emphasis, and Cheap ENOUGH as the constraint… and perhaps some rqmts on speed, altho not clear they have as much focus there.
anyway, agreed that we shouldn’t let narrow-minded thinking rule the day when aiming for breakthrough products & services, but probably good to have a clear primary emphasis, along with secondary constraints.
my .02,
The original form of this dictum (used forever in the systems development world) is ‘Performance, Cost, Schedule – pick any two’.
Pingback: Heather Podcasts – Good, Fast, Cheap – Pick 2 (Episode 2) | Heather Villa
Well all these blanket statements are kind of generalizations but… I think the saying succeeds in articulating that there has to be a trade off at some point.
Nowadays, in the web, stuff is very “cheap” and you can do stuff very “fast” – of course, those are all extremely relative terms but I think most people can define what that means.
“Good” is a very hard statement to define – a lot of people would define “good” for a software product has having a lot of features. And generally, a lot of features takes more time. So you need to sacrifice time for features…..
I don’t really see how the saying is harmful, it articulates a important issue.
The same thing goes for food – Cheap, Healthy, Tasty – choose 2.
Or buying a house – Good Location, Cheap, or Nice/Large.
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)
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 on time, but then you’re tweaking the “good” part.
Sometimes bigger shit happens than you budgeted for with your slop factor or overtime – 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 I manage:
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.
James,
With all due respect, I do agree with the sentiment that limiting thinking can be, well, limiting; but I think the “fast good or cheap: pick 2” model, and your critique of it, are both simplifying the situation quite a bit.
Every single one of the “fast, good AND cheap” examples i think fails the “good” test on really objective grounds. It’s just that “good” is such an ambiguous word (kind of like the Jon Stewart skit about people saying Obama doesn’t have “it”).
All of your “fast good and cheap” examples made really dire trade-offs, and what they did, each of them, was paper over their trade-off decisions to the public, and internally to some extent as well (speaking from personal experience). I’m not saying it’s malicious, or wrong, it’s just that repeatedly trading “fast” for “good” is not the same as stating objective goals for “good” that are measured against and, whoa guess what, we weren’t as good as we thought. It’s the hubris issue that is prevalent in software engineering culture.
It’s understandable, because everyone has their own idea about what is important to be “good”. Pretty? Feature rich? Simple? Well-monitized? Highly available? Fast page load times? Someone can say “This is really good!” and everyone assumes their own interpretation of good is what the speaker meant.
Without getting too into specifics, the places I see this traded off in your examples really clearly are: availability, page load time, maintainability, transparency in understanding user behavior (ie quality analytics)… now if the movie Social Network was right, Zuckerberg really cares a lot about availability, and while FB does better than Friendster at its worst, I would not characterize FB as a performant or highly available site. Is it performant or available *enough for them* is the question, but my sense is that it would take too much time to figure that out, they’re trading fast for good in this way.
Granted these things are hard, really hard. Not taking the time to define a requirement clearly is a different thing than knowing the requirement was met. Your examples strike me as cases where the leaders of these companies uprooted the goal posts of the quality aspects to the game and planted them right next to wherever the ball was. Might be the right biz quality, but don’t expect a decent QA guy not to mention the behavior. 🙂