Early in my career, someone described our way of working as “Origami Engineering”. The documents themselves were valuable — they helped us think, plan and coordinate before the first spade ever hit the ground — but the phrase stuck because it captured how easily documentation can become the work instead of supporting it.
At the time, I laughed. Years later, I realised he was right.
At the start of my career, I was an IT infrastructure and control systems designer for a large multinational consultancy. A significant proportion of my time was spent producing design documentation: specifications, schedules and drawings explaining in detail how something should be built.
We spent hours drafting, reviewing and redrafting documents, circulating them across disciplines to ensure everything aligned. From these, teams produced detailed 3D models of entire buildings, and we’d walk through them repeatedly in coordination meetings to make sure we weren’t all fighting for the same physical space.
As a consultancy, the documents were the deliverables. Milestone payments were tied to them. The final building mattered, of course — but for projects with timelines measured in years (industrial facilities, airports, infrastructure), documentation had to come first. Thousands of pages of specifications. Thousands of drawings. A lot of paper.
And in some cases, no building followed. Budgets changed, projects were paused or cancelled, and the result was a large body of expensive documentation that would never be read.
I assumed things would be different when I moved into testing.
They weren’t.
As a consultant test manager working in V-model deliveries, documentation was again the primary output: strategies, plans, detailed step-by-step test cases, completion reports and certificates marching us toward UAT sign-off. If you’ve worked with IEEE 829 or studied ISTQB, you’ll know the set.
What I gradually realised — though I’d never have admitted it to clients at the time — was that we were spending perhaps 80% of our time on documents: writing them, reviewing them, or talking about them. That left very little time for what I’d call actual testing — the critical work that illuminates product risk.
James Bach and Michael Bolton, renowned thought leaders in software testing, describe testing as:
the process of evaluating a product by learning about it through experiencing, exploring and experimenting…
Applying this definition, our balance felt off. We were delivering exactly what clients asked for — but not necessarily what they needed.
Something had to change.
I noticed that most test documentation was largely the same from project to project. Out of a 70-page test plan, I regularly referred to just two or three pages in practice. So why were we rewriting the other 67 every time?
We deliberately standardised as an experiment in efficiency and reusability. We created portfolio-level documents and reused them as appendices, supported by short, focused, project-specific plans — inspired by the “one-page test plan”.
The result: less repetition, lower cost, faster delivery, and more time redirected into testing. A genuine win-win.
But not all teams want documentation at all. Many swing to the opposite extreme, encouraged by the Agile Manifesto’s principle:
Working software over comprehensive documentation
Which too often gets interpreted as:
Working software with no documentation.
In my experience, selectively adopting isolated principles — or stripping them of context — leads to mixed results. The former is almost impossible without at least some of the latter.
I understand the appeal. I’ve seen first-hand how much effort can go into documents that few people properly read. But valuing a document solely as a completed artefact misses something important. In a document review meeting for a particularly large and complex project, which went badly, the client offered this insight:
The reason we write these documents is to think through what we’re going to do — before we do it.
The value is in the thinking. Writing forces us to discuss our ideas, challenge assumptions, make decisions and expose gaps.
And it’s far easier to change a plan when it’s just words or lines on paper than when you’re in the thick of delivery.
Documents aren’t the only way to do this thinking — but some deliberate planning and coordination is unavoidable if we want good outcomes. Skipping it has consequences.
Thinking is hard. And when teams reject documentation entirely, there’s a risk they reject the thinking too — choosing instead to “wing it”.
So perhaps the real question isn’t do we need documents?
Many will gather virtual dust on a shared drive. What we truly need are living processes: shared ways of working that help teams think together, challenge assumptions and continually improve.
This is even more important in Agile contexts, where speed amplifies mistakes. Processes must be lightweight, explicit and useful.
And product documentation matters too, distinct from process documentation. Process documents describe how we work; product documentation captures understanding of what we are building. Not just at the end as manuals and help files, but throughout development. Capturing understanding as we go reduces painful thrashing later — and the thinking that happens while writing often leads to better ideas and better products.
Maybe the goal isn’t to eliminate paperwork, nor to fold ever more elaborate origami — but to ensure that whatever we write earns its place by helping us think better, decide more clearly, and deliver with greater confidence.