|
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. |