Estimate this!

As a software development agency, prospective clients will often ask for an estimate of how much time & money the custom software they want will cost.

Inside the software world, this debate is settled: estimates suck. In a group, this terse declaration is used as a sort of tribal banner to identify other developers of the same ilk.

I worry, however, that the community spends so much time reveling in estimate-bashing, that we’ve collectively gotten worse at explaining the trouble with estimates to software outsiders.

Can you estimate this for me?

Here are a few example responses to the question, “can you estimate this for me?” that are unlikely to close the deal:

• “We don’t do estimates, we do <Describe Other Activities>”, even when it’s unlikely to be clear how other activities are an adequate substitution for an estimate
• “Estimates put too much pressure on our developers”, as if clients are adversaries to protect oneself from
• “Sorry, but people who ask for estimates simply aren’t a good fit for <Insert Agency Name>”, disregarding the fact that most people have no idea why competent developers might refuse to give estimates

Responses like these are more likely to come off as pretentious than persuasive.

Some studio runners take pride in turning away anyone who so much as utters the “e”-word. Other firms jump at the chance to win any work, and eagerly provide (and even contractually commit to!) detailed estimates. Worst of all, some of the biggest players in the industry habitually lowball their estimates up front, with the intention of later employing their well-staffed legal departments to ensnare clients in a supremely profitable death by a thousand change requests.

The more responsible approach, it seems to me, is to make a best effort to educate prospective clients on the reasons behind our community’s collective distaste for estimation. After all, it requires a counter-intuitive realization to understand that specifying a complete system up-front actually increases—as opposed to decreases—a project’s overall risk of failure.

Have some empathy

Imagine yourself in the shoes of someone hoping to pay others to write an application on their behalf. They are embarking on an expensive venture to buy something intangible, made out of mysterious code they can’t comprehend, and from people who have them at a tremendous informational disadvantage. That’s a lot of unknowns!

If I were the one swimming in that sea of variables, I’d try to fix as many constants as I possibly could. If only I could convert the intangible aspects of purchasing software services into something tangible, then I would have greater control over the project’s success. Or so I might expect.

The vast majority of things people buy in their lifetime are physical goods, it’s hard to fault someone for trying to buy software services in the same way they’d go about remodeling their kitchen: design it up front, shop the plan around to a number of contractors, and choose the best proposal from a number of quotes. This approach makes sense when building physical things, because:

• Changing the design partway through will require rework and increase overall expense, so one can only benefit from starting with a complete and detailed plan
• Pitting contractors against one another to propose a price and schedule will externalize the buyer’s own expertise deficit, because the contractors will be under competitive pressure to minimize their price
• Contractors participate in a local, reputation-sensitive economy and will be incentivized to swallow any losses in the event that cost overruns exceed their quoted price (in the absence of changes requested by the client)

Any experienced developer will recognize that literally none of these conditions are true when buying software development services.

Nevertheless, it’s important to keep in mind that, in the real world, people who want to buy software services are usually under very real constraints: they might have a legitimately hard deadline, or users might demand a minimum set of functionality, or they might be under severe budget constraints. Only after spending the time to uncover and empathize with someone’s constraints can anyone begin to define an approach that’s appropriate for their situation.

It’s entirely reasonable for someone to naïvely start a conversation with a software studio under the presumption (or hope) that paying someone to write software will compare to paying someone to remodel a kitchen. Consequently, it’s our responsibility as professionals to do our best to articulate the dangers inherent in that assumption.

Articulating the dangers inherent in that assumption

Earlier, I mentioned that specifying a complete system up front actually adds to the project’s risk of failure. That risk is separate from but compounded by seeking fixed-price quotes from software developers based on estimates of a fixed scope.

