I last talked about how wild estimates affects a team with unfactored code. Now I want to look at another impact on the team that is even more dangerous.
In order to produce a great application, every team needs to work as a team. They should want to help each other and go out of the way to make it easier on another team member. When code isn’t refactored it puts a burden on the other developers on the team.
I’ve been on a team who was hit really hard by this. The codebase was huge, with tons of legacy code and written in a programming language that is barely used anymore.
One of my first assignments was to add a standard header and footer to the reporting engine, about 70 reports in total. The code for the header and footer were simple; just the report name, page number, and total number of pages. But because the system was never refactored, it took me several days of work in order to finish the task. I can really get into my development and focus, but I have never been so bored “developing” in my entire life.
This feeling was common with the rest of the development team. There were many smart people there, the majority of them way smarter than me, but they were chronically depressed working on the code. Everyday someone would make a joke about how bad the code was or what stupid function they found the day before.
One solution the company had was to rewrite the application in a modern language with newer tools. Unfortunately, that would take a couple of years to complete and several of the developers would still have to maintain the legacy version until the rewrite was done. The rewrite was still started but it caused a major split in the development group:
- the team who was working on the new cutting edge application
- the team stuck working on the legacy version
The big problem the original application had was, the massive code duplication caused everyone on the team to be bored and angry working on it. There were frequent outbursts of “Who wrote this $%#@& code?!?!” and the code reviews where a constant stream of WTFs. This put the development team in conflict with everyone: the other developers, the testing staff, the support staff, and even the customers who were asking for a change. This caused every change request to be immediately rejected by the developers, even if it was in the best interest of the application.
A lot of these problems could have been fixed or improved by just taking a few extra minutes every day to refactor the code. But they never did and the entire team is still struggling.