The second day of QCon 2010 started with a keynote by Ralph Johnson (GoF author and refactoring pioneer) on the topic of aging software. Ralph began by asking the audience to raise their hand if they had been involved in their current project since it’s inception. Approximately 50 percent of people present raised their hands enthusiastically into the air. This is a far higher percentage than I had thought and Ralph pointed out that this number is unlikely to representative of the industry as a whole. Attendees at QCon are typically experienced developers, leads and architects. The type of folks that love to work on new exciting projects and move on to pastures new as projects enter their typical “business as usual” phase. According to Ralph 98 percent of software developers were likely to have not been involved at the beginning of projects that they are work on. As an industry we have long recognised that software often lasts much longer than original anticipated.
He then moved on to discussions of the word legacy and it’s negative connotations in the software world. Legacy code was described as:
- Code with poor design;
- Code that is difficult to understand and change;
- Code developed with old/unsupported technology;
- Knowledge of the original architectural design vision has been lost;
- No tests.
The argument was made that clean code and a comprehensive suite of tests is not enough to document a large system. I tend to agree with this view as I have seen large code bases where the tests do not always describe the behaviour of the application clearly. I refer to such applications as modern legacy. High level architecture diagrams (boxes and arrows) are invaluable for seeing the bigger picture when working with large systems.
The audience were treated to an entertaining story involving a large software organisation who spent huge amounts of time and effort obfuscating their code base before handing the source over to a partner. The code base in question was developed over many years by thousands of developers and was extremely difficult to understand, even with the source code. In fact to cope with this challenge the most effective developers in the organisation created an informal support network, where over time people came to recognise who had knowledge of a particular areas. The most effective problem solvers were not necessarily great debuggers, but rather good communicators. They knew how to ask for help. Ralph went on to joke that the best thing that this organisation could do to get the upper hand over their competitors was to give them the source code. He predicted that their competitors would go out of business long before they understood the software.
Then next question considered was: what is the capitol investment in software? History has shown that as an industry matures entry becomes more expensive to the point where it becomes prohibitive. Taking the automotive industry as an example it is getting extremely difficult for established firms to remain competitive yet alone starting from scratch. The same pattern has not held true for software. Whilst it would be extremely challenging to create a product to compete with the mighty Microsoft Word, our industry (putting aside the recent economic challenges for a moment) still supports start ups and allows the creation of great products by small teams of talented people. It therefore seems reasonable to think of the capitol investment in software as being talented people and their knowledge.
Software maintenance was defined as “all the work you put into a software system when you decide it is going to be replaced” and the audience were encouraged to think about ongoing changes to an aging application as evolution. The motivation around this viewpoint is to avoid the stigma sometimes associated with maintenance roles in other fields categorized by lower salaries and less privileged academic backgrounds. Of course, this stigma soon disappears when ones washing machine breaks. Few, if any, raised there hands to the question: “who is a maintenance developer?”. Ralph suggested that once a piece of software truly enters it’s “maintenance” phase then perhaps it is acceptable to approach development with little thought about the future state of the codebase. In context of an application with a firm date for decommission this may well be a sound strategy. However, the challenge we face as an industry is that even software with an end of life date has a nasty habit of lasting a lot longer into the future, typically in the response to the replacement system not being ready.
Refactoring, was of course, promoted as a technique to assist in the evolution of a software system through a series of small disciplined steps aimed at improving the design whilst maintaining application behaviour. Ralph warned against the dangers of “refactoring projects”. The main objection to this style of development is that it is completely counter to the original refactoring mindset, where small improvements are made on a daily basis to make new features easier to add. The very notion of a refactoring project indicates that the design has been neglected over a long period of time to the point that features are becoming prohibitively expensive to add. Ralph used the analogy of flossing daily versus root canal surgery and reminds us that as soon as senior management start talking about refactoring we know we are in trouble. If you do find yourself taking part in a refactoring project – be sure to have a clear direction of where you are heading and work in small steps.
In summary this keynote covered topics that were generally well understood by the type of audience QCon attracts. However, it was great to hear thoughts on software evolution from one of the early refactoring pioneers. My main takeaway from the keynote was that as a profession we should always seek to encourage healthy relationships between academia and industry. The mainstream adoption of refactoring is a combination of researchers (Bill Opdyke, Don Roberts) and passionate evangelists such as Fowler and Beck working together to bring these ideas to the masses with the classic Refactoring book.
One final thought from the keynote: in twenty years some programmers may be working on software older than they are.