And this is absolutely fine, because the problem with waterfall wasn't the detailed spec, it was

a) the mulyi-year lead time from starting the spec to getting a finished product

b) no (cheap) way to iterate or deliver outside the spec

Neither of these are a problem with SDD.

It seems to me that most people (myself included) never experienced the actual Waterfall elsewhere than in school curriculum descriptions.

It's a bit funny to see people describe a spec written in days (hours) and iterations lasting multiple weeks as "waterfall".

But these days I've already had people argue that barely stopping to think about a problem before starting to prompt a solution is "too tedious of a process".

	▲	yoz-y 8 hours ago \| parent \| next [-]
		To add to this: I've worked on projects that came out of waterfall process, and on projects that came out of too hasty agile iterations. They both have issues but they are very different. A waterfall project would have inscrutable structure and a large amount of "open doors" just in case a need of an extension at some place would materialize. Paradoxically this makes the code difficult to extend and debug because of overdone abstractions. Hasty agile code has too many TODOs with "put this hardcoded value in a parameter". It is usually easier to add small features but when coming to a major design flaw it can be easier to throw everything out. For UI code, AI seems to heavily tend towards the latter.
	▲	wiseowise 7 hours ago \| parent \| prev \| next [-]
		Preparation is waterfall!!! Just code without instructions, bruv!!! Documentation gets out of date quickly!!!
	▲	constantcrying 7 hours ago \| parent \| prev [-]
		I did professional waterfall development and SDD is exactly waterfall. The problem with waterfall was never the time that it took, it is that the spec locks you into a small niche and iterative changes force enormous complexity to keep spec and code consistent. The problems with waterfall come when much of the project is done and then you discover that your spec doesn't quite work, but the changes to your spec require half the requirements to subtly change, so that it can work at all. But then these subtle changes need to be reflected in code everywhere. Do this a couple of times (with LLM and without) and now your code and spec only superficially look like one another.

▲

laserlight 8 hours ago | parent | prev | next [-]

> the problem with waterfall wasn't the detailed spec

The detailed spec is exactly the problem with the waterfall development. The spec presumes that it is the solution, whereas Agile says “Heck, we don't even understand our problem well, let alone understanding a solution to it.”

Beginning with a detailed spec fast with an LLM already puts you into a complex solution space, which is difficult to navigate compared to a simpler solution space. Regardless of the iteration speed, waterfall is the method that puts you into a complex space. Agile is the one you begin with smaller spaces to arrive at a solution.

▲

4ndrewl 6 hours ago | parent | next [-]

It wasn't the spec - it was the inability to change the spec.

It's the ability to _change_ quickly (or be agile) in response to feedback that marks the difference.

▲

wiseowise 7 hours ago | parent | prev [-]

> whereas Agile says “Heck, we don't even understand our problem well, let alone understanding a solution to it.”

How can you even develop something if you don’t have a clear idea what you’re building?

▲

SideburnsOfDoom 7 hours ago | parent | next [-]

> How can you even develop something if you don’t have a clear idea what you’re building?

But, the statement "we don't even understand our problem well" is typically correct. In most cases where new software is started, the problem isn't well-defined, amenable to off-the-shelf solutions. And you will never know as little about the problem as you do on day one. Your knowledge will only grow.

It is more useful to acknowledge this reality and develop coping strategies than to persist in denial of it. At the time that the agile manifesto was written, the failure of "big up-front design" was becoming plainly evident. You think that you know the whole spec, and then it meets reality much as the Titanic met an iceberg.

Agile does not say "no design, no idea", it points out things that are more valuable than doomed attempts at "100% complete design and all the ideas before implementation". e.g. "while there is value in (comprehensive documentation, following a plan), we value (Working software, Responding to change) more. (see https://agilemanifesto.org/ )

In other words, start by doing enough design, and then some working software to flush out the flawed thinking in the design. And then iterate with feedback.

▲

mytailorisrich 7 hours ago | parent | prev [-]

You have am idea but typically you neither have a complete understanding nor a detailed view of the solution, and of course things tend to chanhe over time.

That's the key benefit of starting small and of iterating: it allows you to learn and to improve. You don't learn anything about your problem amd solution by writing a comprehensive design spec upfront.

	▲	wiseowise 7 hours ago \| parent [-]
		I have an idea to build payments processor, how does that get me any closer to actual payments processing?

▲

constantcrying 7 hours ago | parent | prev | next [-]

The spec is the problem.

The delay is just irrelevant. It has nothing to do with it working ot not.

>b) no (cheap) way to iterate or deliver outside the spec

You could always do this in a waterfall project. Just make whatever changes to the code and ship. The problem is the same for SDD, as soon as you want quick changes you have to abandon the spec. Iterating the spec and the code quickly is impossible for any kind of significant complex project.

Either the spec contains sufficient details to make implementation feasible and iteration times become long and the process of any change becomes tedious and complex or the spec is insufficient in describing the complexity of the project, which makes it insufficient to guide an LLM adequately.

There is a fundamental contradiction here, which LLMs can not resolve. People like SDD, for a exactly the reason Managers like waterfall.

▲

mytailorisrich 9 hours ago | parent | prev | next [-]

The detailed design spec is an issue hence Agile's "working code over comprehensive documentation". Your two points are consequences of this.

"Heavy documentation before coding" (article) is essentially a bad practice that Agile identified and proposed a remedy to.

Now the article is really about AI-driven development im which the AI agent is a "code monkey" that must be told precisely what to do. I think the interesting thing here will be do find the right balance... IMHO this works best when using LLMs only for small bits at a time instead of trying to specify the whole feature or product.

▲

4ndrewl 8 hours ago | parent [-]

It's often forgotten that the last part of the agile manifesto states that the eg 'comprehensive documentation' _is_ valuable.

The key to Agile isn't documentation - it's in the ability to change at speed (perhaps as markets change). Literally "agile".

This approach allows for that comprehensive documentation without sacrificing agility.

▲

mytailorisrich 8 hours ago | parent [-]

The Agile manifesto states exactly what I wrote. It's not that comprehensive documentation isn't valuable, it's that working software is more valuable.

In addition, the big issue is when the comprehensive documentation is written first (as in waterfall) because it delays working software and feedback on how well the design works. Bluntly, this does not work.

That's why I think it is best to feed LLMs small chunks of work at a time and to keep the humam dev in the driving see to quickly iterate and experiment, and to be able to easily reason with the AI-generated code (who will do maintenance?)

The article seems to miss many of those points.

IMHO a good start is to have the LLM prompt be a few lines at most and generate about 100 lines of code so you can read it and understand it quickly, tweak it, use it, repeat. Not even convinced you need to keep a record of the prompt at all.

	▲	skydhash 5 hours ago \| parent [-]
		> That's why I think it is best to feed LLMs small chunks of work at a time and to keep the humam dev in the driving see to quickly iterate and experiment, and to be able to easily reason with the AI-generated code REPL development and Live programming is similar to that. But when something works, it stays working. Even with the Edit-Compile-Run cycle, you can be very fast if the cycle is short enough (seconds). I see people going all in with LLMs (and wishing for very powerful machines) while ignoring other tools that could give better return on a 5 year old laptop.

▲

eric-burel 9 hours ago | parent | prev [-]

Yeah but can't we expect bureaucratic companies to adopt such a methodology exactly like that: write a spec for years, run the LLM agent every 6 months, blame techs for the bad result, iterate, and also forbid coding outside of the spec.