Comment by devin
5 hours ago
I chuckle a little bit at this specification thing. We used to do this. We used to write big binders of specifications, and then we'd set about implementing them. We stopped doing it because it didn't really work. We'd learn things in the process of building which negated the value of the big specs we wrote. That's why we stopped doing it. This is where continuous improvement, CI/CD, tighter release cycles, etc. were all born.
But why? On reason is that implementation was a bottleneck. That made it expensive to change a system once it was entirely implemented. It was better to get the feedback sooner so you didn't waste time implementing the wrong thing.
The calculus on a lot of these old adages is changing.
I don't think this was only about implementation being the bottleneck. It was also because implementation forces you to think about the thing you're building at a very grannular level of detail, at which point you might discover flaws or opportunities that weren't obvious at the higher level.
And I find that, when it reasons through and encounters some of those, it just makes assumptions rather than asking the user.
That phrase, “once it was entirely implemented,” is doing a lot of work.
If you go back and read the literature on this stuff, one constant pattern is that technical leaders are constantly advocating for iterative development with frequent integration testing, and pushing back against management types’ impulse to favor giant up front over-specified design by committee plans. It’s not a phenomenon that’s unique to software, either,
But managers love meticulous up-front specification because it gives them the illusion of control and predictability. They are always being asked, “How much will it cost? How long will it take?”, and this approach gets you there.
I would argue that that’s the basic instinct behind meticulous up front specification for AI coding projects, too. It makes it easier to believe that, come implementation time, you can reliably one-shot it with an agent and have a working implementation that satisfies all design goals by next morning.
It is _still_ better to get the feedback sooner. Writing up some big specification, spending a bunch of tokens on implementation, and then shipping a massive PR to match the spec only to then find out it's wrong is a big waste of time. Nothing about writing grand plans in the face of unknown unknowns has changed.
The more things change, the more they stay the same.
Fred Brooks famously advised us to plan to throw one away. That was in the days of waterfall engineering.
The reason he said that is because the best way to learn how to properly build a complex system is by going through the process of building it. Sure, implementation is a bottleneck, but the real problem is that the experience of development is the best teacher.
Personally, I try to bring this lesson into my agentic coding practice by doing spikes and trial implementations first. This is where the AIs really deliver value: they can quickly build something out that touches a lot of the architecture so both it and I can get the proper shape of it. Only after that do I unleash it, constrained by what we learned.
Well, kind of. I think this is an interesting opinion on that: https://www.mountaingoatsoftware.com/agile/the-cost-of-chang...
Which could be summarised by a single line: "In other words, the primary cost of change increasingly becomes feedback delay, not development effort."
The problem with that was lack of iteration, not presence of specifications.
It is funny. At some point the code is the specification.
Remember when it was time to fire all the engineers because your business-analysts could just make UML diagrams?
If the code is the specification, then the only word on what the system is supposed to do is what it actually does.
When what it actually does is surprising, maybe you can make sense of it by asking the author what they were thinking. But that only works if the author is an entity that is both capable of thinking, and of remembering what it was thinking.
Yet software quality has been in deep dive for a while, long before AI.