Maintainability Over Efficiency

On Tuesday, I shared a story about a manager early in my career who challenged everything I had learned in college about writing efficient code.

He told me that readability and maintainability were more important than squeezing every bit of efficiency out of a program.

At the time, I didn't understand his perspective.

Then I was assigned to document a program written by a very talented programmer. This programmer was extremely intelligent and always looking for ways to make his programs more efficient. He would read about new programming techniques and say, "I'm going to use that in my next program."

And he did.

I believe his intentions were good. He genuinely wanted to write better, more efficient software.

I was fresh out of college when I started documenting one of his programs.

I had learned about recursion in school, but I had never encountered it in a real-world application.

After spending several days trying to understand the program, I finally realized something.

The program was calling itself. Over and over.

I managed to trace it through several iterations, but eventually I would lose track of what was happening.

So I decided to take a break from that part of the documentation and focus on the database calls.

That's when things got even more interesting.

I couldn't find references to the database fields anywhere in the code.

The application used an IMS database, with data stored using VSAM. Instead of referencing the database fields through the expected database interfaces, the programmer was updating the underlying VSAM storage directly using offsets.

It was efficient. But it was a maintenance nightmare.

In fact, the team had already decided they weren't going to modify that program anymore. Instead, they would make changes to the programs that interacted with it.

Think about that.

A program was so difficult to understand and maintain that the team decided it was safer to work around it than to change it.

He was trying to solve one problem, but inadvertently created another.

The program may have been efficient for the computer, but it was incredibly inefficient for the people responsible for maintaining it.

Suddenly, my manager's advice made a lot more sense.

Good code isn't just code that runs well. It's code that someone else can understand, maintain, and build upon.

That experience changed how I thought about software development.

And there are a few more lessons from those early years that I want to share, so I'll continue this story next week.