No they can’t do everything before writing a line of code. The design and requirements feed into the code and vice-versa over and over through the lifecycle of a piece of software.
Some architecture work and design will be done beforehand, but many details will fall into place as the code is being written, thrown away, adapted, etc.
The idea that code is mere transcription - which I see a lot in these AI discussions - is completely false. Code is a form of low-level design and is where the rubber hits the road.
The best requirements, designs, marketing, etc are worth jack if one fucks up the code. The code is the actual product.
> but many details
Which part of my list was just "a detail" to be dealt with at some point in the lifecycle (but only if you're not too busy shipping features) for you? You're laying bricks before knowing if the wall's supposed to be concrete.
> Code is a form of low-level design and is where the rubber hits the road.
Sure but in keeping with your analogy tires are fungible across most cars and it takes minutes to change one if you picked the wrong compound. It takes years to properly design a tire, not to speak of everything that sits on top of those tires. By the time you actually "meet the road" you already defined to a tee what you want to achieve from every perspective and everything you do is to meet that goal, even if you have to make tweaks. You don't find out if it's a scooter or a roadster tire while working on it.
> The best requirements, designs, marketing, etc are worth jack if one fucks up the code.
Why are you mixing some fundamental things which are essential and can't be changed along the way without massive effort and risk, if at all, with things like marketing?
Do you want to aimlessly write code while chasing a target that moves randomly and conflicting because your plan was to define things "at some point"? You're really making my point with your insistence that it's all about code and every other fundamental thing is "a detail" that just comes along the way.
In my experience, the parent's view and your view are an example of the divide between the Silicon Valley / startup mindset -- it doesn't need to last, it just needs to get us a paycheck so we can go on to the next paycheck -- and actual software engineering where people build resilient systems meant for humans to use for a long time.
There's a conflation too that to approach things with this level of thought and care requires waterfall design (it doesn't), so people shrug it off or resist because if you want to think carefully and design thoughtfully you can't also Move Fast and Break Things.
Ironically, we all complain about enshittification.
No part of your list was just a detail, but all parts of the list consist of essential properties and details. As I said, many of those details will fall into place when one starts implementing the core architecture.
It also matters a lot what scale one is operating at. Bigger scale will require more effort up front, PoCs, several big iterations, etc.
To give a smaller scale example, I defined a general simple protocol for two local components, picked the IPC and defined the handshake and teardown sequence. The developer defined the message contents. Reviewed together, then it was implemented. Testing showed that component B, which was OSS and had a fixed rate was sending too fast so the developer patched it to do debouncing.
Coding is nothing like changing tires. To abuse an incorrect analogy even more, the architect would prescribe the properties of the tire or even the behaviour of the vehicle and the developer would design and construct the tires/tracks/whatever either from existing parts or from scratch. Possibly going back and forth on the actual means of locomotion.
To wrap it up. Requirements, architecture and design can be changed. When implementing features I always do architecture review with the team and adapt it based on their feedback. We have rejected or negotiated requirements based on PoC or just developer evaluation.
Sometimes that doesn’t work, sure. If it’s a critical feature or there are hard architectural restrictions one puts in the dev work to figure it out and maybe this leads to a non-ideal implementation. Fundamental mistakes at requirements or architecture level do have higher impact, but iterating and having a good arch <-> dev feedback loop is one of the best methods I know to tackle that.
To give another example, I investigated the potential implementations for a feature and prepared a list of technical approaches sorted by specific architectural attributes. The dev team wrote the code to validate them and option 1 turned out to be impossible because of platform constraints. I adjusted the architecture to use option 2.
How does not everyone understand this? It's why waterfall development never worked.