Maintainable code

Code maintainability is not often in the shortlist of qualities that businesses going "digital" are going to value. And if the right technical decisions haven't been made up-front, it might not be something that they'll be able to achieve, either.

Responsible code is modular, consistent, and testable code. These qualities drastically improve the ability of everyone to work with it, ensuring faster development cycles, reduced bugs, and generally improving the quality of a product from end-to-end. Not to mention that developers are happier working on project that has been well-maintained.

Sustainable software depends on responsible code, and software is only sustainable in so far as it can be easily maintained -- updated, refactored, extended, repurposed -- and this doesn't come without a little overhead.

Code reviews

To ensure your software is maintainable, production code should pass through a few sets of eyes. Junior programmers need leads they can emulate, and your leads need to be able to conduct helpful and stringent code reviews quickly and frequently. Code review cannot be two-hour sessions every time a developer merges a branch. Real projects have real budgets and deadlines and can't sustain big block reviews on top of the standups, one-to-ones, and every other meeting looking to take away precious development time.

Leads need to be able to run through code reviews quickly and effetively communicate key concepts to developers to be able to implement immediately. If a concept goes beyond what the developer is comfortable with, schedule a lunch and learn on that topic and invite all those who want a refresher. The idea is that your programmers want to become better at writing maintainable code.

Knowing what not to do only comes from experience -- the experience of having done things that you thought were smart, or clever, or correct, only to find yourself or others stumbling over them months later. Instead of setting up your developers to have to individually stumble through this process on their own during a development sprint, have your team leads write less code and act more in a mentorship role, catching flaws early on.


I've been told that all CS grads have had this bit drilled in their head from day one. "Divide and conquor", "Cohesive and Decoupled". It boggles my mind how few programmers actually take this to heart. Perhaps because they are working in new langauges and never cared to fully internalize how to properly write modular code in that language or framework. Perhaps because they did not feel they had the time to write better code. Perhaps because they're following a lead or architect who never called them out in a code review.

A simple way of knowing if your code is cohesive is to try to pull it out of first application and see if it still works. Another way is to unit test it. Even if you don't have unit testing framework and process in place (and why not?) you can still test it in isolation, or at least think about what the critical tests would be. What will happen in edge cases? What happens when dependencies aren't met? Testable code is a great first step towards maintainable code.


If you want your team to be agile, your codebase needs to be consistent. Every time a programmer sees something for the first time, you lose out of productivity. Every time you force a programmer to have to think about a new situation or pattern, you lose out on productivity. Every time you force a programmer to work in an environment that is foreign to them, you lose out of productivity.

I'm sure many new programmers take pride in their ability to jump in, sink their teeth in and hack a solution -- they might even be able to get it done in record time! But as these programmers become more experienced, they will learn to appreciate that what they only did was make their manager temporarily happy at the cost of accrueing technical debt for the rest of the team. And this leads to much sadness for everyone.

All code should look like it was written by the same person. Please. Have your architects and leads agree on strict rules, and enforce the syntax rules in your linters. Have your architects and leads agree on dominant coding patterns, and have them reinforced in all code reviews. When code is consistent, programmers are able to focus without distraction. That's where you see productivity.