As we quickly head into the new year - the Consortium for IT Software Quality (CISQ) is working to develop a new measure for technical debt. CISQ has created standard measures for software quality in the areas of: reliability, security, performance efficiency, and maintainability. Technical debt carries across all these areas, and this new measure will as well. It will take into account the amount of work required to get rid of debt.
In order to create this measure CISQ will be surveying developers by asking them to evaluate 86 defects that violate the aforementioned quality characteristics and have them respond with how long they think it would take to clear each defect.
Dr. Bill Curtis, the Executive Director of CISQ, says that this is something that executives want - they want to know how much debt they have and how much it is costing them. As it stands, development teams are consistently pressed for time when it comes to developing a new feature or setting aside time to removing technical debt. And the new feature always wins. Technical debt is then left to accrue until it reaches a point where work grinds to a halt, or there is an increase in security risk, or teams are unable to scale. Having a measure on technical debt for executives will allow for a process to take shape on how to deal with technical debt.
The question that most often arises once technical debt becomes a problem, is whether to throw out the whole system or to reengineer the problem areas. The answer to this really depends on the processes you have in place from the executive level. If you spend time within each sprint to fix defects than there may not be a need to throw out the whole system. It really depends on whether your debt lies at the system level, making it more difficult to fix, or whether it is localized in one module within an application.
It is a new trend for auditors to ask for risk measurements that can impact an organizations profitability and performance, and this information needs to be included in a company's 10k annual statement. It is therefore helpful to have a standard measure of technical debt that can be used in evaluating risk and performance.
CISQ hopes to have information from their survey information compiled by mid-January and be submitted to the Object Management Group (OMG) as a proposal by February. This will begin the process of making the technical debt measure an OMG standard.
To read the full post visit here.
Erik Oltmans, an Associate Partner from EY, Netherlands, spoke at the Software Intelligence Forum on how the consulting behemoth uses Software Intelligence in its Transaction Advisory services.
Erik describes the changing landscape of M & A. Besides the financial and commercial aspects, PE firms now equally value technical assessments, especially for targets with significant software assets. He goes on to detail how CAST Highlight makes these assessments possible with limited access to the targetâ€™s systems, customized quality metrics, and liability implications of open source components - all three that are critical for an M&A due diligence.