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.
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.
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.
Your comment brings ripgrep to mind. Grep is about as ubiquitous a software tool as you can get with a very clear contract on input-output and it has absolutely stood the test of time. Then ripgrep comes along, it has the same contract as grep (with I think a few inconsistencies that were intentionally tweaked for modern use-cases...and also I'm sure a few edge-cases from its design), but is significantly faster. The fundamental contract with the user stayed the same, I'm sure some of the design changed, but fundamentally the only difference is the underlying code. And that makes such a big difference that I *always* use ripgrep over grep now as do many others.
That's just one half of it: Intelligent defaults + configurability of what files/dirs to skip. That part has been iterated on in prior tools like `ack` and `ag` and `git grep` for like a decade, and ripgrep was informed by that tradition.
The other part is extreme optimizations, from I/O and OS aspects to CPU, both asymptotic complexity (from scratch NFA regex engine), concrete complexity (rust, SIMD) and ad-hoc opitimizations for statistically common uses like fixed strings...
Then there are some "product" choices driven by performance insights, e.g. no line numbering, defaulting to non-deterministic unsorted output order — these go against most programmers' intuition for "ideal tool I'd like", but turns out the speed gains are significant and what I really like is how fast it is :-)
Both usability & optimizations are described in depth by the author in https://burntsushi.net/ripgrep/, which is one of the best perf. readings ever, highly recommended.
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.
I don’t think anybody except those working with e.g. DO-178B or ISO26262 does BDUF.
Iterative processes are state of the art. The RUP iterative lifecycle illustrates this nicely, with a big chunk of design in inception (first project phase), but also a non-trivial amount of implementation. The design & implementation flow in parallel in the next phases.
> Because if you ever go back a step, it is no longer the waterfall model
By this definition there has never been a waterfall project. They all need to correct, adapt, or redo something.
Look, I think I get your point but you seem too stuck in some formal definition riveted with assumptions to understand the other side. If you build a house you can correct some things after the fact. You forgot a power outlet or a light fixture? You need to move or resize a window? Probably fine and even decently low effort. You realize your foundation is too thin or too small? You forgot about one room? You put the bathroom on the wrong side of the house? Not so fine and definitely not low effort.
The state of software development is so bad because so many devs just jump head first into writing code and in the end they deliver a pile of barely held together shiny bits that technically works but is a pain to modify, extend, maintain, secure, extract the expected performance, etc. All because there are 100 brick layers and not one architect or engineer on the team.
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.