Cost of Correcting Rule Breaks

Last week, Simon Brandhof and Freddy Mallet of Sonar team and me were discussing Vaadin uses. At the end of our meeting, and although Vaadin finally did not fit their particular needs regarding Sonar, the talk disgressed toward quality.

As regular Sonar users know, the former includes a very interesting plugin aptly named Technical Debt plugin. As a reminder:

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise

Ward Cunningham

So, this nice plugin monetarizes costs associated to a rule break in a project. It’s a long way from nothing, but still is only a one-sided argument. Let me explain: we, whether as architects or developers are technical-oriented people. The problem lies in that correcting rules breaks are not a decision made by us technicians. They are made by managers that tend to have a different mindset. I’m apologize to managers, but I will speak in their collective name: my observations so far led me to believe that managers think in terms of costs and risks (correct me if I’m wrong).

What’s good is that the aforementioned plugin assign a reimbursement cost to each rule break: it speaks to managers. They know what it will cost to correct the break. Cost is calculated from a simple formula: time to correct (including locating the right place, checking out, correcting the code itself, checking in) times salary cost. On the opposite side, and in order to take the right decision, managers have to know the costs associated with not correcting. There lies the rub: how can we provide that?

Now, us technical people, we frown at the breaking of a rule, either because it’s genetic, or from hard won experience. As for me, I made my part of crap when developing, but I learnt from it: for example, I can now understand why cycle dependencies is bad because I coded it and had to deal with its associated problems (uh, what do I compile first?). Nowadays, I can tell it’s bad, why it’s bad and do all I can to avoid it. I could even assign a cost to some specific cycles, but it will only be gut-feeling and likely to be challenged by any project manager who is evaluated only on planning and costs (and who don’t give a damn about maintenance).

Do you see the whole picture now? On one hand, we quantify the cost of quality with the technical debt concept and Sonar plugin, but on the other hand, it’s not possible to do the same for “won’t fix”. We can evangelize all we want about quality, there will be only agonizing slow improvement regarding quality as long as we cannot monetarize both costs.

Solutions? It would take some time, but we could create metrics, that will be refined with each project, and that could lead to some average cost for each rule break. Unluckily, that requires an already present quality-oriented mindset that is our target. Who said chicken and egg?

From http://blog.frankel.ch/cost-of-correcting-rule-breaks