A Modern Software Engineer's Manifesto - Part 2

In my last installment in this series, I discussed the need for software developers to integrate testing functionality into their programming workflow, as well as the need for management to buy into this concept. Today I raise an equally important principle - refactoring - which, when neglected, results in short-term headaches and long-term unprofitability for both engineers and executive stakeholders.

Part 2
Let My People Refactor

Mention the terms "legacy" or "other people's code" to a group of developers, and you are likely to get an earful of anything from empathetic sighs, jokes, or even moans of outright disgust. As much as we software developers love to build our own stuff, however, maintaining pre-existing (legacy) systems is a fact of life in today's frenetic technology environment. And often, these legacy systems were developed in haste, under the twin constraints of limited resources and end-user pressure, resulting in source code that is messy and hard-to-maintain. Rather than established software-engineering best-practices, there may be tight coupling, a lack of modular organization, overly-lengthy methods, code that performs the same function repeated in different sections of the application, or any number of other so-called "code smells."

The official term for this brand of coding chaos is technical debt. Technical debt, just like its financial counterpart, tends to grow exponentially when not paid down on a regular basis. This paying-down process is known as refactoring: a process by which sections of the application are re-written, re-organized, and re-architected - not to alter its functionality but to improve its design, enabling developers to extend and/or debug it efficiently. Unrefactored code is like a disorganized surgeon's toolkit - with scalpels buried underneath a pair of forceps, which is in turn entangled in a wad of suturing stitches. Would you want this doc to operate on you before straightening up his or her kit?

Most software developers know that the codebase they are working on is in some degree of disarray. Everyone talks about that infamous module or class with thousands of lines of tangled, tightly-interdependent, and redundant code. They would love to refactor this mess - but doing so always gets put off for more "urgent" (in the view of the powers-that-be) matters. Meanwhile, the technical debt compounds and the codebase becomes increasingly harder to maintain and troubleshoot, even as stakeholder demands increase. Many a developer has experienced career burnout due to this very scenario.

It is, therefore, imperative that a software company's upper management team afford their engineers sufficient time and resources to refactor their code and to reduce technical debt. This is important not only for the sake of developers' morale and well-being, but also for the company's bottom line. An organization cannot be profitable if (1) its employees are burnt-out from frustration, and (2) its products are unmaintainable (and thus not amenable to enhancements and improvements). The issue often arises because management is under the false impression that, since refactoring does not produce something that is visible to the product's customers, it is therefore unimportant (or at least not urgent), and can thus be swept under the rug without harming the organization's profitability.

They. Are. Wrong.

Therefore - to my software engineer friends, I am asking you to add to your arsenal of affirmations the following manifesto statement: As a software development professional, I have the right to the time and resources needed to refactor my codebase and to manage technical debt, in order that troubleshooting and future enhancements of the codebase may be feasible.