If you are new to an existing corporate project, you are fairly likely to find a code base that could use some improvement.
If you happen to be fortunate enough to have the project manager tell you that they have amassed significant technical debt and need to work on reducing it, then you don't need to read the rest of this post. Attend my 360Flex presentation or check back here for my slide deck in a couple of weeks to learn how to refactor responsibly.
I've tried using the reduces maintenance costs / increases bug fixing time arguments too. And frankly, when faced with a looming deadline, some clients have outright said "I don't care about maintenance."
Now I disagree. If you are working on a marketing campaign that has an expected 3-4 week life.... fine. Get 'er done and life is good. But when you are working on a project that has an expected life of years, or even in this case a decade or more... then it is insanely short sighted to not care about maintenance.
Clearly, timing is important... Don't propose an immediate refactoring initiative a month before a major deadline. Do however propose it for immediately after the deadline. From my experience, if you are not "agile", then your deadline is a major milestone... maybe even a release. This could mean that there will be a period of QA testing, acceptance testing, approvals, etc. For us, this was a time that the developers were supposed to work on documentation, as the code was "frozen". (I disagree with both of these statements).
This is the perfect time to refactor. If you need to "document" your code, then you need to refactor. Well written code is self documented. I'd also argue that writing unit tests are the best form of documentation that you can have.
But I digress, this post isn't intended to be about refactoring, it is intended to be how to talk about refactoring so that business will listen.
If you find that concepts like refactoring, technical debt, or maintainability are not working for you in terms of buisness buy-in, we've had some success with some others.
- "Future BIG IDEA" enablement
For us, it was the "new backend framework enablement initiative". This "sold" incredibly well. We were granted a 5 week sprint for enablement (refactoring)
It was during this "enablement" sprint, that this next idea really proved itself.
- Training / ownership
As a developer, refactoring is wonderful!
- The requirements are perfectly clear (do exactly what it is already doing).
- The end state is self defined (I can stop refactoring at any time that I've made any level of improvement, assuming that nothing has changed).
- Identifying what to change is clearly describable to any level developer ( code smells )
Actually, the results of this sprint were amazing! And I'm obviously not talking about functionality, as true to our intent -- nothing changed. But now, the transformation in the team was astonishing.
- Junior developers had dozens of light bulbs / ah - ha moments regarding their own and future coding standards.
- Everyone felt responsibility and ownership in the code base, which previously was more a lay blame / obligation. (see responsibility model )
- We all had fun. It was unanimously voted the" best time" in all of the project's duration
- The team of developers had transformed into the "team" (performing, in the Tuckman's_stages_of_group_development)
So if you need it... it is no longer "we need to rewrite this code".
Let, "we need to increase team ownership by enabling [The next big thing], before we start the next phase." -- be your next refactoring battle cry.