The Quality of Your Code Is the Quality of Your Brand
The Quality of Your Code Is the Quality of Your Brand
As every company continues their march toward becoming a software company, code quality is vital in every industry. Learn how to make sure its there from the beginning.
Join the DZone community and get the full member experience.Join For Free
Whatever new awaits you, begin it here. In an entirely reimagined Jira.
Successful companies must constantly innovate by introducing new technology to differentiate and improve their brands. A wide range of manufactured goods — from vehicles to televisions — increasingly rely on software to provide this differentiation. Many modern products have now evolved into complexly integrated technology platforms with embedded software powering their major systems.
These statistics from the automotive industry provide a great example of this: a modern car has more processing power than the Apollo lunar lander . An average modern high-end vehicle has more lines of code (100M) than the latest technology in the F-35 Fighter Jet (US Joint Strike Fighter) or the Large Hadron Collider .
Software quality plays a large part in determining the value delivered by these products. Consumers have become accustomed to software that’s easy to use and, quite simply, works the way it’s supposed to. As a result, in many cases, software quality is the leading factor that ultimately has the direct correlation with the quality of the brand.
Likewise, as products migrate from consumer-grade use cases to be integrated into mission-critical applications (such as safety-critical automotive systems, factory automation, and medical applications), the chance that faulty software will cause a system failure is a much greater risk and can result in severe consequences that not only bring business processes to a halt but may also irreparably harm a company’s reputation. As a result, ensuring software quality has become a critical concern across many major industries worldwide.
Software Quality Must Be a Top Priority
Businesses rely on the integrity of software to fulfill customer needs and provide value. In many ways, the brand perception is now the user experience, more so than the technical specifications. Consumer opinions are influenced by their interaction with technology. If software quality is not delivered, the company is essentially defaulting on its promise.
However, creating high-quality software is an ongoing process that needs work. For many electronic device manufacturers, software development is not the core specialty of the organization; they are in the software business as a necessity of changing market forces. One thing that is critical to understand is that quality cannot be installed at the end. Many organizations will need to adjust their software development processes to produce higher quality applications.
Rethinking the Role of Testing in the Software Development Lifecycle
W. Edwards Deming introduced a revolutionary new concept in manufacturing quality in the 1950s, which involved educating companies about producing higher quality products -- at the lowest cost. Deming’s philosophy criticized the prevailing method of quality control used at the time: primarily that products were inspected after they were manufactured. Instead, Deming believed that the manufacturing process should be designed to ensure that quality was created from the beginning. 
This seems obvious now when we think of manufacturing, but the software industry has been slow to adopt a similar philosophy. Often, a software release cycle is seen as a zero-sum game, where investing more time in testing simply pushes out release dates by the same amount. This type of thinking is unfortunately deeply ingrained in the software development industry, but this mindset neglects the value of continuous software testing over the lifecycle of the product.
The first step to improved software quality is to rethink the role of testing in the software development cycle. Organizations searching for improved quality must start thinking in terms of total lifecycle cost, not simply time to release version x.0.
The following are common flaws in the implementation of testing:
- Testing completeness is not measured.
- Tests are not easily shared among team members.
- Testing is not automated and continuous.
- Finding code regressions late in the project schedule.
- Failing to focus on edge cases versus nominal path testing.
In creating an oriental carpet, an extremely high-quality product, each part needs to be hand knit and inspected. It would be extremely effective for quality to take a similar method and apply it to software development. But that also leaves the problem of effectively scaling for software so it works across thousands of devices. If you handcraft tests each time, it would be perfect, but one can’t achieve scale at that level.
The solution is to leverage test automation early and automatically re-test any changed or added software to ensure high quality while promoting test processes that are also efficient and scalable. To have quality at volume, there has to be a strong development process in place, and the process must incorporate established procedures that can be effectively followed. The good news is that with software, when you have it right, it can be replicated easily.
By leveraging automated testing, it eliminates the need to manually generate thousands of lines of test code and helps by making testing more repeatable. If testing is also simpler to perform, developers will do more of it, and quality will be improved as a result.
Begin by using established industry best practices to get your team into a process that enables high-quality software to be repeatedly developed by establishing complete and continuous quality procedures. Start by taking an assessment of where things currently stand. Leverage test automation and make it easy for everyone on the team to see and understand the results. From there, you can incrementally improve your processes over time.
With higher quality software, everyone wins.
Opinions expressed by DZone contributors are their own.