undefined | Better HN

0 pointsonion2k7d ago0 comments

Code is a specific implementation of a spec. You can even use it as a spec if you're happy to accept exactly what the code does. But the code doesn't tell you what was supposed to be built so the code is not a spec.

Simple thought experiment: Imagine you have a spec and some code that implements it. You check it, and find that a requirement in the spec was missed. Obviously that code is not the spec; the spec is the spec. But also you couldn't even use the code as a spec because it was wrong. Now remove the spec.

Is the code a spec for what was supposed to be built? No. A requirement was missed. Can you tell from just the code? Also no. You need a two separate sources that tell you what was meant to be written in case the either of them is wrong. That is usually a spec and the code.

They could both be wrong, and often are, but that's a people problem.

0 comments

lmm7d ago

> Obviously that code is not the spec; the spec is the spec. But also you couldn't even use the code as a spec because it was wrong.

Or the spec was wrong and the code was right; that happens more often than you might think. If we view it through the lens of "you have two specs, one of which is executable" then obviously you could have made an error in either spec, and obviously writing two specs and checking for mismatches between them is one possible way to increase the fidelity of what you wrote, but it's nothing more than that.

onion2kOP7d ago

That assumes that the two have equal 'authority' though. Really one of the two should be the source of truth, and that's usually the spec. That's definitely the one that the should win if there's a difference in my experience.

j / k navigate · click thread line to collapse