logo-vector

Squoring Technologies is now part of the Vector Group

TechnicalDebt TrapToAvoid TooMuchAbstractIndicators 604x270

Traps to avoid for your project – #1 Deploy too much abstract indicators

Download our Expert Opinion

Download our expert opinion below and go further in building efficient quality indicators and discovering how to efficiently manage your technical debt within the SQUORE dashboards.

When talking about Software Quality, most articles cover best practices and development process to implement, in order to avoid that projects collapse under Technical Debt: identify risky components, do frequent code reviews, refactor complex artifacts, check coding rules, etc. However few guidelines can be found around the project itself: yes, deploying a solution for Software Quality Management should be considered as a project.

That’s why we, at Squoring, decided to share our hundred years of cumulated experiences on Software Quality Management tooling projects, in a blog post series dedicated to the traps to avoid when leading a Software Quality Management project. Let’s start with the first one: Deploying too much abstract indicators.

Trap #1: Deploying too much abstract indicators

This is probably the most frequent pitfall that we observed these last decades. Like in any other management project, indicators are strategic and will reflect your quality approach by making it concrete. Indicators are the main expected deliverable, and this is especially true for a Governance Program of your software developments.

In this context, the “trap” lies in the temptation to express the quality of a software artifact with a magical synthetic indicator, which would be built from numerous heterogeneous and conflicting data. In short, badly designed indicators would be like hieroglyphics in your dashboards: No one can understand them, even their own designer!

And when we fall into the trap, we usually get an unbounded value with no measure unit. In example: my application overall quality equals to 128, 72 for maintainability, 42 for robustness, etc. Doesn’t it ring a bell? As you’ll easily understand, these values do not mean much, when out of their context. Moreover, they raise some embarrassing issues that will quickly highlight the poor design of your indicators and will weaken your quality management program at an early stage:

  • Problems for developers and managers to well understand and communicate with each other
  • If an indicator is misunderstood, it won’t be adopted. In some cases, it will be fully rejected
  • The tool that computes these indicators will be challenged, replaced by some “homemade” indicators: this double reading will jeopardize your decision making and the resulting action plans

What is clearly thought out is clearly expressed!

The design of your quality indicators is a key step that needs time and attention. It must be clear, strong and indisputable, in order to allow your quality program to be understood, applied, adopted and continuously improved. Remind its essential role before building it: an indicator measures the gap between a situation and a target to be achieved, and helps you leading actions to reach your quality goal.

For example, one of my primary goals for my mobile application is its reliability during the exploitation phase:

  • I will make sure that the code is easily testable
  • I will also check if it has been effectively tested!
  • My reliability indicator will be based on the following data:
    • Code testability metrics (cyclomatic complexity of methods, coupling between classes, etc.)
    • Unit Test information, such as code coverage from tools like JaCoCo, Emma, Clover…
    • Data from function testing campaigns
    • To complete the picture of the reliability level of my software, I could also include information from load testing tools. Indeed, if my app is not able to support thousands of concurrent users, the unavailability due to performance and scalability issues would be considered as a lack of reliability.

The characteristics of an efficient quality indicator

Without diving into the specifications detailed in ‘NF X50 -171’ or ‘ISO 9001:2008’, we could say that an indicator is efficient when it meets the following requirements:

  • Relevance and usefulness: How well does the indicator point out the gap between the situation and my quality target?
  • Simplicity : a good indicator should be explained with a few words. Say what it does, do what it says, then check. It also must indicate if the target has been reached or not (see the « Goal Question Metric » approach by Victor Basili).
  • As a representative indicator, make sure it is:
    • Comprehensive : The indicators must be available for each level of your artifacts (portfolio, app, package, etc.). Actually, this point is made easier to cover with static code analysis tools that automate data collection.
    • Quantifiable : for example, code coverage metrics, total bugs found in execution, rule violations found in code, sum of new code lines delivered, average of days of delay for a delivery, etc.
    • Objective : the components of your indicators shouldn’t be controversial. What about the number lines of code to measure the size of a software artifact: Should we count blank lines? Commented lines? Only compiled instructions? Generated code should count as part of the software?
  • Deployability : It’s one thing to sketch your indicators on paper, but quite another to deploy and to make them “live” with real data. Often, the data is not in a proper format, scattered from different tools, or even does not exist at all for some artifacts. You will ensure the availability and the scalability of your indicators.

Technical Debt indicators: relevant, ready to use and easy to deploy

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.

Many IT companies (such as Squoring or Inspearit with the SQALE method) have implemented this concept to provide development teams with tools to identify and quantify the amount of their applications technical debt, generally expressed in days. Thanks to these measurements, these kind of indicators become powerful tools to pilot the quality of software development projects.

  • Usefulness: 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.
  • Ease of Understanding : 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.
  • Ease of Deployment : At its simplest, technical debt is computed by accumulating workloads of nonconformities. Thus, your first attempts to measure projects debt can be done into just an Excel sheet.
  • Reconciliation of technical and managerial 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 by nature: this is a huge advantage of the Technical Debt indicators. Computed from nonconformities found into the project (code, docmentation, 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.

Download our Expert Opinion

Download our expert opinion below and go further in building efficient quality indicators and discovering how to efficiently manage your technical debt within the SQUORE dashboards.

Leave a Reply

Current day month ye@r *