I was thinking about software maintenance recently, and a fairly simple comparison came to mind.
Building software is a lot like building an apartment complex.
You design it, figure out how everything connects, build it, test it, and eventually open the doors.
But opening the doors isn’t the end of the work. People move in.
Things start getting used every day. A pipe leaks. A door stops closing properly. An elevator needs servicing. Something that worked perfectly for the first hundred residents starts struggling when another thousand arrive.
Sometimes there’s a small crack that can be patched in an afternoon. Sometimes that crack tells you there’s a much bigger structural problem underneath.
Software isn’t particularly different.
You launch it, people start using it, and eventually things break. Bugs appear. Dependencies become outdated. APIs change. Security requirements evolve. A feature designed for 100 users suddenly has 10,000. Something that made perfect sense three years ago becomes the part everyone is afraid to touch.
That doesn’t necessarily mean the software was badly built.
Buildings need maintenance because they are being used. Software does too.
The more I thought about the comparison, though, the more I realized that the software industry has never exactly hidden this connection.
We build software. We design its architecture. We create frameworks. We depend on infrastructure. We talk about platforms, pipelines, stacks, components and even scaffolding.
We worry about how something will perform under load. When the existing structure can’t support what we need anymore, we rebuild or refactor it. And the people responsible for some of the biggest structural decisions are literally called software architects.
Not every one of these terms came directly from construction. Computing has borrowed language from engineering, mathematics, manufacturing and plenty of other disciplines. But the pattern is hard to miss.
When people needed words to describe increasingly complicated software systems, the language of buildings and infrastructure made sense.
A building isn’t really one thing. Behind the walls are electrical systems, plumbing, ventilation, structural supports, elevators and hundreds of other components most residents never think about.
They just expect the light to turn on when they flip the switch.
Software users have roughly the same relationship with software.
They click a button.
Behind that button might be a frontend, an API, authentication, a database, a payment provider, several cloud services and a collection of dependencies maintained by people the user will never know exist.
They don’t need to know where the pipes are.
Someone does.
And this comparison becomes particularly interesting now that LLMs are changing how quickly software can be created.
Someone can describe an idea in ordinary language and, with the right tools and enough iteration, have a functioning application surprisingly quickly.
It’s a little like suddenly giving millions of people access to a construction crew that can work incredibly fast.
“Put a wall here.”
Done.
“Add another room.”
Done.
“Move the kitchen over there.”
Done.
For prototypes and experiments, that’s incredibly useful. You can find out whether an idea actually works without spending months assembling a team just to get something onto a screen.
But construction speed and building ownership are two different problems.
The apartment still has to survive after people move in.
Imagine taking ownership of a large apartment complex without really knowing how it was constructed. Everything looks great until Unit 1704 develops a leak.
Where does that pipe go?
What else is connected to it?
Can you replace it without shutting down water for half the building?
And if you change something here, what happens three floors below?
An LLM can help create thousands of lines of code remarkably quickly. But generating code and understanding a system aren’t quite the same thing.
Eventually, the important question becomes:
Does anyone understand the building well enough to maintain it?
That doesn’t mean everyone using LLMs to build software needs to become a traditional software engineer. But it does mean that as construction becomes easier, maintenance becomes more important rather than less.
Good documentation matters. Sensible architecture matters. Monitoring and testing matter. Understanding dependencies matters.
And somebody should probably know which walls are load-bearing before asking the construction crew to knock one down.
There’s a tendency in software to treat launch day as the finish line.
The product shipped. The website is live. The app works.
But a property developer wouldn’t look at a newly completed apartment tower and say, “Excellent. We’ll never have to touch that again.”
The building has simply entered another phase of its life.
Software does the same thing.
Once people depend on something you’ve built, the job changes from construction to stewardship.
That may become even more important as LLMs make software dramatically easier to create. We’re getting very good at putting buildings up quickly.
The next question is whether we’re getting equally good at looking after them.
Because eventually, something will leak.
And when it does, someone needs to know where the pipes are.