Reduction of code review costs
Improvement of software reliability via early defect detections
Better reactivity with accelerated decision-making
Greater productivity via optimized quality monitoring along development and maintenance phases
Enhanced team collaboration and best practices adoption through a shared reference tool
“ Every minute spent on not-quite-right code counts as interest on that debt » Ward Cunningham
Technical Debt indicators are particularly appropriate to start your Software Quality Management project.
Initially invented by Ward Cunningham in the 90′s, the Technical Debt is those tasks (feature, bug fixing, code refactoring, architecture optimizing, etc.) that a development team would -whether willingly or not- delay to a further sprint or product release.
It immediately provides the team with a breath of fresh air, but as any other borrowing, the later you’ll reimburse the higher will be the interest rate. In other words, if a feature costs 100 to be developed today, it will cost 100 + something tomorrow, 100 + something higher the week after and so on.
Thus, the higher the debt, the lower the innovation and competitivity.
In order to avoid this loss of productivity and reactivity, the SQUORE dashboard integrates packaged Technical Debt indicators, and proposes in its action plans refactoring priorities for a quick and cost effective reduction of the debt.
Technical Debt, an indicator with high ROI
• Relevant and Useful : it’s a well-known fact that Technical Debt heavily weighs on teams agility and their innovation capacity. A high Technical Debt means important efforts allocated to corrective maintenance, to the detriment of the added value of new features delivery. A tech debt indicator will highlight the quality gap of software artifacts, in regards of product quality requirements (robustness, security, reliability, maintainability, etc.) and the nonconformities found in the project.
• Easy to understand: Technical Debt speaks for itself when displayed in UOW (time, money…), from the CIO to the developers through DevOps. Workload of each postponed task -or delivered but with an unexpected level of quality- is summed up to measure the total debt of an application, a project or an artifact. For example: we’ll need to allocate 10 man-days to make the project conform to reliability requirement, as defined in our quality model.
• Easy to deploy : at its simplest, Technical Debt is computed by cumulating workloads of non conformities. Thus, your first attempts to measure projects debt can be led done into just an Excel sheet.
• Reconciling managerial and technical visions: by providing the stakeholders with a relevant, understandable and non-ambiguous information, they use a common framework to act on real software quality issues, rather than discuss the definition of the indicator itself.
• Task-oriented and objectified, by nature: this is a huge advantage of the Technical Debt indicators. Computed from non-conformities found into the project (code, documentation, requirements, etc.), it allows you to list the necessary actions to reduce your Technical Debt with an extreme ease, in an efficient and objectified way.
SQUORE Technical Debt, an action plans oriented dashboard
Building on Software Quality Management projects that our consultants led, Squoring Technologies defined and packaged Technical Debt indicators in a dedicated version of the SQUORE dashboard. These indicators come with ready-to-use quality models that can be easily customized to fit the context of your project. In minutes, the solution allows to deploy a primary level for an effective management of Software Quality.
SQUORE Technical Debt solution integrates Technical Debt among project monitoring indicators and provides action plans including refactoring priorities for an effective and cost effective reduction of that debt.
• A turnkey analysis model, with standardized control points to measure and manage the quality of developments: evaluation and monitoring of Technical Debt evolution based on the SQALE method (Software Quality Assessment based on Lifecycle Expectations), a standardized method for computing the Technical Debt.
• A rating system that is easy to understand (with A, B, C, D, E and F grades) and provides accurate information (Technical Debt estimates in man-days or currency…).
• A fast highlighting of risks and quality issues in a projects portfolio, thanks to unique drill-down features through the quality characteristics and into the software components (projects, packages, methods, functions, etc.).
• Indicators taking into account not only code-collected data, but also functional requirements of the project, quality of the documentation, etc…
• Task Plan generation, optimized to efficiently reduce Technical Debt of your projects, based on standard and project-custom quality requirements.