The usual adage among self-styled technical project management gurus is, “Good, Cheap, Fast — pick two.” This means that you can have something built well and quickly, but it won’t be cheap. Or you can have it cheap and fast, but it won’t be good. Or you can have it good and cheap, but it won’t be fast.
I’m here to say they still have it wrong. In reality–and this is the bane of all project estimations I have ever seen or heard about–you can only have ONE of those factors when you’re talking about software.
Say you want something done quickly and well. No problem, just expand the budget, right? It won’t be Cheap, but we still have Fast and Good, right? The people who say that never read The Mythical Man-Month. You can throw more programmers at a problem, but you quickly go from diminishing returns to negative returns. That’s right. More programmers can decrease quality and speed. The problem is information. If you have a process that can handle adding in more programmers, it will be by definition deliberate and slow, because the extra processes to accommodate getting information shared and collaboration managed among more people take more time. If they don’t take time, you’ll have less coordination and, hence, more bugs. That means less quality.
Say you want it cheap and good, but you can wait. Really? What are you waiting for? The Spirit to move you? Quality takes time and planning. At some point, someone has to pay for this time. So if you slow down and do it right, you aren’t necessarily saving money. It doesn’t matter if you’re building it in-house versus purchasing pre-built components (which usually have their own integration overhead), any time you deploy someone on a given task and not something else, that’s a cost. An opportunity cost, but a cost nonetheless. Being cheap necessarily means limiting the time spent on it.
This isn’t to say there aren’t things you can do to reduce costs, increase quality, or speed development. But it’s not a simple tradeoff of one against the other two that can be applied on a given project. Usually such improvements actually come across projects. Experience increases quality, reduces cost, and speeds things up. But experience can’t be ratcheted up on a project manager’s whim–because if nothing else, it’s usually the project manager’s experience that plays into the whole equation.
There are certain cases where you can buy a prebuilt component and save yourself time while increasing quality. There are certain cases where a little more non-overtime time will be cheaper while increasing quality. And, of course, you can sometimes drop features to get something out the door faster and keep quality on the remaining components (which is the same as increasing cost, since the remaining components cost more to build). But if you aren’t in these situations, the canard of process gurus will come back to bite you.
Note that the one thing I never mention is altering the quality (Good) part of the equation. You can absolutely trade off quality for cheaper and faster products–at least in the short run. In the long run, your clients will demand the quality anyway, or go to other vendors who have said quality, and you’ll have to improve the quality of your offerings to stay in business. Witness Microsoft’s recent work on security and stability over new features. Even though they offer their browser for free, their lunch is beginning to show red panda-shaped bite marks.
So just remember–the next time you intone that you can simply adjust the budget to get yourself the same quality in less time, prepare yourself for failure.
2 thoughts on “Good, Cheap, Fast–pick ONE”
That’s sorta like the addage for girls.
Pretty, Smart, and Sane. Pick two, but then settle for one.
Pingback: Kyle Hailey » DevOps Conundrum: Managing DB dependent development
Comments are closed.