Uncle Bob famously wrote:
“Truth can only be found in one place: the code.” -- Robert C. Martin, Clean Code
For years, that felt almost unquestionable.
Documentation gets outdated.
Diagrams lie.
Requirements drift.
But ultimately, the software does what the code says.
Yet Spec-Driven Development challenges that idea.
When a specification becomes the contract from which code is generated, validated, tested, or even regenerated, perhaps the hierarchy changes.
So where is the real source of truth now?
🔸 THE OPTIONS
▪️ Truth is in the CODE 💻
The spec expresses intent, but only executable code defines what the system really does.
▪️ Truth is in the SPEC 📜
The specification becomes the authoritative contract. Code is merely one implementation of it.
▪️ Truth is in BEHAVIOR ⚙️
Neither code nor specs are enough. The ultimate truth is what the running system actually does.
▪️ It depends 🤷♂️
Architecture, tooling, generation, testing, and governance determine where the authoritative truth really lives.
Maybe Spec-Driven Development doesn't make Uncle Bob's statement wrong.
Maybe it forces us to redefine what we mean by source of truth.
What do you think?
POLL OPTIONS
1️⃣ Truth is in the CODE 💻
2️⃣ Truth is in the SPEC 📜
3️⃣ Truth is in BEHAVIOR ⚙️
4️⃣ It depends 🤷♂️
#SoftwareEngineering #SpecDrivenDevelopment #CleanCode #Architecture #Java #Programming #SoftwareDevelopment #Developer #APIDesign #AI
Go further with Java certification:
Java👇
Spring👇
SpringBook👇
JavaFullstackBook👇