This. Waterfall never worked for a reason. Humans and agents both need to develop a first draft, then re-evaluate with the lessons learned and the structure that has evolved. It’s very very time consuming to plan a complex, working system up front. NASA has done it, for the moon landing. But we don’t have those resources, so we plan, build, evaluate, and repeat.
That "first draft" still has to start with a spec. Your only real choice is whether the spec is an actual part of project documentation with a human in the loop, or it's improvised on the spot within the AI's hidden thinking tokens. One of these choices is preferable to the other.
I agree, and personally I often start with a spec. However, I haven’t found it useful to make this very detailed. The best ROI I‘ve been getting is closing the loop as tightly as possible before starting work, through very elaborate test harnesses and invariants that help keeping the implementation simple.
I‘d rather spend 50% of my time on test setup, than 20% on a spec that will not work.
AI is also excellent at reverse engineering specs from existing code, so you can also ask it to reflect simple iterative changes to the code back into the spec, and use that to guide further development. That doesn't have much of an equivalent in the old Waterfall.
Yeah, if done right. In my experience, such a reimplementation is often lossy, if tests don’t enforce presence of all features and nonfunctional requirements. Maybe the primary value of the early versions is building up the test system, allowing an ideal implementation with that in place.
Or put this way: We’re brute forcing (nicer term: evolutionizing) the codebase to have a better structure. Evolutionary pressure (tests) needs to exist, so things move in a better direction.
What matters ultimately is the system achieves your goals. The clearer you can be about that the less the implementation detail actually matters.
For example; do you care if the UI has a purple theme or a blue one? Or if it's React or Vur. If you do that's part of your goals, if not it doesn't entirely matter if V1 is Blue and React, but V4 ends up Purple and Vue.
While writing the comment, I did think to myself, that NASA did a ton of prototypes to de-risk. They simulated the landing as close as they could possibly make it, on earth. So, probably not pure waterfall either. Maybe my comment was a bit too brusque in that regard.
Hehe. Well it's funny because years and years ago I made a similar comment to a person who I highly respected and had way more experience than me and he looked right at me and said, "No, waterfall does work." And it really made an impression on me.
But yeah, there's a point at which you have to ask where waterfall begins and agile ends in reality it's blurry. Prototyping is essentially in most nontrivial problems, so if you count prototyping as agile then shrug but ultimately it doesn't matter what we call it
Which one? The one in 1960s or the one which has just been delayed - again?
I think you can just as well develop a first spec and iterate on than coding up a solution, important is exploration and iteration - in this specific case.
Iterating on paper in my experience never captures the full complexity that is iteratively created by the new constraints of the code as it‘s being written.
