Maintainability of Software is Key

I have an uncle who went to college in the 60's, got all degreed up in chemistry, and then went to work. He never left his first employer. After 30 years of mixing a little of this and a little of that together to see if he had a cure for cancer yet, he retired. He never had to write another resume; never had to go on another job interview. Not a bad gig if you can get it.

My journey as a software engineer has been somewhat different. I started my professional career over 25 years ago and almost can't count the number of employers I've had. I certainly can't count the number of co-workers and close team members I've had. I've worked for small technology companies, start ups during the "dot com era," big behemoth companies, and other companies not even in a technology business, but using software and creating their own applications nonetheless. I've helped create operating systems, device drivers, embedded network and security systems, education and database applications, web applications, restaurant food and cash register systems, voice communications, etc. I've coded in C, 3 different assembler languages, C++, Java, Ruby, JavaScript, Visual Basic, C#, and Perl. I've been on hugely successful projects, failures, and everything in between.

In short, I've been around the block a few times. I even spent about a year focused on recruiting IT talent.

I finished my formal education more than a couple decades ago, but I have constantly been forced to learn new things. When one starts a new job, there are new people to meet, new personalities and work habits to understand, and the need to learn what methods of personal interaction work (and don't work). There's new code bases to learn and procedures for getting work done. New coding styles and tools to adopt. Each company employs different styles of executive decision-making and management processes. At the end of the day one still needs to be productive and create the wealth for which they were hired. That's not easy ... but it is IMMENSELY educational.

My case isn't all that unusual in the software industry, but it's also not uniform. I've worked with several people over the years like my uncle who have had one job in their professional careers and, while that may work well for a chemist, I have concluded that it is often not such a good model for software engineers. I don't have an explanation for this, but there seems to be a correlation between depth of "vision" and the number of times one has been around the block. The more times around the block, the more far-sighted one becomes. Conversely, short sightedness seems to stem most from those co-workers who "don't get out much."

So why does this matter? It all depends on how you measure success in the development of software. One measure of success is simply whether it does the job for which it was designed. Another is how well it performs in the face of adverse conditions such as limited processing power or memory resources, hardware failures, or just unanticipated user actions. Longevity is also often a large part of the measure of success. Questions about whether the software continues to work over time as changes take place to its operating platform and environment are significant. Similarly, and probably most prominently, there is the cost of maintenance to take into consideration when evaluating a piece of software.

Maintenance of software is the single largest expense in any successful software system that has marketplace staying power. New features are constantly in production, bugs are encountered and resolved, and changes are implemented to keep pace with operating systems and related devices. The maintenance cycle is so costly that many companies struggle to survive it. Many companies fail. The conclusion, to me anyway, is that software success can only be measured by its performance in the maintenance cycle.

This is a subtle and very often overlooked aspect of software development. It's not something taught in academic environments because people are rarely in that environment long enough to care and the software written there has an entirely different objective than what is produced in for-profit ventures. Instead, the idea that maintainability is the ultimate measure of software success is something that only comes from practical experience ... something that comes from having been around the block a few times.