The issue with this is that code is the final form of specs, but fit for machine execution. Coding is mostly f(a, b, c, d, e, …) where all the variables are specifications. Iterating on specs is tweaking individual variables. You’re still missing the broader interactions between them, and sometimes, the formula itself changes (discarding some variables and getting new ones). And as soon as you hit production, the function is recursive (code is part of the things to take into account)
So, specs is more like an historical archive of decisions taken. I prefer to take a change request (ticket) transform it into a list of requirements, then apply that against the code rather than iterating through old specs in order to produce a new version of the code.
So it becomes f(z, k) where z is the specs for the change and k the old code, instead of f(a, b, c, …, z) (without k) where a and the others are updated specs and z is the new one.
ADDENDUM
In other words, specs are like memos while the code is the company policy handbook. No one edits past memos, you just issue new one, and then edit the handbook.
So I rather have code versions (git commits, …) that links to change requests, which link to discussion and analysis. Not dealing with a pile of documents.
Interesting read! My personal experience with Cursor aligns with this. The initial result of my prompt was stunningly good, but adjusting the code afterwards was not a great time. It also aligns with the software 3.0 concept pitched by Andrej Karpathy, making the english language (or other natural language) the new 'code'.
I’d rather shared infrastructure fit a stability and correctness spec than fit the whims of some random programmers throwing a fit and refusing to adapt.
I suppose you’re fine with bridges built haphazardly and airplanes with doors that fall off.
There’s real infrastructure under the software that powers critical logistics. Such systems really should just be simple and straightforward.
You want ornate meta software structures? Have at it on your personal laptop like a proper h4xx0r
If you’re a real practitioner of the craft you’ll do it for free in your basement. If you’re just trying to unicorn you’re just a traditional capitalist and that’s boring.
skydhash|8 months ago
So, specs is more like an historical archive of decisions taken. I prefer to take a change request (ticket) transform it into a list of requirements, then apply that against the code rather than iterating through old specs in order to produce a new version of the code.
So it becomes f(z, k) where z is the specs for the change and k the old code, instead of f(a, b, c, …, z) (without k) where a and the others are updated specs and z is the new one.
ADDENDUM
In other words, specs are like memos while the code is the company policy handbook. No one edits past memos, you just issue new one, and then edit the handbook.
So I rather have code versions (git commits, …) that links to change requests, which link to discussion and analysis. Not dealing with a pile of documents.
Avalaxy|8 months ago
android521|8 months ago
sodothat|8 months ago
I’d rather shared infrastructure fit a stability and correctness spec than fit the whims of some random programmers throwing a fit and refusing to adapt.
I suppose you’re fine with bridges built haphazardly and airplanes with doors that fall off.
There’s real infrastructure under the software that powers critical logistics. Such systems really should just be simple and straightforward.
You want ornate meta software structures? Have at it on your personal laptop like a proper h4xx0r
If you’re a real practitioner of the craft you’ll do it for free in your basement. If you’re just trying to unicorn you’re just a traditional capitalist and that’s boring.