Let’s talk about maintainability.

Those of you that know me know that in my civillian identity, I work as a SQA professional. QA gets a bum rap sometimes; manual functional testing can be one of the most boring parts of software engineering, but while there’s plenty of button-pushers who will be happy to poke at an application for minimum wage, there’s a lot more to quality than simply functionality. One of the commonly overlooked aspects is maintainability: the ease with which changes can be made to the software system.

Jeff Foxworthy at Resch Center

Now, maintainability can be measured. You can track how long it takes to discover the root cause of an issue, or how long it takes to work a simple enhancement request. You can track the number of groans or “WTFs” per minute in code review. You can track the cylcomatic complexity of the codebase or, if you’re a masochist, the Halstead complexity. But there’s a number of informal, “gut feel” warning signs you can use to tell if your application is maintainable. Here’s a sampling I’ve collected from various programmers in the industry. I like to call it Your code might be unmaintainable if…

Your code might be unmaintainable if the programmers give it nicknames like “the monster” or “the barge” or utter the words “there be dragons”

Your code might be unmaintainable if you can tell how old a file is by what revision of the coding standards it follows – within 3 seconds of opening the file

Your code might be unmaintainable if requesting a dependency map from the database server chugs for 30 minutes then crashes with an “out of memory” exception

Your code might be unmaintainable if you’re the most senior dev on the team… six months out of uni

Your code might be unmaintainable if you can’t localize the text of dropdowns for a new locale because that would break the existing 400-line if-else chain that lists out every localized string and keys functionality based on it

Your code might be unmaintainable if management dictates the design of the codebase – down to the nitty-gritty tactical level. Bonus points if the manager is a non-technical VP who responds to criticism by firing the developer on the spot.

Your code might be unmaintainable if half the variable names are in a different language and nobody’s quite sure which

Your code might be unmaintainable if you’re serving 20MB of CSS files on every request

Your code might be unmaintainable if your dependency graph is unreadable when printed on a single sheet of 8.5“ x 11” paper. Or a single sheet of A4. Or a single sheet of A3.

Your code might be unmaintainable if your variable naming “convention” is u734, u1234–2, u623, etc… and variables all change names between files

Your code might be unmaintainable if you have a single function webservice with 17 layers of abstraction between the entry point and where the business logic lies. Apparently the developer had never heard of YAGNI

Your code might be unmaintainable if you re-order the properties of an object and the code breaks

Your code might be unmaintainable if Microsoft Access forms a critical part of your business workflow. Or Microsoft Excel. Bonus points for unreadable Excel macros that fall victim to other traps in this article

Your code might be unmaintainable if it includes the line #defined ONE_HUNDRED 100 unironically

Your code might be unmaintainable if you find the source code! …in a folder marked DEV_BACKUP_2013

Your code might be unmaintainable if you can’t find the malfunctioning bit of code because it’s monkeypatched onto a class you control from god knows where

Your code might be unmaintainable if you go to debug a production issue and not only can you not reproduce, the entire functionality isn’t present in the codebase on the development servers.

Your code might be unmaintainable if you go to debug a production issue and not only can you not reproduce in dev, you can’t find the functionality even in production. Bonus points if you finally chase down a series of redirects and end up on some server somewhere, named after a flower, that was meant to have been decomissioned years ago. Double bonus points if you’re pretty sure it shells out to a Minecraft server in the process.

Your code might be unmaintainable if it’s full of comments that simply read //BUGBUG. Or //TODO (with no further explanation)

Your code might be unmaintainable if there’s a header at the top of every page served up in production that reads


// [Decompiled](http://thedailywtf.com/articles/variables-everywhere-but-not-a-stop-to-think) with JetBrains decompiler
// Type: FloorPlanCLR.EventManagementService.Triggers
// Assembly: FloorPlanCLR, Version=1.0.0, Culture=neutral, PublicKeyToken=null
// MVID: 55C2F875-6F43-4FDE-A2C6-6CD7F464A43B
// AssemblyLocation: C:\Users\SomeGuy\Pictures\FloorPlanCLR.dll

Your code might be unmaintainable if it’s in a proprietary langauge your company invented. Or a blend of two such languages.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!