Home > Development > Cost of correcting rule breaks

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?

Send to Kindle
Categories: Development Tags: ,
  1. Carsten Behring
    March 7th, 2011 at 13:45 | #1

    I share completely what you expressed in your article. Th problem is that i think it is very hard to associate costs with “leaving the rule brake in”.

    It depends on a lot of factors, of which most are maybe not even in the code itself. I just list some of these factors, as they pop out of my mind.

    1) Will the code which has a lot of rules broken ever be maintained ? If the code is never, ever changed (or read) again, the price might be low.

    2) Will it be the original developer, which needs to change / read the code ?

    3) Are their releases planned anyway, or would we need to make releases just for “rule fixing” ?

    All this are project management decisions, which are both, not visible in the code, neither known in a lot of cases.

    So any calculation of “costs of not fixing broken rules”, needed to ask this to humans and quantify it.



  2. Alexandre Victoor
    April 28th, 2011 at 09:30 | #2

    This is a little off topic regarding the subject of your post. I am currently evaluating vaadin and so far I think it is a great RIA solution. I am really curious about the reasons why it has not been choosen for sonar… If you can tell us more about it that would be really great 🙂
    Anyway, I look forward to read your book on vaadin.

  3. April 28th, 2011 at 11:26 | #3

    The best person to ask it is Simon Brandhof. Btw, you can already get the book as a work-in-progress at a discount (and you’ll get the final version of course) at https://www.packtpub.com/learning-vaadin-7-0-rias/book.

  1. No trackbacks yet.