The myth of software time estimations

The article treats software development as an unknown and dangerous terrain, so estimating completion dates is described as unrealistic. It links this uncertainty to the limits of predicting arbitrary programs, then argues that even careful teams face unpredictable problems, shifting requirements, and human factors.

Reading notes

#

• The text compares software development to crossing a dark forest without a map, where only the general direction is known.
• It states that estimating software development time accurately is an unrealistic expectation and a futile task.
• It relates this limitation to the impossibility of always predicting whether an arbitrary program will run forever or terminate.
• It says formal methods and provably correct programs are exceptions that are not widely practiced.
• It maintains that writing and maintaining code is a chaotic activity, subject to sudden and unpredictable problems.
• It reports that, in projects, the parts that take the most time are often underestimated or not even anticipated in the initial planning.
• It observes that users, multiple developers, human errors, management issues, and market changes increase unpredictability.
• It explains that time estimates exist because they are fashionable, because business and sales make future promises, and because many accept the practice as if the others were right.
• It says that even simple tasks can hide unforeseen issues that take weeks of work.
• It states that time estimates lead to cutting steps and producing software that is oversimplified for problems that later become more complex.
• It calls this complexity debt and describes the effect of having to extend basic interfaces and data models to handle more complex cases.
• It says that consistently accurate estimates may signal a broken product or a low-difficulty context, not necessarily a healthy process.
• It recommends using pure Kanban without time estimates.
• It argues for communicating that the company does not provide software development time estimates and considers this practice harmful to the process.
• It proposes using difficulty estimates without a commitment to a deadline, combined with elapsed time, number of users affected, value for the product, bug confirmation, and the importance of the affected users.