Developer buy in

The refactoring project rolls on and the code gets better. This week saw a marked change in attitute from some of the developers on the team…

I was originally brought into this project because the lead developer was leaving and other developers within the team were unhappy with taking over the project as they were scared of the state that the code was in. Management accepted the need for change and welcomed the incremental improvements that my original report on the project proposed. The other developers were unsure and, though they didn’t want to take control of the project, they also didn’t really want to change how they did things. This week that started to change…

People have got used to the idea of using a source control system properly. We’ve done several nicely controlled releases followed by patches to fix bugs. Whilst that’s been going on we’ve progressed major refactorings on another branch and integrated the changes when we wanted to release. Things are much more controlled than a month ago and minor releases are no longer a time of stress and worry as we know exactly what has gone into each one.

One of the other developers is working on some new functionality on his own branch. He’s come across a point where the existing code is in a very bad way and where he knows that just hacking in his changes will be bad for the project in the long term. He’s under time pressure to complete his functionality. Up until last week I’d have expected him to just hack in the changes. The existing team have been in ‘just get it done’ mode for so long that even though they know they’re building a rod for their own back, they still hack stuff in rather than think about the long term effect.

This week he called me and his manager into a meeting and told us straight that the area he’s about to work on needs refactoring and that might take longer than just hacking in his fix. He pointed out that hacking in the change will make it very hard to continue to maintain this area of the code but that he doesn’t think he can hit his deadline if he has to refactor the code. He suggested that I add this area of the code to our list of danger areas and that he hack in his changes to meet his deadline but look at refactoring after. We decided that since this was an important area of code we’d make it the highest priority for refactoring and that I’d look at refactoring it in parallel with him hacking in his changes.

Good result. The tide is turning.

Just after this the manager, who also codes, had a bug report to deal with and took a quick look at the code and decided it was an easy fix. He sent out an email to the users saying that they could have their bug fixed in a patch release that afternoon and then started to work on the bug. Unfortunately the bug was in The Heart of Darkness - the most twisty of all the twisty code. His simple fix took a day and a half to get right due to unexpected side effects and a general lack of design in the area of code that needed fixing. He slipped his release by 2 days and we ended up pair programming to get it done.

I’d already flagged up the fact that simple changes in this area were likely to take far longer than expected due to the poor design but there’s no better way to get this kind of point across than have the guy responsible for making the call try and make a simple change and fail ;)

The good news is that we’ve now added The Heart of Darkness to the refactoring list as a high priority item. The bad news is that it’s still a very scary piece of code.