“My dear young man, don’t take it too hard. Your work is ingenious. It’s quality work. And there are simply too many notes, that’s all. Just cut a few and it will be perfect.” – Amadeus
It sounds bizarre, but I’m getting to the point in my software programming career, where the less code I write, the happier I am.
Believe me, I know how strange it sounds.
Like I’m some Shaolin monk in some remote monastery, studying prayer wheels and imparting zen wisdom to less experienced and junior programmers.
Yet grasshopper, I speak the truth.
Let’s get something clear. Computer code is to a programmer what musical notes are to a composer. It’s what we create in order to communicate our wants and desires to a computer.
Until computers are smart enough to understand human languages, we must resort to communicating with them at their level.
So to be effective computer programmers, we must master the art of writing code. Like anything else, mastering a particular skill is a lifelong journey.
This is especially true with the art of writing computer code.
I still remember the joy of getting your first software program to work and do your bidding.
Writing code was so exciting back when I first began my programming career. Everything was a new learning experience and there was so much to learn.
You have to learn the specific syntax of whatever computer programming language you decide to use. You must learn the basic concepts every computer languages share to this day … while loops, if-then logic, switch statements, for next loops, and a number of other core concepts.
The early phase of my developer career was a heady time. It was a real headrush. I coded like a madman. Did it really matter that the act of coding was more important than actually analyzing the problem and figuring out the optimal solution?
Of course not!
So I was coding like a mad man, figuring that’s really what being a software developer is all about.
That is, until the rubber hit the road, and I had to deal with all the fallout of my mad rush to code everything as I could, as fast as humanly possible, without first analyzing the problem I was trying to solve.
It led to lots and lots of rewriting and refactoring of code.
Which bothered me to no end, because if there’s one thing that absolutely drives me bonkers, is having to do something twice, unnecessarily. Which is probably why I’ll do everything humanly possible to stuff as many groceries, regardless of weight, into one or two shopping bags, so I don’t have to make a SECOND trip back to my car to get the rest of the groceries for a second trip.
It took me the longest time to realize a profoundly strange sounding but conclusive truth …
Software developers need to write LESS code, not MORE code.
I know it sounds strange for a software developer to say more code causes more problems.
It reminds me of the movie, “Amadeus”, where Mozart asks his sponsor, Emperor Joseph II, what he thought of his new musical masterpiece … and the Emperor’s funny but devastating reply:
“My dear young man, don’t take it too hard. Your work is ingenious. It’s quality work. And there are simply too many notes, that’s all. Just cut a few and it will be perfect.”
As funny as this sounds, a tone deaf musical neophyte criticizing the best musician and composer the world has ever seen, the ridiculous notion Mozart’s music needs a little trimming down, there’s a sort of comic truth that continues to resonate with my own philosophy about coding.
It took me the longest time to understand this truism, because it sounds so counterintuitive, but every line of code introduces new technical debt and support problems in the future.
Even if the code is the cleanest and most well written and thought out code the world has ever seen, there are two fundamental truths that every line of code ever written by a software developer faces:
1. The original programmer, sooner or later, no longer becomes responsible for the original code
2. The original business problem the code was written to solve, changes.
It’s rare that the original programmer of a piece of code owns that code for the entire lifetime that code exits.
Life happens. We all get promoted, or transfer to a different department, or leave the company or organization for greener pastures. It happens all the time and should be factored into every software project.
But when the original programmer/designer of a piece of code leaves, it does leave a vacuum of knowledge where all the original tribal knowledge and expertise that went into the original code, disappears.
This causes lots of problems for the next programmer in line, who inherits this original source code. They must quickly get up to speed with the codebase, but what typically happens is the original programmer is unavailable or no longer with the company, to even answer the questions the replacement programmer needs answered.
And nine times out of ten, the code is poorly documented, if at all. In reality, the only true documentation is the source code itself. So the programmer who inherits the application, must essentially read the source code and somehow deduct the ESSENCE of what the code is trying to do, from a 30,000 foot level.
This, in my opinion, is the toughest part of being a software developer. Understanding what source code does at the level a computer interprets the code, is relatively easy and straightforward.
But understanding what BUSINESS PROBLEM the code is trying to solve … now THAT is the truly challenging part. Human readable documentation is supposed to address this, but the sad reality is that software projects are always a mad rush to get out into production, and documentation is always the first thing to get axed, when scheduling software ship dates.
The second problem which all code, sooner or later, introduces, is staleness.
Let’s go back to the fundamental reason why computer programmers write code.
It’s not for the sake of writing code, as naively as I thought, during the beginning of my programming career.
The sole purpose of computer code, is to SOLVE A PROBLEM.
We programmers start with a problem statement or some business need.
Once we take the time to understand and analyze the problem statement, we formulate a design plan to solve the problem through computer code.
But what happens when the original problem statement changes?
This is not a rare occurrence.
Problem statements evolve. Companies and organizations are always evolving. Business goals and mission statements are always in a state of flux.
Unfortunately, the computer code that was written to solve those original problems does not automatically change and adjust itself to solve the new business problem statement.
This is what happened recently during one of my enhancement projects.
During testing of some new enhancements and code changes for one of my recent projects, I came across a new runtime bug.
Upon further analysis, I tracked down the exact computer code behind the cause of the error.
And the other members of my team quickly pointed out the same piece of code as the culprit behind the error, and brought up lots of ways to address the error and fix the code.
But nobody bothered asking the question whether the code itself continued to deserve to exist.
What I was really trying to get to the bottom of was whether the code in question, was still relevant? Does the business problem it was originally written to solve, still a valid business problem?
That was the question I sent out to the rest of the development team.
If the business problem the code was originally written to solve, is no longer a relevant business problem, that code needs to be eliminated.
Removing the code, removes one less potential defect in the overall application, and less support and maintenance that the next software programmer that comes in after me, needs to worry about.
So I guess I’m writing less code these days than I used to.
But if that means fewer maintenance headaches for me and more time for those fancy little umbrella drinks?
*Cue Pina Colada song*
