Blogging AllianceDave GordonIT Best PracticesProject Management

Why #NoEstimates Is a Rough Finish for Your IT Career

I live in the American Southwest—the Mojave Desert, to be specific. We have massive areas of land covered with nearly identical homes, built in clusters called “developments.” The term is meaningful, because the builders aren’t just building houses; they are developing entire communities.

Complexity Lives at the Business Level

We have a well-established process: The organization with the right to build on a tract of land proposes a plan, which is reviewed by a planning commission. Approval usually comes with stipulations and concessions, from widening roads and funding storm drainage to possibly even contributing land for an elementary school. The developers then arrange for the site to be prepared, laying in utilities and streets, traffic signage and environmental controls. Then a specialty firm lays out and pours foundation pads for the planned houses, and at some point, carpenters come in to frame the houses. Other specialists put in the electrical and plumbing, tile the roofs and hang the windows and doors, stucco the exterior walls, drywall the interior, and install cabinets and countertops. These activities aren’t performed house-by-house, but a street at a time.

Estimates Are Table Stakes

Now, picture a carpenter who has been asked to bid on framing a group of houses. He replies that he can’t tell how long it will take, because his crew hasn’t built that model before. But if the home builder gives them, say, $400,000, they will work diligently, and when the money runs out, they can decide together whether to put more money into the construction. You’re probably thinking that the builder won’t ever do business with that carpenter, and neither will anyone else in town. But that’s because the carpenter isn’t an employee—he has competition. This helps explain why certain software developers think #NoEstimates is a fine idea—they don’t perceive that they have competition.

Coders often claim that they are bad at estimating, and so it is counterproductive to ask for them. Never mind that coding is only one piece of the effort to deliver a product. Never mind that the market waxes and wanes. Never mind that the organization has other potential uses for their capital. Never mind that other specialists will be called on at certain times to contribute their knowledge and skills, and they need to make their own work schedules. Never mind that marketing needs to begin well before there is a shippable product. None of that matters, because coders are only good at coding, and estimating is an unproductive distraction.

Your Future Probably Doesn’t Include Employment

There has been a remarkable shift over the last generation: There are fewer employees and more contingent workers in virtually every business, in virtually every market. Entire business functions have been outsourced. Few companies administer their own employee benefits or payroll. IT services are being taken over by global firms that simply “re-badge” the workers they want to retain. Apple manufactures nothing; they simply contract with hundreds of suppliers to have their designs turned into hardware. Software-as-a-service is replacing bespoke and even packaged software applications developed and maintained by internal resources.

As a contract project manager, I am an efficient competitor, negotiating favorable agreements with global firms that want to reduce their risks. They like doing business with me, because I speak the language of business, not project management. I give them a statement of work, with estimates, assumptions, stipulated roles and responsibilities, milestones, a specific change control process, and professional references. We understand each other, and they are willing to pay a premium for that level of understanding.

If you are a software developer or manager, contingent work is in your near future. Software development isn’t about coding; it’s a business function, like residential carpentry. You need to ask yourself: Who is my competition? And why would I lose to them? Then take some time away from learning the newest cool development tool to become viable as a contingent worker. Otherwise, you might end up standing in the parking lot at Home Depot, asking departing customers if they need some help for the day.


For more brilliant insights, check out Dave’s blog: The Practicing IT Project Manager

View the press release for his new book too: The Data Conversion Cycle

Show More


  1. Coders and many agile enthusiasts often overlook Dave’s statement:

    “Never mind that coding is only one piece of the effort to deliver a product.”

    Which is why agile and its associate concepts, like “no estimates”, only comes into play after an overall project is set up, general requirements established, architecture is defined, possibly some general design work is done, a general schedule and costs are defined and agreed to, the team is hired and trained, etc. All those things take time and require that the recipient/client agrees to some notion of “how long”, “how much”, and “what will I get”. A plan calling for “slinging code until it’s done” should not be acceptable.

    1. Well said, Gene. I asked a well-known Agile thought leader: “Who is responsible for organizational change management under Scrum?” The reply was, “The ScrumMaster.” My response:

      A Boy Scout Troop boards a plane for Denver. In mid-flight, the pilot has a heart attack. Who lands the plane? Answer: the co-pilot.

      A project plan has to include both internal and external dependencies, and participation by knowledge specialties that are not part of the core team. The #NoEstimates arguments proceed from a “Gilligan’s Island” world view – there are only the seven of us, and anyone else is at least an outsider and most likely a threat.

      Thanks for taking the time to comment!

  2. I think there is a fundamental misunderstanding of the #noestimates position. Using the framing a house example, would you ask a builder to estimate the number of nails he will use on each wall? Or would it be a better use of his time to estimate how many nails he will use on each floor instead? Asking a team to develop estimates at too detailed a level wastes time and creates churn.

Leave a Reply

Back to top button

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.