engineering practices
Code that can change.
Clean Code and Test-Driven Development - the practices that enable everything else: pipelines, contracts, and predictable delivery.
Monowai · Engineering Advisory
What if…
Regressions were caught by a test, not by a customer
Any engineer could open any module and follow it
Refactoring was routine - not a risk to be scheduled
Reviews argued design and intent, not archaeology
A green pipeline actually meant something
the premise
Everything downstream assumes changeable code
Pipelines, contracts, evidence - the whole delivery architecture rests on one assumption: code can change safely.
You can't automate the delivery of code you're afraid to touch. Before the platform, before the tooling, two practices make change safe - and neither can be bought, installed, or mandated.
the corporate default
How code usually ages
Optimised for the deadline
Written once, under pressure, for the milestone - then read hundreds of times by people who weren't there.
Tests written after - if at all
Coverage backfilled to satisfy a gate. It asserts what the code does, not what the business needs.
Review as archaeology
Reviewers reconstruct intent from variable names and hope. Approval means 'I gave up', not 'I agree'.
Fear-driven change
You don't refactor what you don't understand. The code calcifies, and every change becomes an act of courage.
None of this is a people problem - it's what happens when the cost of change is nobody's metric.
practice nº 1 - clean code
Written for the next reader
Code is read far more often than it is written - so optimise for the reader, not the author.
Small, intention-revealing units
Functions that do one thing; names that say why. The design is visible in the code, not in a wiki.
Don't repeat yourself
One concept, one place. Duplication is a bug you haven't had yet - twice.
Explicit boundaries
Modules expose intent and hide mechanics - dependencies point one way, seams are testable.
Leave it cleaner
Every touch improves the patch you touched. Quality is a habit applied continuously, not a project.
Design for change starts at the function level.
practice nº 2 - test-driven development
Red, green, refactor
Red
Write the test first
Say what the code must do before it exists. A failing test is the specification, made executable.
Green
Make it pass - simply
The smallest change that satisfies the test. Code earns its place by passing, not by being clever.
Refactor
Improve with the net up
Now reshape the design freely - the tests hold. This is where clean code actually gets made.
A loop measured in minutes - the tightest feedback loop in the whole delivery system.
what test-first buys
More than coverage
A regression safety net
Grows with the system, not behind it. Every behaviour that matters has a tripwire.
Design pressure
Hard-to-test code is coupled code. TDD punishes bad boundaries early, while they're still cheap to fix.
Executable specification
The tests say what the system promises - read them and know, run them and verify.
Refactoring confidence
Fragility becomes a choice, not a fact. The net is what makes 'leave it cleaner' possible at all.
Coverage is the by-product. The product is confidence.
how they reinforce each other
Two practices, one loop
TDD enables clean code
- The test net makes refactoring safe
- So design debt gets paid continuously
- Instead of accruing until a rewrite
Clean code enables TDD
- Small units are testable units
- Clear boundaries make fast, focused tests
- So the loop stays measured in minutes
Drop either one and the other decays - practise both and the loop compounds.
why this deck exists
The practices that enable the rest
Tight feedback loops
make continuous delivery real - a pipeline is only as fast as the tests inside it
Safe change
lets contracts evolve - you can honour a spec you're not afraid to implement
Green = releasable
keeps evidence honest - quality gates mean nothing over untested code
Readable systems
kill tribal knowledge - the design lives in the code, not in someone's head
Delivery architecture, contract-first, the product platform - all of it stands on these two practices.
taking it home
Start small, expand on proof
The next change, test-first
Don't backfill the estate. Write the test before the very next fix - the net starts where the work is.
Leave it cleaner
Every PR improves what it touches: a name, a seam, an extracted function. Compounding beats campaigns.
Never a rewrite
Strangle the mess module by module, behind tests. Rewrites reset the risk; refactoring retires it.
No tooling to buy, no programme to authorise - just the next pull request, done properly.
closing thought
Fragility is a choice.
Speed doesn't come from rushing - it comes from code that's safe to change.
Clean code and test-first development are how a team chooses, every day, to keep tomorrow cheap.
references & further reading
Read the books
Clean Code Robert C. Martin · 2008
Readable, intention-revealing code - the craft of keeping change cheap.
Test-Driven Development by Example Kent Beck · 2002
The red-green-refactor loop, from first principles.
Refactoring Martin Fowler · 2018
Improving design in small, safe, behaviour-preserving steps.
Working Effectively with Legacy Code Michael Feathers · 2004
Getting untested code under test - where most teams actually start.
Tidy First? Kent Beck · 2023
Small tidyings, and when to do them - the economics of cleaning as you go.