Ultimately it's just a question of objectives. Usually software isn't written for its own sake. It's written to achieve a goal, meet a customer need, generate revenue, prove a market, etc. You can achieve those goals without gathering all the requirements, redesigning and re-implementing most of the time. Not in aerospace, or biomedical maybe, where we are willing to pay the outlandish velocity penalties. But most of the things we do aren't that.

Generally, if you want to build a pristine, perfect snowflake, a work of art, then you'll be the only one working on it, on your own time while listening to German electronica, in your house. [1] Nothing wrong with that - I have a few of those projects myself - but I think it's important to remember.

Linux is hoping to adjust the velocity-quality equilibrium a little closer to velocity, and a little further from quality. That's okay too. Linux doesn't have to be everything to everyone. It doesn't have to be flawless to meet the needs of any given person.

[1] https://www.stilldrinking.org/programming-sucks

> Not in aerospace, or biomedical maybe, where we are willing to pay the outlandish velocity penalties.

… because we really needed X version of software out yesterday? This incredible “velocity” that you speak of has created monstrous software systems, that are dependency nightmares, and are obtuse even for an expert to navigate across. In the rush to release, release, release, the tech sector has layered on layers of tech debt upon layers of tech debt, all while calling themselves “engineers”… There’s nothing to celebrate in the “velocity” of modern software except for someone hustling a dollar faster than someone else.

I for one enjoy the fact that AMD GPU drivers have been upstreamed.

Gathering requirements doesn't have to take months. It can take hours or a few days. You can even do it in the middle of maintaining a product, e.g. as part of steps towards addressing a feature request or a refactoring. It doesn't strike me as unreasonable that in the 50 years of building UNIX-style kernels, and the 30+ year development of Linux to have someone write down some functional requirements somewhere.

The software version of "There's always time to do it twice, but never time to do it right?"