It was 1996.
My second professional software project.
The assignment sounded straightforward enough: customize a standard software package for a customer. Six months were planned.
The requirements already existed. In fact, they existed in impressive quantity. Someone handed me a binder: a business analysis of roughly 200 pages.
At first glance, it looked thorough. Detailed. Professional.
The kind of document that gives everyone in a meeting the comforting feeling that things are under control.
The analysis had been written by a business analyst with years of experience.
Unfortunately, she was navigating unfamiliar territory.
This was her first project using our brand-new Windows version.
And she was still learning Windows herself.
That showed.
The document was full of decisions that felt strange:
- Simple Yes/No questions were represented as drop-down lists.
- Places where users should clearly select one option used multiple checkboxes.
- Screens looked less like a Windows application and more like a character-based system that had been fitted with graphical controls as an afterthought.
- The controls were modern. The thinking behind them wasn't.
And it wasn't just the screens.
Parts of the analysis left me wondering what was going on at the customer.
Some workflows felt strangely complicated.
Others felt artificial.
As if they had been assumed rather than observed.
The more I read, the more uncomfortable I became.
Eventually I walked over to her desk.
"This can't be what the customer needs!"
She didn't argue.
She took the binder from my hands and started flipping through it.
When she reached the signature page, she tapped her finger on the customer's signature.
"The customer signed for it."
Case closed.
At least officially.
Something Felt Wrong
Development started.
I implemented the first screens exactly as described.
And the feeling became worse.
Nothing was technically wrong.
The software behaved as specified.
The requirements were documented.
The signature was there.
The process had been followed.
Yet every screen I completed reinforced the same thought:
This is not going to work.
At that point I couldn't explain why.
No methodology.
No framework.
Just professional discomfort.
The uncomfortable suspicion that a lot of effort was being invested in creating something nobody would actually want to use.
Loading a Computer Into a Car
Today, when people want feedback, they schedule a Teams meeting.
Back then things were more physical.
We didn't have laptops.
So I loaded an entire desktop computer into my car.
Monitor.
Computer.
Keyboard.
Mouse.
Cables.
Everything.
Then I drove to the customer.
My idea was simple: Before spending six months building software, I wanted someone to reassure me that we weren't completely off track.
The CTO welcomed me, watched my demonstration, and seemed genuinely enthusiastic.
For a moment I thought I had worried for nothing.
But enthusiasm from management was not what I had come for.
"Could we ask one of the users to take a look?"
He agreed and called somebody in.
A real user.
Not a manager.
Not a project sponsor.
Not someone who had approved documents.
Someone who would actually use the system.
She sat down in front of the computer.
And almost immediately became confused.
She didn't understand how she was supposed to use it.
This wasn't an experienced Windows user. Quite the opposite. She was still new enough to graphical interfaces that, a few minutes into the test, I had to explain that a mouse could simply be lifted and moved back when it ran out of desk space.
Yet even she immediately struggled with the application.
And unlike me, she knew the business.
It wasn't a training issue.
And the software wasn't broken.
The screens, navigation, and workflow reflected the analysis.
Not the user's work.
I remember looking at the CTO.
The CTO looking at me.
And both of us realizing the same thing.
The software was behaving exactly as specified.
The specification was the problem.
The customer had signed it.
The users clearly hadn't.
Every Two Weeks
Panic is often overrated.
Sometimes it is surprisingly productive.
I proposed something that wasn't part of the plan.
Let me redesign the screens.
Let me implement a better solution.
And let me come back in two weeks.
The CTO agreed.
Two weeks later I returned.
The users sat down in front of the software and started using it.
Then the interesting part started.
The CTO, the users, and I discussed what worked.
What didn't.
And what we should tackle next.
Then I went back and worked on the next milestone.
Two weeks later, I returned again.
And again.
And again.
Over time, almost every screen changed.
Not because we had planned it that way.
Because reality kept giving us information that the original document never contained.
Nobody called it iterative development or incremental delivery.
Nobody called it agile.
Nobody talked about feedback loops.
We were simply trying to build something that people could use.
Four Months Instead of Six
The project was planned for six months.
We finished the customer-facing work in four.
Not perfect.
Not complete in every imaginable detail.
But good enough to satisfy the customer.
The remaining two months were spent differently.
We improved parts of the implementation.
Fixed a few bugs.
Cleaned things up.
Added a few nice-to-have features that we knew would make people's lives easier.
Things that hadn't appeared in the original analysis.
Things discovered while cooperating with actual users.
It felt like time well spent.
Not everyone agreed.
The People Who Were Not Happy
The customer was happy.
The users were happy.
The business analyst was furious.
To be fair, having a greenhorn systematically dismantle large parts of your 200-page analysis is probably not an enjoyable experience.
More surprising was the reaction of my development manager.
He wasn't impressed.
Especially the nice-to-have enhancements drove him mad.
At some point he called me in and made his position very clear.
"Don't work like that anymore or we'll have to fire you."
That sentence stayed with me.
Not because I felt threatened.
Because it was honest.
Years later I realized he wasn't really criticizing my work.
He was criticizing the fact that I had departed from an established process.
What Actually Happened
Looking back, people would probably call this an agile project.
I wouldn't.
Not because the label is wrong.
Because the label explains very little.
The important part was not that we worked in short cycles.
The important part was that reality outranked documentation.
And therefore, we started treating the signed specification as a hypothesis.
Users were allowed, even encouraged, to contradict it.
And when they did, we changed course.
That sounds obvious.
It rarely is.
Most documents gain authority once they have enough pages.
Signatures make them even more convincing.
The problem is that reality doesn't care.
Users don't care either.
The Inconvenient Part
The experience taught me something else.
At the time, I had unknowingly violated one of the unwritten rules of the software business.
The customer signs the specification.
The software house delivers what was signed.
Whether it is what the customer actually needs is a problem for a later invoice.
What Came Next
A few months later, I resigned.
Not because of that conversation alone.
But it certainly helped.
The next software house turned out to be remarkably similar.
Different customers.
Different product.
Different logo on the coffee mugs.
Same binder.