How to Work With a Contract Web Developer: The Better-Cheaper-Faster Myth

Once upon a time I was a young aerospace engineer working on NASA's Hubble Space Telescope project. A typical shuttle mission, if there is such a thing, took about three years to plan. Hundreds of companies, thousands of people, and billions of dollars were stirred up with a healthy dose of governmental help. All for a total of five or six work days during which over-qualified astronauts fixed the aging telescope.

A common truism repeated by engineers was "Good, Fast, Cheap - Pick Two." Of course, that common refrain was at odds with the official NASA slogan of "Better, Faster, Cheaper". As is often (but not always!) the case, the engineers were right. Attempts to reign in costs always failed as the consequences of cutbacks began to show themselves. Demands for quality were continuous and proper - we're talking about huge amounts of money, not to mention human life and national pride. Giving up "Good" was not an option. That left Fast or Cheap on the chopping block. What usually happened was some things got done fast and other tasks were done cheaply (by government standards, at least).

They were right about human space flight, not web applications. The NASA engineers neglected a fourth variable - scope. A space shuttle mission's scope is rigid. You must launch the payload and the astronauts must be able to fix the telescope. End of story.

That is not true for a web application. If a project costs too much, you can almost always drop a feature. If that makes the feature set insufficient, you can reduce the quality. If the quality is too low, increase the time. If it takes to long, you can pay for more developers.  So what should give? How do you address this balancing act?

In practice, some of these variables are easier to change than others. It is difficult to speed up development by adding money, for example. Software development just doesn't work that way. Real life budgets are usually constrained, as well.

Similarly, there is a minimum acceptable scope. It's been popular recently to call this the Minimum Viable Product, but that's pretty much buzz-word-speak for "the simplest product that will solve the problem it's aiming to solve."

Building a minimal product is not the same as building a low-quality product. If quality dips too low, maintenance costs more, future coding is slower and more expensive, and the overall user experience suffers from outages and other weirdness.

So we typically have a minimum scope, minimum time, maximum budget, and minimum quality level.

No project should ever be started unless all of those constraints are acceptable to both the principal and the contractor. If there isn't a viable sweet spot where everything works, someone is going to be disappointed. This requires discipline, careful thought, and an honest look at reality. Nothing is going to be ideal, so get that out of your head right now. Building software is about balance and tradeoffs. Not even truckloads of money can change that.

Coming Next: Agile is the New Average