DZone
Java Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Java Zone > Cost of Correcting Rule Breaks

Cost of Correcting Rule Breaks

Nicolas Fränkel user avatar by
Nicolas Fränkel
CORE ·
Mar. 07, 11 · Java Zone · Interview
Like (0)
Save
Tweet
4.13K Views

Join the DZone community and get the full member experience.

Join For Free

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

tech debt IT Project manager Ward Cunningham Vaadin Concept (generic programming) EGG (file format) teams Dependency

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Why Great Money Doesn’t Retain Great Devs w/ Stack Overflow, DataStax & Reprise
  • Growth in Java Development for Web and Mobile Apps
  • 10 Books Every Senior Engineer Should Read
  • 6 Best Books to Learn Multithreading and Concurrency in Java

Comments

Java Partner Resources

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo