So, you need to do all the coordination and communication up front, perfectly, so that you don't need to do coordination and communication later on? So what do you gain by this, you're just moving all the work to the start of the project, and you remove any margin of error. Ok, so what if the people were wrong at the start? Like mistakes will happen. Can't the team change in size during development, it's stuck in stone for years? What if requirements change? Can't people leave? Don't new employees need to do all that communicating when they replace the old ones?

Long answer here (again from Eskil Steenberg). Short answer… yes, there’s gonna be planning up front. We’re gonna need to solve the most important problem in software engineering ever, namely program decomposition (Ousterhout). We need to gather requirements, and think in advance about what is not yet known, what is likely to change, what requires prior investigation…

Note that many software components are fairly generic, and quite resistant to change. The more foundational you get, the more static and predictable things are. You can start working on those parts first, while you’re still designing the rest of the system. This is not Big Design Up Front. But let’s stop kidding ourselves, we do need some design up front. Or investigation up front: a prototype, mock, proof of concept… whatever you need to answer your important questions.

Can't the team change in size during development, it's stuck in stone for years?

If each component can be written by a single person, changing the size of the team is easy. And sure, if someone leaves you may have to rewrite their latest finished work entirely. Thankfully that’s not that much work to begin with, since they did it alone.

What if requirements change?

Don’t let them. Not always possible, but I see two main reasons for changes in requirements, both avoidable:

• Poor gathering. The requirements didn’t really change, our understanding of the requirements did. Sometimes properly gathering requirements is hard, but we should at least know what parts are uncertain, and what parts can be set in stone.
• No spine. Either from your sales team, which promises the Moon and then Mars and then Saturn, or from yourself whenever your hierarchy pretends changing things is easy and you don’t clearly tell them the change they’re asking for will cause unnecessary weeks and months of delay. Or just toxic companies who would fire you before listening to you, in which case I’m sorry. Still, we have more power than we know.

you promised to implement some API or functionality, you better follow those specs to the letter, with no user visible bugs and acceptable performance.

I'm not sure if you are writing a comedy bit. Is this a troll post?

I’m dead serious.

Ok, but what if an employee doesn't? Sure, you can punish them by firing them. But then what? How will the plan self correct for this?

Unfortunately I see no way around having competent people on top. Then juniors will need some guidance, we’ll need to check on the progress, maybe ask the less trusted members to lay out a plan and demonstrate short term progress (in the order of days or weeks)… You still need to give everyone as much autonomy as you can though.

The start of the project could be fairly naturally self correcting, simply by having several people discuss the architecture. Then when everyone works on their own little module, they can ask for help or even just advice. Seniors can review junior code, you could have people write test suites for the modules of their peers instead of just their own…

A developer working in a team, based on a design that they didn't approve of, but that they were ordered to perform

That’s your problem right there. With what I’m advocating there would be very little design beyond the interface boundaries. Which, if they are any good, would be much smaller than the module implementing them.

Even if the API is stupid, if you give me carte blanche about how to implement it I can generally do a very good job. I only collapse when you give me an existing program, and I need to fix horrible bugs while minimising my changes. (But boy do I collapse, I’m terrible at working with other people’s code.)

They may think they are able to deliver on time with no bugs, but shit happens.

Estimations are hard. I still suck at that. Still, you can minimise the amount of shit by sitting on a solid foundation, dependencies that work, are properly documented, and don’t change every month… But yeah, shit happens. Planning needs to account for that obviously. And as a dev, I’ve learned not to treat estimation as a promise to deliver. Now I often go like "should take 3 days, 2 if everything goes well, 6 if all goes to shit — I’m especially afraid of this and that part, you’ll have a more accurate estimate after one day of work."

Sure, in an ideal world, all of this is doable, if you hire like literally the best 100 programmers in the world, and pay them 1 million a year to motivate them. Otherwise, this all sounds like the fever dream of a psychotic megalomaniacal boss who expects perfection from underpaid and overworked employees.

To be honest, I have a feeling that our median output is unacceptably low quality. Management is often to blame, but more and more I question our own competence. I have a sense that better, much better, is possible, but that would require a serious rethink of our methods. We should set a minimum bar for ourselves. (Note that I don’t pretend to meet that particular minimum bar myself, but I don’t see why I shouldn’t either.)

Then comes the really hard part: education.