Working Effectively with Transitional Code (Part 1)

Thanks to M. Feathers for the title inspiration.

Many companies today are struggling. As the economy contracts, they have started to look for new ways to become more efficient. Some have recognized the benefits of Agile methodologies, and have started to make the transition. These transitions can be lengthy, and if done improperly, painful and costly. A problem that I've started to see more and more among companies adopting an agile mindset is the stalled transition.

A stalled transition occurs when an organization:

• Partially adopts agile practices and/or principles. Some teams and individuals fail to make the transition and revert to old habits.
• Adopts practices that have been modified for expediency by mandate, rather than for effectiveness through team retrospectives.
• Fails to adopt sets of practices that are interdependent (Continuous integration without automated testing, for example).
• Mandates agile practices blindly, without understanding their benefits and effects.

For example, an organization may adopt some of the project management practices of various agile methods (Stand up meetings, planning poker, user stories) without adopting the technical practices that make those management practices effective (Test Driven Development, Continuous Integration, Refactoring). 

The result is, quite often, a mess. Projects managed in this fashion typically exhibit a number of common characteristics. Test coverage is spotty. Many tests make trivial assertions like checking for nullity of a returned object. Some tests make no assertions at all, which makes any code coverage metrics highly suspect. Builds often take 30 minutes or longer to complete, not due to any inherent complexity, but simply due to poorly written tests that run slowly. Refactoring is not done mercilessly, if at all, and so the the level of code quality is low and dropping. Quality standards are only intermittently applied. Pairing is rare or non-existent, and implicit code ownership silos start to appear "Give that task to Larry, he knows the UI better than anyone". 

As a result, the team may find it impossible to make frequent deliveries of working code. Customer demos are full of hand-waving and special cases, and the product is most certainly not ready to ship. When it does ship, defect counts and high, and stakeholders are often disappointed with the result.

I call this mess transitional code, and it is a serious and increasingly common problem. Adopting iterative and incremental project management practices without rigorously applying iterative and incremental technical practices is recipe for disaster. 

This is the first in what I hope will be a series of posts on this issue. I believe its resolution is critically important to the Agile movement.

Comments

[Mr. Hericus]

While you don't have to pick up the entire stack of Agile methodologies, you do have to ensure that the ones you pick up won't leave you in a worse state. Completely agree with your statement about implementing continuous integration without automated testing. It just means you build the same broken (functionally) code again and again without realizing that something really went wrong quite a while ago.

Thanks for the post!