← Back to context

Comment by jrumbut

2 hours ago

The problem with up front spec writing was that it created this long, very high risk period where there was no code, no prototype, no hard limits.

So you're arguing back and forth about exactly which fields should be collected where and meanwhile the world is changing around you. The person who insisted on an absolutely minimal signup page has changed jobs, the new hire prioritizes complete data even if it means more signup bounces.

Weeks and months are going by and there's nothing to click on and still nothing to tether the project to reality or limit the scope of debate. High functioning teams can avoid this, but they don't always control who inserts themselves into the conversation.

And of course as soon as coding starts the spec is out of date unless you absolutely nailed it which I've never seen happen in 15 years. Once a user sees the software and gives feedback it probably needs to be rewritten. Maintaining the spec (pre-LLM) was not that much less work than maintaining the software itself. All this time the world around the software is changing and the spec needs to be updated to reflect that.

And while the spec helps in understanding the system, ultimately you still need to understand the code and it.

But now the time between spec and working code is greatly reduced and spec updating can be automated to an extent. The cost is greatly reduced and the benefits have increased, so people like specs now.

What I hated is when you come into an old project. The spec says one thing and the code contradicts it. WTF do you do? I felt more like an archeologist than a programmer.