Much (although not necessarily enough) has been said about IT professionals coming of age. Ironically, in an industry rightly accused (so far) of ageism, we now have to contemplate a new twist on the problem: code is aging too. There are not only pockets, but pillars of code written decades ago that still do a good job. But fewer and fewer people know what that code does and how to manage it.
Programmers write whole systems or just temporary fixes (nothing is as permanent as the temporary fix!) without becoming philosophical about their work — they do not have the time or the inclination. Few thought at the time of their writing of some piece of code that that may be their brush with eternity. Unlike architects or painters, few programmers showcase their name with their work. In IT, for most people, work is anonymous and collective. But it is not as ephemeral as initially thought and there are hidden ways to distinguish ourselves.
As best practices continue to teach us, comments go a long way to enhance and prolong the existence of code, and they make the life of programmers so much easier. More than that, comments sometimes tell an interesting side story: you can retrieve the traces of old mates, their wanderings through companies and their IT exploits. Moments of despair, rebuttals or bursts of enthusiasm sometimes come out amidst what’s supposed to be stern lines of code and comment.
Often one is survived by the code produced. Causes are many: jumping ship to another company, career progression or change of direction, layoff and, now that the field has spun some decades, retirement is just round the corner for a lot of IT people.
Sadly, biological demise of a person while on the job is also to be factored in. For better or worse, code is always left behind (comments are just a bonus, not to be expected). And code is remarkably resilient: it is more difficult to ‘fire’ and replace a working piece of code than it is to hire a good replacement for a deposed programmer.
Some practitioners bank their careers on that. They know how difficult it is for anyone else to step into their shoes and do the unglamorous but essential job of maintaining old and usually undocumented code.
Deliberately writing hard-to-understand (albeit functional) code is a practice not unheard of. The trade-off is clear but comfortable for some: paycheck stability in a highly customized setting, at the price of a career dead-end in the larger IT world. But who needs the world if it will not pay the bills?
As many Java and Web developers could have attested until recently, having cutting-edge skills and finding a job were two very different things. While all the flashy stuff that meets the eye on Web pages and mobile devices are written in the flavour du jour of newer languages, the hard work is often done in the background by thousands and millions of COBOL, Assembler and PLI lines of code — especially in the banking and insurance industries.
The air travel reservation business still relies heavily on TPF, a specialized, ultra-efficient transaction system that has seen little change since the ’60s. And then there are custom-written languages and applications for various niche players, written in more recent years and which have become legacy as markets died or matured for the plethora of languages and platforms.
There is money to be made by those with reverse engineering skills and detective-like minds, who sooner or later will have to be brought in to maintain or resurrect these systems to another life. A lot of business rules lie buried in aging code, and extracting them is no easy task.
Rewriting a business application from scratch or implementing one from the shelf is not always a realistic option.
But this reality sunk in only under the threat of Y2K. The lack of an IT disaster of that time seems to have made everyone complacent again about the issue of aging code. The first wave of boomers turning 60 this year seems to bring the issue again to the forefront.
What shall be done at trench level until management gets its act together on the issue? For one thing, we should not hesitate to put our names on top of our coding opus. And make sure that the next in line to handle that piece will bless our name, not curse it.
–Andronache is a Toronto-based application developer for a large IT firm. She can be reached at [email protected].