For myself, I have found that the more detailed an estimate, the more detailed an "up front" plan. This is a classic pattern, and techniques like Waterfall and TDD rely on it. It's an extremely good way to get the costs and plan formalized (critical, in many organizations). Further, with TDD, this allows a very detailed and complete test matrix to be established, so the end quality can be quite high.

I worked this way for most of my career. One of the big reasons, is that I spent a lot of my career, writing software in support of hardware devices, and coordinating parallel development efforts was crucial. Lots of critical paths.

Also, hardware people tend to be very "waterfall-y," so I was often never given a choice.

As a result, we learned to give fairly accurate estimates, for pretty long-term projects.

The main problem with this approach, is that it delivers yesterday's technology, tomorrow. By the time the project is released, no one wants it. Also, it's quite possible to deliver features and algorithms that aren't useful, inherently flawed, or actually detrimental to the user's workflow.

Once it has been written into the lists, it is set in stone; even if it is found to be a mistake.

After leaving my last job, I started experimenting with more flexible development methodologies. I think I've had some success[0]-[4], but the scope of the projects has been much more humble than my previous works (out of necessity).

In the project that I'm developing now, there has been almost no "up front" plan at all, and no set schedule. I've been working on the frontend app (a native Swift iOS app) for over a year. The backend is a couple of servers that I wrote years ago. One has since become a standalone open-source initiative, run by a different team[5], and the other was one that I made as "practice," several years ago[6].

In developing the frontend, I created a TestFlight-ready app, almost immediately (I made my first TestFlight release about a month after I started coding). This has been a "running prototype," ever since. The entire team gets releases, quite quickly, and gives feedback and testing. Additionally, the app is continuously being vetted by Apple, so we are unlikely to have the "App Store Approval Brick Wall" problem.

This has allowed the specification to "morph," throughout the life of the project. I have actually thrown away months' worth of code, as we have decided to pivot direction, many times, throughout the lifecycle.

We're all very happy with where it's at, now. We are in the home stretch (but we still have at least a couple more months of work on the frontend app). It is almost entirely different from the original, unworkable, "idea man" concepts, that were presented to me, over a year ago.

I've also been doing this for free. I can't imagine any company that wanted to make money, doing it this way. I would have been forced to deliver a crap hack, six months ago.

[0] https://littlegreenviper.com/miscellany/thats-not-what-ships...

[1] https://littlegreenviper.com/miscellany/forensic-design-docu...

[2] https://littlegreenviper.com/various/evolutionary-design-spe...

[3] https://littlegreenviper.com/various/concrete-galoshes/

[4] https://littlegreenviper.com/various/testing-harness-vs-unit...

[5] https://bmlt.app

[6] https://riftvalleysoftware.com/work/open-source-projects/#ba...