Build for the Next Developer, Not Just Yourself
“Good software should never depend on the original developer being available to explain it.”
Several years ago I accepted a contract to replace a developer who was leaving a company.
The website was built on Drupal.
At least… that’s what everyone thought.
What I actually inherited wasn’t really Drupal at all.
The login system had been bypassed and replaced with a custom authentication system.
Content wasn’t managed through Drupal’s CMS. Entire pages had been written directly in PHP and dropped into Drupal as though it were nothing more than a file repository.
Drupal wasn’t being used as a content management system.
It was being used as a folder.
Then I opened one of the primary application pages.
Over two thousand lines of PHP.
No functions.
No classes.
No meaningful separation of responsibility.
Very few comments.
And more than eighty nested if statements.
One continuous wall of code.
At one point I remember finding something like this:
$x = 1;
if ($x == 1) {
...
}Not because $x changed later.
It didn’t.
That pattern simply appeared over and over throughout the application.
It wasn’t code that had evolved over time.
It was code that had never been designed in the first place.
The company had been paying the original developer approximately $150 per hour for support.
Not because the application was particularly sophisticated.
Because nobody else could understand it.
It was actually cheaper to rebuild major sections of the application than to continue maintaining what already existed.
That experience has stayed with me ever since.
Code Shouldn’t Require a Translator
One of the biggest compliments I’ve ever received wasn’t about performance.
It wasn’t about solving a difficult technical problem.
It wasn’t about building a beautiful interface.
It was another developer saying:
“I understood your code.”
To me, that’s success.
Because one day someone else will inherit every piece of software we write.
Maybe another developer joins the team.
Maybe the project changes hands.
Maybe it’s you six months later trying to remember why you made a particular decision.
Good software shouldn’t require the original developer sitting beside you explaining how everything works.
The software should explain itself.
Job Security Through Confusion Isn’t Job Security
Over the years I’ve heard variations of the same idea.
“If nobody understands the code, they’ll always need me.”
I’ve never agreed with that philosophy.
Software that only one developer understands isn’t valuable.
It’s fragile.
It’s technical debt disguised as job security.
Professional developers shouldn’t build systems that create dependency on themselves.
They should build systems that allow other developers to succeed.
Build So a Junior Developer Can Maintain It
Whenever I start a new project, I try to keep one person in mind.
Not the senior architect.
Not the original client.
The developer who inherits it next.
My goal has always been simple:
Could a reasonably capable junior developer understand this project after spending some time with it?
That doesn’t mean the software has to be simplistic.
It means it should be logical.
Functions should have one responsibility.
Classes should have one purpose.
Folders should make sense.
Variables should describe what they contain.
Method names should describe what they do.
Architecture should guide the reader instead of confusing them.
If another developer spends three weeks trying to understand my code before making their first change…
I haven’t done my job very well.
Write for the Reader
One of the biggest misconceptions in software development is believing we’re writing code for the compiler.
We’re not.
We’re writing it for people.
The compiler only needs correct syntax.
The next developer needs context.
Good naming.
Logical structure.
Predictable organization.
Comments explaining why something exists.
Not comments explaining what an obvious line of code does.
The code itself should explain the “what.”
Comments should explain the decisions.
Tomorrow’s Requirement Is Never Today’s Requirement
Anyone who has worked with me knows I dislike hardcoding values.
Not because abstraction is fashionable.
Because requirements change.
Today’s fixed value becomes tomorrow’s configuration option.
Today’s single payment gateway becomes tomorrow’s four payment gateways.
Today’s single organization becomes tomorrow’s multisite deployment.
If every change requires rewriting large portions of the application, the problem usually isn’t the new requirement.
It’s the original architecture.
Good software anticipates change without pretending to predict the future.
The Hidden Cost of Spaghetti Code
Spaghetti code has an interesting characteristic.
It often gets features delivered quickly.
It rarely builds software that survives.
The fastest code to write is frequently the most expensive code to maintain.
I’ve inherited projects where adding a single feature required tracing execution through dozens of unrelated files because nothing had clear responsibility.
That’s exhausting.
More importantly…
It’s avoidable.
Code Is Read More Than It’s Written
One sentence has shaped the way I write software for years.
Code is read far more often than it’s written.
Every developer knows this.
Surprisingly few develop like it’s true.
Every decision we make should make life easier for the next person reading the codebase.
Not harder.
Build Software That Doesn’t Need You
This might sound like strange advice coming from someone who develops software professionally.
But I genuinely believe it.
Build software that doesn’t need you.
Not because you’ll never touch it again.
Because someone eventually will.
The true measure of good engineering isn’t how indispensable the original developer becomes.
It’s how confidently another developer can continue the work.
Software should outlive its author.
If another developer can understand it…
extend it…
improve it…
and confidently deploy it…
without asking me how it works…
then I’ve succeeded.
Because I wasn’t building software for myself.
I was building it for the next developer.
Highland Principle #5: Build for the next developer, not just yourself.