Listen to the podcast Better code is cheaper to learn how the Software Improvement Group (SIG) is paving the way for software quality and maintainability.
Software quality is an often-overlooked development parameter, making way for those items that resonate outside of the engineering team – a faster schedule and an on-budget project. Joost Visser, Head of Research at Software Improvement Group (SIG) sat down with me to explain how a focus on quality helps to achieve the fastest possible schedules and lowest possible cost of development and maintenance.
Successful teams should have common understanding about quality.
Defining software quality
The first problem in treating software quality as a first-level concern is the fact that “quality is in the eye of the beholder.” The definition of software quality can vary from engineer to engineer and from company to company. So, the first step is to set quality standards for the team and project up front. For instance, code duplication adds unnecessary complexity to development and makes maintenance a confusing hassle. Visser suggests that one piece towards constructing a quality standard, a focus on duplication, could be to keep it to 3-5%. Many engineers know to keep duplication to a minimum, but without a stated decision at the beginning of the project, it could vary dramatically. You’ll note Visser doesn’t suggest aiming for perfection – a duplication rate of 0% – as that would be unrealistic, improbable, and would likely stall the project. Instead, his suggestion aims at a measurable improvement that has a positive impact on the project without slowing it down. Deciding upon a percentage of acceptable duplication is one example; add that to a list of standards and make sure that list is communicated to the team before the first line of code is written, and the quality improvements will be substantial.
Software engineering is… subject to the laws of economics.
Communicating the benefits of software quality
As with any business, the software engineering business requires trade-offs. A budget and schedule will be created with an eye toward the expected return on investment, the needs of the company, and available resources. Decisions like these may be handed down from management, but often will include representatives from the software engineering team. If you’re in this position, you must be able to communicate why software quality is so important. It’s not just for the sake of doing good work – it has repercussions that will reverberate outward and affect business goals. Amping up your engineering team around these quality practices is relatively easy; you all speak the same technical language, but when working with others across departments, you’ll need to be clear as to why quality should be a top-level goal. Visser and his team suggest that you set up a clear way to communicate, like a star system, where 5 stars represents “very good” quality code. No matter how you do it, you need to get this fact across: “Better code is actually cheaper.” That will resonate outside of the engineering team.
Better code is actually cheaper.
Maintaining that quality code
The maintenance phase of a software project is no longer something that will occur months or years down the line. It can begin as early as 10 days from the start of your project. So, the time you take to set quality standards – such as creating small units, keeping complexity low, and using the right libraries – will not only be economically sound for your budget, it will also make the job of maintenance easier to do.
What if you enter a project in the maintenance or upgrade phase? What if you can’t set those standards from the start because that start was three years ago? Visser suggests focusing on areas in which you can make a difference that’s apparent. Once you figure out the portion of the code base you’ll be working on, set quality standards for that section. An upgrade in quality in that one area can make a big difference to the overall project. Alternatively, sub-standard quality and performance of inherited code might be a reason to plan for a fresh start. However, before you even consider doing that, you’ll want some actual quality and performance metrics. While this makes sense when jumping into a project, it is a necessity for any project that you start – metrics are crucial to setting, meeting, and surpassing standards. Measuring how setting standards affects your project and those around it is essential to closing the feedback loop for continued balance and improvement.
You cannot control what you cannot measure.
Measuring the efficacy of quality standards
Creating quality standards is meaningless unless you know how those standards have altered or enhanced your project. Since quality isn’t inherently quantifiable, you must make sure to set up a way to measure outcomes objectively. Visser says, “Measurement is not the end of the discussion, it is the beginning of a discussion.” Metrics must be generated early and often, so that you can iterate on your standards and make sure the outcome is as expected. And, as with all raw data, you must add the expertise of your team to interpret this information and revise as necessary.
Measurement is not the end of the discussion, it is the beginning of a discussion.
Quality standards implementation and measurement provide your team with opportunity to write streamlined code, create better products, and steer the business to a better bottom line––but to make it stick, you must sew it into the fabric of your code base. Listen to my complete discussion with Joost Visser to hear more about how to make it happen within your company.
This post is a collaboration between O’Reilly and SIG. See our statement of editorial independence.