One reason developers bristle at in-depth system specifications is because they prematurely solidify the whole team’s opinion of what “done” should look like, even though few finished applications ever resemble their initial designs upon completion. From an outsider’s perspective, the intangibility of software seems scary, but an insider will recognize that software’s inherent malleability can also be its greatest asset. If the team starts by building something very small, the highly-variable nature of software allows them to build incrementally in whichever direction seems best, allowing the eventual design of the system to emerge organically over time. While such an approach might see one’s kitchen remodel ultimately encroach well into the bathroom, it can confidently ensure a software system will never do more than it absolutely needs to do.

After all, why decide every detail at a project’s outset, the moment when we will have the least information available to us? While nailing down the details in advance might appear comforting from a risk management perspective, it has the deleterious side effect of dramatically diminishing the team’s empowerment to make future decisions that deviate from that initial plan. Future decisions are typically better-informed than today’s decisions, because they carry with them the benefit of the team’s concrete experience building the software and can incorporate the feedback from stakeholders based on actual interactions with the nascent application.

Moreover, when developers commit to an up-front estimate, it unnecessarily creates an adversarial relationship between the present-tense team who is best informed about the software versus the past-tense buyer initially promised a fixed cost, fixed-scope quantity. Negotiating over the financial impact of these inevitable deviations does not contribute to the success of the project, but does run the risk of destroying otherwise healthy working relationships.

Constraint-conscious development

For these reasons, a more sound strategy is to distill the initial expectations of the hypothetical application into a list of its desired outcomes. The team can then identify the simplest human and system activities that those outcomes will require. The goal of this activity is to set the bar for initial success so low that everyone involved can easily visualize stepping over it.

To keep the design simple while it remains in this abstract state, the entire team must be on-guard against specifying any detail unnecessarily. Of course, secondary decision points should be acknowledged as they materialize, but it’s best to defer them until a concrete implementation of the initial simple design has emerged.

But what if the prospective client and the developer fail to arrive at an approach simple enough to begin work with one another confidently?

As it happens, great developers employ a number of proven practices for building trust by reducing uncertainty and risk. They might:

• Work in the open. Deploy and demo working code frequently while keeping everything in a stable state. Should an unforeseen event prematurely end the project, the incomplete system is likely to be independently valuable (or, at worst, in a salvageable state)
• Minimize commitments. At the end of each week, give the client the opportunity to cut their losses and end the engagement if the team isn’t showing progress commensurate with their rates
• Find a common language. Run a 1-2 day paid “inception project” to break down the most important aspect of the application into an initial backlog of sufficiently small, technically viable units of work—all the while educating the client about their role as a product owner
• Aggressively address risky unknowns. Sometimes, a poorly understood aspect of the system that won’t be needed for weeks carries with it a valid risk of blowing the project’s budget out of the water. To avoid that outcome, pull forward focused research activities (“spikes”) to eliminate these unknowns toward the beginning of the project, before sunk costs can become too great
• Be a fantastic partner. Great development agencies openly exhibit a desire for close and honest collaboration with their clients. Their developers will have lots of experience coaching clients on the skills it takes to be a successful product owner

The goal of these practices is to put the client in a position to make informed decisions about each feature at the moment they’ll be best-equipped to do so: just before developers start implementing that feature.

Avoiding an impasse

For developers, it’s easy to scare off perfectly legitimate customers by shouting “we don’t give estimates!” It’s a little more difficult to realize that doing so has the side effect of limiting one’s list of potential clients to those who already understand why up-front specification and estimates are so problematic. That’s a relatively small market.

For prospective buyers, some will continue to insist—even after hearing all this out—on contracting at a fixed price for a fixed scope of work. After all, plenty of software consultancies are happy to contract under those terms. Sadly, what such a buyer is unlikely to realize is that they’re self-selecting for less-talented vendors, including potentially predatory ones. Agencies of highly-skilled developers are typically unwilling to contract on that basis because they understand that it leads to significantly worse outcomes for all parties involved. (To say nothing of the fact that premier agencies are in high enough demand to avoid signing such contracts.)

My hope is that we as developers will continue to hone our pitch about the dangers of up-front specification & estimation, while acknowledging that it will continue to be entirely reasonable for folks outside the software realm to initially request them.