The Economics of Legacy Code

The final keynote for the SPA 2008 Conference was given by Michael Feathers from Object Mentor on the economics of managing legacy code.

Michael set the scene by mentioning some classic references including Freakonomics with regards behavioral economics, the Social Atom with regards how people behave in groups and the Big Ball of Mud which describes a common software architecture, the haphazard or casually structured system with a challenge 'do we believe it or do we ignore it?'.

He compared a Normal distribution curve with the Power Law curve stating that a power law appears in many aspects of life where preferences can be made. He then cited that if a distribution of method size across a project is plotted, it follows a power law and not a normal distribution. Intuitively you would expect uniformity with a clean design but suggested that this might be unnatural (maybe this is boutique design?). Personally, I think that unless the development process is actively managed, there will always be differences in the approach developers, primarily based on previous experience; this is a demonstration of the creative process of development.

There are some obvious reasons why organisations have difficulties in maintaining code:

Too many ways of Solving the Same Problem

As an example of showing that there are many ways of solving the same problem, Michael cited Perl where there is little consistency between two programs as there are multiple ways of doing the same thing. This clearly leads to difficulties in maintaining other people's work.

The Organisation

Another law, Conway's Law demonstrates that the software reflects the organisational structure that produced the software; it is often easy to see that different teams have worked on the project (see later for a personal view on this). Michael posed the question 'Can organisations align with the software to be produced?' and hence produce more maintainable code. Maybe....

• Public bodies have a short-term view as they control expenditure
• Organisations in the 'competitive milieu' have a number of options:
1. Software impacts the bottom line such that some changes may make the software better and hence benefit the organisation
2. Hyper-competitive organisations where software becomes a mess as the organisation strives
3. Monopoly organisations become lethargic asking 'why does it matter?'

Within a development team with dedicated people assigned, it is highly unlikely everyone will have an equal workload. Michael suggested that development should be subject to 'collective' ownership . This is one way of recognising that there are never enough good people to go round. This led to a discussion on professionalism which stirred up some interesting views.

My comments

1. I believe that code should be seen by multiple developers with continuous review. Pair programming achieves this with 2, but other practices can also lead to multiple views of the code with a reduced tendency to claim code as a personal asset rather than a team asset
   
2. Ensuring code is maintainable is not normally the primary goal of any developer; it is to get the task in hand done, hopefully on time. However, if there are good development practices defined at the start of the development which are managed consistently then there is a greater chance of achieving maintainable code. Given the increasing tendency to have off-shored development teams, then the managing the consistency of the development almost certainly mandates good tooling. As another session at SPA2008 showed, if this isn't done then the architecture and design will decay until it can no longer be maintained.