Yesterday I came in close contact with the horrible stench of a backport. No one really likes backporting code (all good programmers can identify the risks involved) but this one turned into a real stinker when a few other volatile elements were added to the mix. A poor release plan resulted in a day-before-the-release backport, and the release cycle that has been slipping further away from development cycles meant that the code required backporting into multiple branches! Why a stench?

“Code smells” were made popular by the Refactoring book by Kent Beck and Martin Fowler. It has an appropriate name because when you encounter code of which you consider a bit sketchy, a certain foulness tends to surround it. Going hand in hand with code smells is another group known as anti-patterns with the major difference being that they are known patterns that solve a problem but are known not to work (especially over time). Personally I don’t think that the concept of a smell applies only to code but also can apply to the processes that surround software development.

Agile methodologies attempt to address the smells that traditional software methodologies (such as RUP or waterfall) typically reek of. However don’t assume by any means that ‘doing agile’ automatically defends you from such smells because like most other types of bad smells, they tend to be produced by people in execution instead of the processes themselves. I’m undecided as to whether or not what I experienced was really a symptom of a bigger smell or if it should be considered a stench on its own. Either way, I think something needs to be tweaked to prevent more of these happening in the future.

Here are a few reasons to avoid the backport stench:

• Release and development cycles fall further apart, adding administration overhead to what parts of the code base are to be released.
• Each release costs more for the business as more development time is spent carefully isolating groups of functionality for release. Thankfully small iterations help in isolating groups of changes, but I shudder to think about performing these in non-agile environments.
• A whole new class of bugs is more likely to be introduced (caused by errors in the backporting process).
• Communication with the business becomes more difficult as the groups of what is being released, what has been completed and what is being worked on fall further apart.
• Testing resource requirements are increased as more work is being generated (as testing is required in both the trunk and each branch to which a backport is performed).

Ways of preventing this bad smell include:

• Release planning that actually requires some real planning… The plan should not just consider the immediate future (i.e. end of the week) but should encompass at least the next few weeks. Part of this is ensuring that the release manager appropriately juggles business priorities and communicates these intentions to developers in advance.
• Don’t promise hard deadlines. Promising dates will come back to bite you (because everyone wants what they want as soon as they can get it) – If you can demonstrate that releases can be delivered frequently and are of high quality, the delicate balance between IT’s strained resources and business needs can be met without hard deadlines (I’ve seen this work first hand for the last couple of months!). Short iterative release cycles work well to meet business needs because they realise that it is easy to get functionality out and there is less pressure to ensure that everything is added to the single iteration. Therefore keep in mind that the promises of releases on specific dates should be reserved for extremely special cases.
• The closer each release is to the current iteration that the development team is working on ensures a higher standard of code by ensuring that bugs found in production are quickly addressed and released to production.