The Most Expensive Minute
Sometimes the most expensive part of software isn't implementation. It's the time spent solving the wrong problem.
- Discipline
- Business Analysis
- Type
- Anonymised professional work
Every user had the same habit. Download the document. Open it in Word. Switch the page from portrait to landscape. Continue working.
No one taught them to do it. They simply learned that this was how the software worked.
The exported document contained a wide table. The preview looked perfectly fine, but once downloaded, part of the table disappeared beyond the page. Rotating the document became part of the workflow.
After a while, nobody questioned it anymore. It wasn’t a feature. It wasn’t even a bug. It was just… normal.
Only later did I learn that this issue had been discussed for years. It never made it into development.
Problem Evolution
| Stage | What happened |
|---|---|
| Symptoms | Users manually changed every exported document to landscape before reading it. |
| Initial assumption | The preview had to remain portrait, so exports required a separate landscape layout. |
| Discovery | Users never asked for two layouts. They simply wanted to read the document. |
| Reframing | Use the same landscape layout for both preview and export. |
What surprised me wasn’t the problem. It was the assumption behind it.
For years, everyone had been discussing the same question:
How do we keep the preview in portrait while exporting the document in landscape?
Once that assumption was accepted, the implementation naturally became more complicated. Two layouts. Two rendering paths. More things to maintain.
The problem kept growing without anyone asking whether the assumption itself was still true.
When the Product Owner brought me the user feedback, we didn’t start with implementation. We started with a different question.
What problem are users actually trying to solve?
The answer was almost disappointingly simple. Users didn’t care whether the preview was portrait or landscape. They cared about reading the document without fixing it first.
Once we stopped designing around the old assumption, the solution became obvious. The preview and the exported document should simply use the same layout.
Later that day, I asked the developer how long the implementation had taken. He smiled.
About a minute.
Then he added,
Shipping it took much longer.
A feature had to be created. A branch opened. Code reviewed. Merge conflicts resolved. QA wrote new test cases, ran the tests, verified the output, and finally the change entered the release process.
The code itself was the shortest part of the entire delivery.
Before we left, he said something I still remember.
Nobody had really analysed it before.
It never felt urgent.
We all assumed it would be difficult.
Reflection
The code was never the expensive part. The expensive part was spending years solving a problem that nobody had stopped to redefine.
Users spent years rotating documents. The team spent years discussing implementation. The code took a minute. Understanding the problem took much longer.