5 Effective warning signals that will get you sponsorship for a large scale refactoring
In 2005, professors Bizer and Petty showed something interesting about human behavior. People make more efforts to avoid what they don’t want, than to get what they would like. The study itself is interesting, you can have a look at it here. For example, it explains why political campaigns are getting more and more nasty. There’s also a lesson for us, mere developers. We’ll get more sponsorship for our refactorings if we highlight the dangers of not doing them !
This is the 11th post of a series about how to get sponsorship for large scale refactoring. If you haven’t already, start by the beginning.
From the inside, many systems are in such a messy state that seem like a catastrophe waiting to happen. Unfortunately, this mess is completely invisible to non-developers ! Here are a few techniques to show how close we are from a total breakdown !
Effective Warning Signal #1 Pranks
If you have the guts and your company is fun enough, you can try one of these pranks.
They’re bound to have a big impact … but they might also get you fired ! We should be creative and find both effective and acceptable pranks. Pranks are a lot more effective than we first think. Non-Violent Revolution activists have actually used Laughitism to take dictators down ! For a good (and unexpectedly fun) read on the topic, have a look a Blueprint for a Revolution. It was written by Serb non violent activist Srdja Popovic member of OTPOR!, who brought Millosevic down .
Promised, as soon as I manage to use such a prank without getting fired at work, I’ll blog about it !
Effective Warning Signal #2 Dice of Debt Game
While doing my researches for this article, I found the Dice of Debt game. It’s aimed at making business people experience the long term legacy code drag. It has good reviews, have a try at it with your business people and post back your feedback ! I’ll do so as soon as I have a chance to test it myself.
Effective Warning Signal #3 Higher authority
Appealing to a higher authority works as long as people recognize this authority as so. Knowing the people in front of us, it’s our job to bring up the reference in an effective way. Here are
In this talk, Doc Norton, a recognized technical debt expert, shows the link between technical debt and productivity.
Showing similarities between our own code metrics and this graph might ring the alarm bell in business people.
Another interesting model out there is A2DAM. It was built through the Agile Alliance. It can be used to estimate the value of a codebase when buying a company. Maybe business people will listen if we tell them that their software would be worth 0 on the market ?
Effective Warning Signal #4 Metaphor
I was recently working with a team that is preparing a pitch to get sponsorship for a refactoring. They want to rework multithreaded code that uses locks and other low level synchronization. The hand written synchronization is becoming difficult to maintain. They would like to refactor it with the actor model. Business people will likely argue that this module is now stable enough and should stay as is. We all know that this is not the case with bogus multithreaded code : the more you use it, the more bugs you find ! They had the idea to use the email vs phone metaphor. No one in the room could have handled all his daily emails with a phone only ! Everyone understood why it was necessary to switch to actors.
In A Taxonomy of Technical Debt, Bill Clark adds another dimension to technical debt. On top of the classic principal and interests he adds contagion. In fact, it’s a bit as if he’s ditching the technical debt metaphor for the disease metaphor ! Disease have a cost to live with, a cost to heal from and a contagion rate. People at the agile alliance also noted this self reinforcing behavior. This metaphor might be better for “cruft”. Ward Cunningham’s original metaphor of technical debt only applied to tested code.
💡 A disease might be a better metaphor than debt for code cruft.
Effective Warning Signal #5 A horror story
We said that a successful refactoring story will be useful to frame ours as an opportunity. We can have more impact with the opposite ! We should relate a large software failure, that had impact on the business to bad code. The bigger the impact on the business, the better it is. If you (unluckily) have something like that at your company, it should be a very powerful argument. If you don’t, try to find a public story on the internet, or a public conference. For example here is one from The 10 Worst Programming Mistakes in History.
💡 The Therac-25 (a radiation therapy machine) killed 6 people because it was difficult to perform automated tests !
We can draw parallels and forecasts, to highlight the high risk of failure.
Almost there
This was the 11th post in a series about how to get sponsorship for large scale refactoring. Unfortunately, presenting refactoring in a good way only brings us so far. If we want to be really convincing, we need to use quantitative data. That’s going to be the topic of my next post.
Leave a comment