Driving engineers to an arbitrary date is a value destroying mistake (2020)

Alternate view point - driving projects to a specific deadline allows the other departments in the company to coordinate marketing, packaging, and selling the product. These people don't sit on their hands patiently waiting for engineers to finish building, their work can take many months just as the development does, and sometimes also involves making tradeoffs to deliver on time. No company wants to wait another year after development is finished before they start earning money for it.

The article is full with interesting nuggets of wisdom, but I found it all over the place, as it mixes several issues (all of them important) into one.

The article mentiones "high-value" projects (vs "low-value" projects), but the actual distinction made is between high-effort (new framework, new kind of product) and low-effort. Value and effort are not neccessarily correlated, indeed by the end of the article the team has had a high-effort project that resulted in a low-value product.

It also conflates product discovery (what will actually have value to the users) and technical discovery (how do we build the damn thing). It starts with the technical challenges (and I totally subscribe to the notion that estimating anything that you're not doing routinely is Dangerous, see https://blog.senko.net/bridges-vs-apps) but then veers off into describing mismatch between features built and value add (also a very important subject, but a different one).

I would love to see author expand each of the sections into an own article and explore these things in more depth!

The most underwhelming part for me are the recommendations at the conclusion. So (focusing here on tech aspects) if "Something by Date (tm)" methodology is bad (which I can agree with in principle), the solution to "let competent engineers prototype [the app] in 3 or 4 different frameworks", ie . "give your engineers unbounded time"? All developers (and I am one) wish they'd have more time to implement things properly, so that's not a new insight. But it's not actionable either - "give more time" then turns into "Something by Later Date (tm)", which is basically the same problem, just with more money (and thus stakes) involved.

I hoped to see an exploration into how to creatively solve for "can we deliver value" + "we have this budget and time" constraints.

There is also a difference between buggy for the first time, which tends to cause a user to dismiss the app, versus sometimes buggy after the app is well established as useful for the user. At that point, there is a different dynamic at play for competitors, they need to be perceived a significant percentage better than the incumbent to overcome and justify the effort of the user changing. I have no sources to back that up sorry, just something observed.

There is a counter intuitive thing about software project estimation that took a long time for me to discover.

The more rigorously you try to analyse the problem, cutting it into smaller and smaller parts, the more error you introduce, reducing the value of the estimate at each step.

Thus, the best practice is to give a very rough estimate based on the scale of the project and your past experiences.

If you don't have previous experience with similar projects, then you should not even try to estimate.

Chapter 11. Plan to Throw One Away

Chemical engineers learned long ago that a process that works in the laboratory cannot be implemented in a factory in only one step. An intermediate step called the pilot plant is necessary to give experience in scaling quantities up and in operating in nonprotective environments. For example, a laboratory process for desalting water will be tested in a pilot plant of 10,000 gallon/day capacity before being used for a 2,000,000 gallon/day community water system.

Programming system builders have also been exposed to this lesson, but it seems to have not yet been learned. Project after project designs a set of algorithms and then plunges into construction of customer-deliverable software on a schedule that demands delivery of the first thing built.

In most projects, the first system built is barely usable. It may be too slow, too big, awkward to use, or all three. There is no alternative but to start again, smarting but smarter, and build a redesigned version in which these problems are solved. The discard and redesign may be done in one lump, or it may be done piece-by-piece. But all large-system experience shows that it will be done.[2] Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time.

The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers. Seen this way, the answer is much clearer. Delivering that throwaway to customers buys time, but it does so only at the cost of agony for the user, distraction for the builders while they do the redesign, and a bad reputation for the product that the best redesign will find hard to live down.

Hence plan to throw one away; you will, anyhow.

-- Frederick Brooks, The Mythical Man-Month