Code Renaissance is about building great teams and great software. By exploring best practices, team interactions, design, testing and related skills Code Renaissance strives to help you create the team and codebase that you've always wanted.

Maintainability: Consistency Trumps Correctness

Consistency is the key to a maintainable, high quality codebase. The way an architectural problem (see def) is solved in one part of the code is the way it should be solved everywhere in the code. This is true even if that solution isn't totally correct, correct being defined here as the optimal, preferred solution at a particular moment in time. With correct defined this way, as it is in practice by developers, correctness changes on a fairly regular basis, and can vary wildly from developer to developer, leaving behind it a wake of inconsistent, bug ridden, unmaintainable code.

Consistency provides Quality

One time solutions, those built from the ground up without regard to previous work, have a lot of unknowns that can't be accounted for. Though estimates will be padded to compensate, developers tend to be overly optimistic about their skills and minimize the complexity of the problems. This leads to insufficient time being allocated for a task. When nearing the end of their allotted time behind schedule, having spent time they didn't have on problems they didn't account for, developers will push themselves even harder to meet the deadline by taking short cuts and cutting code quality. These solutions will have significant problems(e.g. bugs or missed requirements) and will take yet more time to get right. To the business it may look like everything is going reasonably well, despite a few defects and delays, but in reality the foundations of the project being demolished beneath their feet.

In contrast, when a developer knows exactly how something is going to be built, especially when they've built it that way before, then their estimates tend to be accurate and realistic, allowing the business to plan accurately and pull features or make other adjustments if necessary. Solutions that are repeated can be implemented quickly with relatively few defects and solidified over time, which is to say that if a bug is found in one implementation it can be quickly checked for and fixed in all. As unfulfilling as it may be for programmers, the only way to do it right every time is to do it the same every time.

Consistent code is Maintainable

When a bug is found or a feature needs to be added the first thing that a developer will do is look at the code to understand where changes need to be made. When consistent patterns are implemented then the developers have a very good idea of how the code works, where to look, and what to do, therefore maintenance will go smoothly.

If an existing pattern isn't working then the team as a whole needs to evaluate it and define a new one... and then go back and change all of the old code. If it's not worth fixing all the old code then it's probably not that broken. Only by establishing and enforcing team standards, patterns, and practices you can create a consistent and maintainable codebase.

Fail 1: Poor Communication and Lack of Documented Standards

Writing standards is an arduous task for most developers and being restricted by them can seem stifling. It's the old "Smart for one, dumb for all" adage. Each developer thinks "I'm skilled. I'm experienced. I should be able to decide how to do things!" but when everyone does this then their disparate ideas and standards will eventually collide (as developers are forced to maintain each other's code) and the codebase will become a nightmarish hodgepodge of one offs, cludges, and hacks. If developers don't talk about the problems they're solving and work together to standardize on solutions then the codebase is doomed to devolve.

Fail 2: A Search for Interesting Problems

Smart developers love to be challenged by interesting problems. These are the kinds of problems that developers will fight over and that the more tenured developers tend to take for themselves. These problems come up frequently early in a project but become ever more valuable commodities as the project matures. During a drought of interesting problems developers will look for problems that have been solved in less than optimal ways and challenge themselves with them. This leads to a codebase peppered with complicated, novel solutions; a complex, inconsistent codebase is the bane of maintainability.

Fail 3: Excessive Speed of Development

This is the biggest killer of code quality. Early in the project, in an effort to prove they are on track and on top of things, the business pushes the developers to produce too many features too quickly. This stifles developer discussions and standards at the time when they will have the biggest impact on the success of the project and future developer productivity. In addition each developer is likely solving many of the same problems in different ways with different levels of success and a great deal of time is wasted.

Developers respond well to, and can even thrive on light to moderate amounts of consistent pressure (this varies from developer to developer). Under too much pressure though they write absolutely horrid code and will sacrifice the code quality and pretty much everything else in order to meet a deadline. Sadly, early efforts to push productivity usually end up hamstringing the project before it ever gets off of the ground.

The Solution

As counter-intuitive as it can seem from a business perspective sacrificing productivity for communication, group problem solving, and team standards actually leads to significantly greater levels of productivity over time. This can be a hard decision for leadership to commit to. Commonly they'll pay lip service to it without actually reducing the pressure on the developers so they can follow through with it. Or worse they won't hold the development team accountable and the developers will shirk the hard work of putting standards in place. The only sane way to manage a project is to put code quality, consistency and standards first.

0 - What do you think?: