A while ago, I spoke to a client’s tech lead about why the company was making changes to their software development process. I’m always curious to hear these explanations, because often changes are being made for strange reasons – a prescription for an incorrect diagnosis. These unnecessary changes can lead to project failure and long-term avoidance of better changes that might actually help produce better software. It’s important to change software development processes for reasons that are tied to specific business objectives, and as I spoke to this tech lead, it became clear that the changes were being implemented without any clear reasons as to why.

This, of course, is all-too-common and, most importantly, doesn’t lead to improved quality or security. If I ask, “Why do you want to do static analysis?” and the answer is, “Because it seems like a good idea,” or, “Because the boss said to,” I get worried about the long-term prospects of your static analysis initiative.

So I asked if I could talk to this client’s manager to better understand the company’s needs. Unlike the tech lead, the senior manager knew exactly why he wanted to do the new things he had planned. They were selling a smart device and were having issues with the software that caused customers to return the device. I asked how he knew it was the software that was causing them problems, and he had a reasonable answer. As he explained, when a device is returned, they run it through the full sequence of tests that would normally occur before shipping. If resetting the device with fresh firmware and factory settings makes the problem go away, they conclude that the problem is with the software – sure, there are probably a few exceptions, but overall it seemed like a reasonable assumption.

This company had gone down the usual path of chasing bugs in the software, some of which they had no idea how to fix because they couldn’t reproduce them in the lab, until eventually they just decided to go back to the beginning and start doing “the right thing.” For them, the right thing included the modern basics of software development: consistent unit testing, peer review, static code analysis, and adoption of Agile principles.

It was a bold move. Rather than propose a quick-fix solution, they chose to take time and create a rigorous process that could be adequately measured, writing code to best practices and standards and demanding better software.

Doing the right thing won’t quickly fix immediate problems you’re having today, but it will ensure that problems over time are diminished. It’s an investment in your own future. As software is developed in a more rigorous fashion, the quality goes up, the security is increased, and overall predictability is enhanced as well, making it easier to run the business.

In today’s device-driven IoT world, where software is in everything, the cost of software failure is higher than ever. If a device fails, customers don’t care about whether the hardware or software is bad – they just return it. And tell their friends. And switch to a competitor. The only way to get ahead of this is to start building quality and security into your products. Expect the same level of maturity and quality from your software team that you do from your hardware team. The benefits will pay off.

Arthur Hicken has been involved in automating various practices at Parasoft for more than 20 years. He’s worked on various projects involving the software development lifecycle, software security, complex web applications, and integration with legacy systems. Arthur taught at the College of DuPage in Illinois, as well as developed and conducted numerous technical training courses at Parasoft.