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.

If Software Teams Made Cars

...these requirements would be accepted:

  • Must have 4 Wheels
  • Must have brakes and steering
  • Must have a way to get in
  • Must be reddish orange

...this mock-up would be approved:

photo by marcmos

...the developers would plan to make this:

photo by jarm13

...the business would expect this:

photo by djbwhizz

... the customers would actually want this:

photo by earthworm

... there would only be enough time to make this:

photo by jdueck

And the kicker is... all the "defects" would have to be fixed while it was being road tested!

Note: Regarding this post... gross exaggerations and stereo types have been used liberally in a fictional context for comedic effect. Any similarities to the development practices of employers past, present, future, or in parallel universes is purely coincidental, depressing, and sad.

The Devolution of Code

The more intense the demands of business or market forces acting on a system, the faster it will change. Unlike in life though, natural selection in software does not favor evolution into a higher state; instead code naturally devolves.

Photo by MangPages on Flickr

Why? Because writing bad code is easy and writing good code is hard. Because with every change to the code there is an increased chance for a reduction in quality. Poorer quality code is more likely to survive because it's difficult to understand and time consuming to fix. It is also more likely to devolve further with future changes. Without intervention a downward spiral of code quality occurs.

The rate of decay of a system is determined by three factors:

  1. The quality of the team
  2. The speed of development
  3. The size of the system

The Quality of the Team

A weak team can't develop a strong code base; it's just impossible. Beyond the maturity of the team and knowledge of the individual members, both the team and their manager must have a strong commitment to the internal quality of the project... because they're the only ones that can. No one else knows what trade offs have been made to meet deadlines. No one else knows what pieces of code have become muddled and difficult to work with over time. So too, no one can advocate for code quality except the team.

Speed of Development

The faster the project moves, the less time there is to discuss, design and refactor the code. A emphasis on time to market over quality and design can pay off for a little while but only at the expense of an ample amount of technical debt. Problems occur when management (usually upper levels) doesn't recognize the cost of this initial boost of speed (i.e. time saved must be paid back later with interest) or worse yet, expects it to be sustainable.

Unfortunately prioritizing speed (the rate at which new features are added) produces ever diminishing returns because reducing internal quality slows things down. As the project becomes more brittle defects increase and features become harder to add. A vicious cycle ensues.

Of course this could be easily fixed if the business allowed time to clean up the codebase by drastically reducing or halting time spent on new development. But that's unlikely to happen. You see the business views development time as an expenditure not an investment. From their stand point they've already paid for these features once. They're done! They work! Time spent refactoring them only increases the cost of those features. From the business view point you're asking them to pay for the features twice! Crazy!

Size of the System

The larger the system grows the more time it will take to add features, the longer the learning curve will be for new people and the more people you will need to handle the work load. The less code you write the better, because the smaller the code base is, the less code has to be maintained and the more well-designed/well-factored the code that's there is likely to be.

Because of this an effort must be made to fight unnecessary features, get rid of seldom used features and otherwise constrain the size of the system. You have to pick your battles. That new feature that's going to add 10,000 lines of code, turn your code base to swiss cheese and only be used by 3% of users... that's the one you better fight.

The bottom line is, do what you can to stem the rising tide of code; even small victories can have a major impact down the road.

How to Fix this Mess

You need to focus on code quality as much or more than you focus on defect count. While a rising defect count can be a symptom of reduced code quality, defects are actually a measure against requirements not code quality. Given enough effort it's possible to get a project with abominable code quality into a defect free state; it just really hard to do and even harder to keep it that way.

The sad truth is that in most places a balance is reached. Projects become mired in mediocrity and just enough upkeep is done on them to keep things from falling apart completely. Developers who have been on a project like this a long time tend to be disheartened as years of disappointment and frustration can quench the most ardent fire.

Fortunately there is an ebb and flow of programmers on every team and you can use it to your advantage. Each programmer that leaves offers you a chance to make things better. Find good people, passionate people to replace them. The right person can stoke the fires of existing team members and breath new life into the team. Set them loose and help them break the status quo.

Set standards and expectations early and review them often. Do whatever you can to keep the speed of development and the size of the codebase manageable. Every week try to make things a little better and don't give up.