More than forty years ago, I found myself sitting in one of those old corporate boardrooms that looked exactly like you would expect an old corporate boardroom to look.
Mahogany everywhere.
Big table.
Important people sitting around it.
I was there talking to a company about designing a hotel management system.
The discussion had been going pretty well.
They seemed to like what I was saying.
Then one of the executives finally asked the obvious question.
How many hotel management systems had I designed?
My answer was immediate.
None.
Not one.
The room got very quiet.
So why are we talking to you?
After a moment, somebody finally asked what everybody else was obviously thinking.
If I'd never designed a hotel management system, why were they wasting their time sitting there talking to me?
I told them that was exactly why they needed to be talking to me.
Their problem wasn't that they needed somebody to computerize what they were already doing.
Their problem was that they needed somebody to look at what they were doing in the first place.
That wasn't quite the answer they were expecting.
So I gave them an example.
I looked around the table and asked how many hotel rooms were represented by the people sitting in that room.
There was some discussion.
They added things up.
The number they eventually settled on was around 10,000 rooms.
Fine.
Then I asked another question.
Out of those 10,000 rooms, on an average day, how many actually had some kind of problem that required management's attention?
That took a little more thought.
Eventually they came back with a number.
About twenty.
That was the number that mattered.
Twenty.
The other 9,980 rooms were fine
Their existing systems were designed around reports.
Lots of reports.
This was long before anyone had a browser sitting on every desk or a phone in their pocket with more computing power than the machines running the hotel.
When I say reports, I mean real reports.
Paper.
Dot-matrix printers.
At the larger hotels, some of them had line printers, which were basically the bigger, faster, noisier version of the same idea.
They could chew through an impressive amount of paper.
That was part of the problem.
I told the people sitting around that table that their current system was essentially designed to produce a report explaining that 9,980 rooms didn't have a problem.
Somewhere in all that paper were the twenty rooms that did.
So somebody had to print the report.
Somebody had to handle the report.
Somebody had to look through the report.
And the vast majority of what the system was telling them was:
Everything is fine here.
Everything is fine here too.
This room is fine.
So is this one.
And this one.
And another one.
Thousands of rooms worth of "nothing to see here."
Meanwhile, what management actually needed to know was:
Here are the twenty rooms that need your attention.
That's a completely different way of thinking about the problem.
That's when I called it paving cow paths
I told them that taking a bad manual system and automating it was the net effect of paving cow paths.
The cow walks across the field enough times and eventually there's a path.
Then somebody comes along and says, well, everybody is already walking that way.
Let's pave it.
Nobody stops to ask whether that's actually where the road ought to be.
We just make the existing route more permanent.
And faster.
And more expensive.
That's what I thought they were in danger of doing with their hotel system.
They didn't need a faster way to tell management about 9,980 rooms that didn't require attention.
They needed a system designed around the twenty that did.
I've watched the same thing happen ever since
The technology changed.
That particular mistake didn't.
Years later, I started seeing the same thinking when people wanted to take old desktop applications and make web versions of them.
Then mobile became the big thing.
Someone would have a large Windows application with dozens or hundreds of procedures and say they wanted a mobile version.
And sometimes the proposed solution was basically to put something on top of the existing application and churn out a web or mobile equivalent of everything that was already there.
Technically, that's impressive.
But I kept thinking about those hotel rooms.
Just because you can put every procedure on a phone doesn't mean anybody wants every procedure on a phone.
In fact, most of the time they don't.
The mechanic doesn't need the accounting department in his pocket
I've used an automotive repair shop as an example of this for years.
Suppose somebody has a very good automotive repair application.
It's mature.
It's well thought out.
It handles customers, vehicles, repair orders, parts, labor, invoicing, history, scheduling, accounting, and everything else the shop needs.
Now they decide they need a mobile component.
Fine.
The wrong way to approach that is to say:
We need the automotive repair application to run on a tablet.
Why?
Does the mechanic standing beside a car really need the complete accounting system?
Does he need every report?
Every configuration window?
Every administrative function?
Probably not.
Maybe what he needs is a very simple way to stand beside the vehicle, pull up the customer, identify the car, enter the mileage, record the complaint, take some pictures, and start the inspection.
That's useful.
That's something the old application couldn't do nearly as well because the person had to leave the car and go back to a computer.
Now the technology has created a new opportunity.
That's different from reproducing the old application.
It's adding the part that was missing.
The environment should change the solution
That's the thing I think gets lost when people talk about converting applications.
A phone isn't just a smaller monitor.
A tablet isn't just a portable desktop screen.
A browser isn't just another place to draw the same windows.
The person using them may be in a completely different place doing a completely different part of the job.
If we don't think about that, we end up reproducing a perfectly reasonable desktop workflow in an environment where it makes no sense.
Then we congratulate ourselves because it's responsive.
We've done the modern equivalent of printing the 9,980 rooms faster.
Now AI can do it even faster
AI gives us a remarkable new version of the same temptation.
Today I can hand an AI a large old application and ask it to rebuild the thing using a modern stack.
Depending on the application, it may do an astonishingly good job.
It can inspect the old code.
It can find the business rules.
It can recreate the forms.
It can build web APIs.
It can produce responsive screens.
It can write tests.
It can even make the result look considerably better than the original application.
None of that answers the most important question.
Should we have recreated those screens at all?
AI is getting very good at answering the question we ask.
That means we need to get better at deciding whether we've asked the right question.
Otherwise we've invented the world's fastest cow-path paving machine.
The old system still has enormous value
None of this means I think old applications should be discarded.
Quite the opposite.
A good old application may contain decades of knowledge.
Somebody learned how the business really works.
Somebody found the exception nobody thought about in the original specification.
Somebody fixed the calculation that was wrong.
Somebody found out what happened when a customer did something nobody expected.
That accumulated knowledge is valuable.
I'd preserve as much of it as I possibly could.
What I wouldn't automatically preserve is the assumption that the old way of interacting with that knowledge is still the right one.
There's a difference.
The old program may know exactly what has to happen.
That doesn't mean the old screen knows the best way to make it happen today.
Forty years later, I'm still asking about the twenty rooms
I don't remember every detail of every software meeting I had forty years ago.
I remember that one.
I remember the boardroom.
I remember telling a room full of executives that I'd designed exactly zero hotel management systems.
And I remember the silence after I said it.
But most of all, I remember the numbers.
10,000 rooms.
Twenty with a problem.
9,980 without one.
Because those numbers reduced the whole problem to something obvious.
The purpose of the system wasn't to describe everything that was okay.
The purpose was to help somebody deal with what wasn't.
That's still the question I'm trying to get to when somebody tells me they want to modernize an application.
Not:
How do we reproduce everything this software does?
But:
What are the twenty rooms that actually matter?
Find those first.
Then build for them.
Related Guide
For the broader framework behind this story, see Don't Pave the Cow Paths.