Developers & Fixer-Uppers

Developers don’t like to be fixers of other developers’ code. If the developers are on the same team, proficient in the same language, and the fixing is happening as part of a code review, then cool, but otherwise, it is typically a pass.

The older, undocumented, and foreign code is to a developer, the less they want to take on fixing code and an application overall. Code can be highly intertwined, making it laborious to connect all the dots adequately. The worst nightmare for a developer is to get into a codebase they aren’t familiar with, only to discover the code is spaghetti once they become familiar with it. A developer who is expected to make sense of and rewrite old spaghetti code will begin to question their life choices, at least professional ones. This is one of the reasons good code comments, documentation, version control, and standards-based coding are so important. Developers need to write and leave their code to make it easy for other developers to modify and evolve. Developers who don’t are amateurs. Developers should operate as if someone besides themselves will be managing the code in the future because they will.

We do due diligence on software products as part of investment rounds, mergers, and acquisitions. The most consistent negative feedback we give is that code is not well commented, documented, or structured, making it significantly more challenging for it to not only be maintained and extended but also scalable. Poorly written code will cause performance issues for an application that initially may not be identifiable but will appear at critical times of user and usage growth. The code needs to be discarded and rewritten in some of these circumstances. We don’t like delivering this news as part of technology due diligence engagement, but we have a responsibility to.

As a services firm, we often get asked by potential clients to fix what they or someone else they’ve engaged with in the past has done with bad code. We almost always decline to engage because we don’t want to subject our team to have to clean up someone else’s mess and the angst associated with it. Good developers want to write good code, and they don’t want to get mired in cleaning up someone else’s mess which could compromise their writing good code. Good developers care about the efficacy and efficiency of their work. Fixing someone else’s bad code and not being able to rewrite an application entirely means the quality of a developer’s code and, therefore, reputation could be at stake.

No developers’ code is perfect, and the best developers are humble in light of this. Developers not wanting to fix someone’s bad code isn’t about ego, as some people suspect. It is the opposite. Developers who take great pride in their craft know how challenging it is to be a great developer and that the veracity of their code is their work product. Anything that diminishes a developer’s ability to stand behind their code is a professional representation of themselves. I would also say that it is a personal representation of themselves because, like any other creative craft, writing code directly represents the person who writes it.

Development is deep work, and it takes tremendous focus to write great code. The intensity required by developers to do great work can’t be understated. The only thing developers like less than fixing someone else’s bad code has to rewrite code they’ve written because the requirement changed or was poorly communicated. Rewriting one’s code when it isn’t the developer’s fault is tolerable, even if annoying because a developer is at least rewriting their code. Fixing another developer’s bad code is a different thing entirely.

Rewriting another developer’s code is part archeological dig, part janitor, and part trail guide, working to establish how it got the way it is, determining what can be kept and what needs to be thrown away, and figuring out a path forward. Is the developer expedition a fun challenge occasionally? Yes, for some, it is. But most good developers would rather take their journey writing code that doesn’t have a legacy of chaos to get the job done.

Fixing others’ code can be an emotional experience for developers who otherwise are fairly stoic and unemotional. The anxiety of not knowing what they will encounter and being able to stand behind the revamped code and product can make developers emotional about the work, causing them not to do their best work.

The purpose and impact of a product weigh into a developer’s perspective on rewriting another developer’s code. A high-value and high-impact application that helps to improve society and lives will carry much more favorable consideration. We are fortunate at AWH to work with many clients who have a significant positive impact on communities and people, making it more tenable for our developers to rewrite bad code willingly. We don’t take this for granted as a firm and value our team’s willingness to take on important rewrite engagements.

It is important to note that code is also in the eye of the beholder. One developer will look at a code set and deem it acceptable based on their experience, expectations, and standards. In contrast, another developer will look at the same code and be utterly appalled and disappointed. The ranking of code can be subjective. Ideally, it wouldn’t be given the maturing standards and the use of proper syntax within programming languages. Still, two skillful developers can each develop different yet effective ways to approach a piece of code. In these cases, they can be right by identifying different yet mutually effective ways to write an area of code. This is what makes coding have an artful and creative flair behind the lines of working code. There are often many different ways to approach coding that would be reasonably effective.

Developers who can and willingly fix other developers’ bad code are the SWAT team members of developers. They relish the challenge and, by doing so, know it separates them from other developers who shy away from the challenge. These developers are often more experienced and daring, and they want the most complex coding challenges. These developers also tend to work better on their own or as part of a really small team because the intensity of the work requires tremendous focus and energy. These fix-it developers will often say, “Okay, I will take this on but leave me alone for the next six months while I get my arms around this.” Unless a company never has to deal with any technical debt and bad code (Ha!), maybe they don’t need a few SWAT developers on their teams, but my guess is they need at least a few.

It is easy to be pollyannish and expects that bad code is a thing of the past with today’s coding standards and the maturing of the craft, but we know that isn’t true. Bad code will always be a reality and present, and it depends on the degree and whether an organization has the culture and team members’ capability to overcome it.