Let me tell you a story about a young developer called “Sue”.
Sue has just learnt all about eXtreme Programming. She has worked on an XP team with lots of pair programming, unit testing, refactoring, simple design etc and is totally converted. The world should be doing XP!
Sue hears about another application at her company which is in trouble. Let’s call the application “Squirrel”. Squirrel has been in production for a few years now, the codebase is rather large and the internal design is somewhat confused. The Squirrel team is having increasing difficulty adding the features the customer wants in a timely manner. Sue is convinced what they need to do is to refactor the codebase and add lots of automated tests.
Sue manages to persuade her manager “Paul” to let her work on refactoring Squirrel. She gets a copy of the code out of the version control system and sets about writing unit tests and refactoring. A few weeks go by and Sue reports to Paul that everything is going really well. She has solved some significant technical challenges in order to put in place some unit tests and has a small suite that she runs regularly. She proudly shows Paul the test scores and some UML diagrams of how the code looked before her refactoring, and after. Paul is pleased at how much better the UML looks and when Sue asks for more time to improve the code further, he grants her request.
A few more weeks pass and Sue is starting to attempt quite ambitious refactorings. She really feels the Squirrel team is going to be delighted when they see how much better their code looks and how many tests it has.
Meanwhile the Squirrel team has been continuing to add features and fix bugs and are actually quite proud of the progress they have made with the small team available to them. The users of the Squirrel application have complimented them on how much more stable and usable the application is becoming.
After a few months, Sue, Paul and the Squirel team agree that the next release of Squirrel should include Sue’s refactorings. The approach chosen is for the Squirrel team to take Sue’s copy of the codebase, and integrate all the recent bug fixes and new features into it. Everyone thinks this will be straightforward using the advanced diff&merge tools provided with the version control system. Sue persuades Paul that this would be better than applying all of Sue’s refactorings to the Squirrel team’s version of the codebase, since she had made so many sweeping changes and her codebase had extensive unit tests.
It was a total disaster. Sue had introduced a huge number of bugs when refactoring. Sue didn’t understand what the code was really doing, having never actually worked on the application before and having only the documentation to go on. She had hardly spoken to the Squirrel team in all the months she had been working on their code, even though their project room was a short walk from her desk. The unit tests she had written covered only a fraction of the codebase and often reflected her poor understanding of what the code ought to be doing.
The diff between the two branches of the codebase was huge and the integration work was difficult, time consuming and error prone. After a week or so the work was stopped, Sue was in the doghouse, “Refactoring” was a dirty word, and the Squirrel team went back to their old codebase.
So what went wrong? Sue clearly did not have enough understanding of the codebase in question and was not skillful enough to pull off the refactorings she attempted. She had too much faith in the few unit tests she had written and lent on them too much. Sue didn’t think about the integration cost rising exponentially the longer she worked apart from the Squirrel team.
However, I think it is Paul who really carries the blame for what happened. As the manager responsible for both Sue and the Squirrel team, he should not have allowed Sue to continue working alone for weeks on end producing only UML diagrams and unit test reports. Paul should have anticipated the integration problems even if Sue didn’t. He should have asked to see working code – if he had sat down and manually tested Sue’s copy of Squirrel, he would have found serious bugs within minutes.
Well, thankfully Sue wasn’t sacked immediately and was given a chance to redeem herself. Sue joined the Squirrel team and started working on bug fixes and customer features. She quickly gained more understanding of the code than she had ever got working alone. Sue did put in place a few unit tests and do some refactoring, but it was always in the context of whatever bugfix or feature she was working on at the time. Most of the big sweeping refactorings that Sue thought would make a difference were never implemented.
The customer was happy for a while but the pace of new feature addition was still a bit slow for them. The customer also discovered that they could get a much better product from a competitor. So a couple of years later they dropped Squirrel. Happily for Sue, by then she had found a better job with a more competent manager.
