We have heard a lot of times that for the end user, the UI is the system. Well, in my view the answer is partially correct. Agreed that the UI gives a pleasant feeling and makes you stay on the site for longer. But would you stay on the user cool looking site if the pages were taking 30 seconds to load? Probably not.
The same holds true for project stakeholders. They might get easily impressed with the UI and cool looks of the system. This may prompt them to either pat the back or kick the butt of the development team. But, there is more to the system than what meets the eye. The stakeholders should also be looking at the quality of the crutches on which the cool UI is standing. Does it remind you of a beautiful facade which is supported with decaying wooden frame on the backend?
In a recent post on InfoQ, I talked about the value and the reason for monetizing the technical debt that the system has. Using the technical debt plugin from Sonar, it becomes very easy to assign a monetary value to the technical debt of the system. Not only does it give the stakeholders an idea about how good the system is but also lets them know if there is a need for further investment into the system.
As Israel Gat suggested, adding monetary value to the technical debt helps in the following
- Tells the teams when to stop development and start refactoring to keep the debt low.
- Customers and VC get an idea of how risky is it to use or invest in the software.
- Helps the stakeholders decide on how much affordable the software is and whether it makes sense to keep the development going on
- Stakeholders can define credit limits on the technical debt and as soon as technical debt increases the credit limit there is a strong alarm for the decision makers.
- Also helps the development team to analyse the cost of the software.
So assuming that you have a perfectly well done UI for the POC and everything looks hunky dory, it still makes sense for the stakeholders to look at the Sonar plugin report.
The Sonar plugin report would look something like this
This report would give the stakeholders an immediate snapshot of the amount of effort it takes in man days as well as $$$ to get the technical debt resolved.
How is the calculation done?
The cost is calculated by first figuring out the debt which is
- Debt(in man days) = {cost_to_fix_duplications + cost_to_fix_violations + cost_to_comment_public_API + cost_to_fix_uncovered_complexity + cost_to_bring_complexity_below_threshold + cost_to_cut_cycles_at_package_level}
There is a default cost in hour associated with each of the above violation. For example
- cost_to_fix_duplications = {cost_to_fix_one_block * duplicated_block}
Now, as per the defaults cost_to_fix_one_block = 2 hours. Assuming that the average developer cost is $500 per day and there are 8 hours to a day then to fix one such block $125 would be spent. Likewise, monetary analysis can be done for each violation to finally arrive at the total technical debt.
So next time when you are just looking at the UI and feel what a great system it is, or you are looking at a completed POC and wonder wow how fast the development team is working, just make it a point to look a bit deeper. There may be bigger surprises awaiting you when you turn the rock. Be Very careful!
Inphina has carried out several audits and helps organizations develop better software. If you are interested in our auditing and better software services then please contact us by sending a mail on audits@inphina.com
1 thought on “Don’t Judge an Application by the Looks3 min read”
Comments are closed.