Maintaining Code from Others

Small applications written on limited budgets, tight deadlines, limited specifications and frequent changes often result in code that is difficult to maintain and change over time.

Add to this the dreaded "someone else's code" and you're in for a rough ride.

My first "real" job in a software support role came with a manager who refused to promote anyone into the developer space until they've spent at least two years in support. The reason for this? If you get the 3am phone call several times a month to track down a mysterious failure that was recently introduced by the dev team, you’re less likely to be careless once you get into the dev team.

Learning from the pain is an important step in becoming a better developer and builds an understanding that code lives beyond the first release. Once you are done developing the specific piece of software and move on to another project, sometimes with another company entirely, someone is left behind to keep it going, make necessary adjustments over time as requirements change and patch security flaws and incompatibilities introduced by the passage of time and advancement of the hardware and software it is built upon.

But many have not had this lesson.

I've been hoping between a few codebases for various clients, solving minor issues, making changes and adding features.

The biggest pain points have been improper naming of controls, variables and functions. It's difficult to search through code when the variable holding the applicable tax rate is called t1var throughtout the entire code base. Function names that do not adequately describe the actual work being performed, CreateReportNew1 and the always beloved Textbox1 though 27.

The other has been massive code duplication and associated dead code.

Three or four overloads of a single function, but only one is ever called. Copying and pasting blocks of code into functions when they could be refactored into a function has been a killer of reliable future changes. There's always somewhere that gets missed during the change cycle and that only crops up in the production enviroment six months after release. This is primarily because testing is performed manually.

When variable and function names aren't important enough to receive proper names, the odds of test existing are minimal. Sadly with small software utilities and reports, sub 10 000 lines of code, clients are highly unlikely to approve time to retrofit tests, refactor code, add logical naming and cull dead code.

To my fellow programmers, please think of those who come after you when implementing code because one day you'll be the code plumber attempting to correct a critical issue with zero prior knowledge of how the system works and you wouldn't want to be on the receiving end of poorly designed and writted code when that happens.

To those currently code-plumbing, there's light at the end of the tunnel but unfortunately that light is usually at a different company.

It's a dirty job, but someone has to do it.