JavaScript Scene
Published in

JavaScript Scene

Demos Over Deadlines

Image: Smoke Art Cubes to Smoke — MattysFlicks — (CC BY 2.0)

Software Estimates Lie

Estimation Challenge

Why are software estimates usually wrong (commonly by orders of magnitude)?

  • Scope creep — new features were added, pushing out the ship date.
  • Undiscovered scope/complexity. Software development is an exploration. We’re doing something we’ve never done before and in the process we’re discovering new APIs, new protocols, engineering new components from scratch, and occasionally solving a problem that nobody has ever solved before. This is not trivial work, but when we estimate, we trivialize it. We almost always underestimate the scope and complexity of the problem.
  • Developers think about how long it will take them to implement something, not how long it will take to implement, test, integrate, deliver, fix, retest, and redeploy before it’s finally done. The difference in the two values is orders of magnitude.
  • Upstream/library vendor issues. Software developers often find bugs in the components they use and need to work with upstream developers to get the problems fixed — or fork the project and take on unplanned maintenance costs.
  • Life happens. Key people get sick, have accidents, get married, have babies, etc. There’s no planning for these things.

Why Estimate?

Customer Hired You on Contract

Investor Milestones

Planned Ship Dates

  • You have a well established relationship with the vendors you depend on and you’re certain they can deliver for you.
  • You have a well established process and a track record with great insights into the timing of the components that will go into the product. (This is very rare in software due to lack of repeatable production).
  • Design is complete or almost complete, allowing for most of the product scope to be already discovered and accounted for.
  • You have some flexibility and can cut scope to meet the deadline, even if the deadline was “next month” instead of “6 months from now”.

Brooks’s Law

“Adding manpower to a late software project makes it later.”

  1. New software developers require time to ramp up on any substantial application. Plan for 2–3 months before the developer can approach the average productivity of other members on the team. In the process of ramping up, new developers will have lots of questions about the project that only the early developers can answer, distracting your most productive people from their primary work on the project.
  2. New developers often make mistakes that developers more familiar with the project and each component’s requirements would not have made, leading to an increase in rework.
  3. Communication overhead increases exponentially with each new developer on the project, leading to a combinatorial explosion of communication complexity and reduced visibility. For example, each new developer might open several direct-messaging channels with other project developers. Developers may decide they need to break out into meetings to coordinate, opening up several new sub-group communication channels, and so on. The more developers you have on the team, the harder it is to coordinate work on that team.
  4. The hardest part of software development isn’t writing the code. It’s decomposing complex problems into individually solvable, smaller problems. It’s often very difficult to break a task down into smaller pieces that individual developers can work on safely without getting in each other’s way. As Brooks points out: “nine women can’t make a baby in one month.”
Real month-over-month progress graph.

“Nine women can’t make a baby in one month.”

Estimation Challenge: Solution

  • Are we talking about the number of bees who participate in a colony during the course of the total life of the colony?
  • The total for a full year?
  • The average number actually in a beehive at a particular point in time?
  • Are the numbers different for different geographies?

Discovering Hidden Complexity

Real software burn down chart. Dots represent the number of open issues at that point in time.
  • If you guessed a number less than that range, you lose. You’ve missed your deadline. Game over.
  • If you guessed a number above that range, your boss figures out your game (under promise, over deliver) and starts cutting your estimates in half for public product announcements. You miss a deadline set by the marketing team in response. You lose.
  • If you guessed a range and your top number is below 10k, you lose.
  • If you guessed a fixed number inside the range, subtract the difference between your guess and 45,000 and multiply by -1. That’s your score. Congratulations! You didn’t lose. But you didn’t exactly win, either.
  • If you guessed a range with both numbers in the range, congratulations! You get one point.
  • Demos over deadlines.
  • Control scope.
  • Set priorities.

Next Steps

  • Strategy
  • Team building, hiring, and onboarding
  • Cultivating healthy development culture
  • Effective software development process
  • Continuous discovery and continuous delivery
  • Managing software quality
  • Budgets and compensation
  • Conflict resolution
  • Technical debt



JavaScript, software leadership, software development, and related technologies.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store