Smaller development teams produce software that has the highest structural quality, while teams of 20 or more create software of poor structural quality. That is according to the 2017 CRASH Report on the global health of software released late last month.

The report bases structural quality on five characteristics: robustness, security, performance efficiency, changeability and transferability, according to Dr. Bill Curtis, senior vice president and chief scientist at CAST Software, whose research lab compiles the report.

The study looked at 1,850 applications with an average of 400,000 to 500,000 lines of code. Applications written in Java EE had the best quality; those written in COBOL had the poorest quality, he said. They also were the most frequently used technologies by survey respondents, Curtis noted. And, he said, because COBOL was found to be primarily in financial services and insurance, the health of applications in those sectors was poorest, which surprised Curtis. “When I saw that, I immediately took my money out of the bank and put it under my mattress, where it would be safe,” he joked.

Another important factor in structural quality is where organizations stand on the Capability Maturity Model Integration framework, or CMMI. Those at CMMI Level 1 performed most poorly in terms of structural quality, Curtis said. According to the report, Level 1 environments are characterized by uncontrolled commitments and baselines, and developers are frequently overworked on unrealistic delivery schedules. As a result, he said, developers at Level 1 are “making a lot of mistakes,” and don’t have the time to track bugs and correct those issues, resulting in poor-quality software. The quality of software approves as organizations move up the CMMI ladder.

Building architecture into agile practices also proves to be a way to ensure higher structural quality in software, Curtis said. “Sprint zero should be dedicated to design and architecture,” he said. “Spend up-front time going through architecture and design enough to know you’re going down the right path.”

Short sprints, he said, give you fast feedback to make sure you’re building the right functionality, which all leads to better structural results.

Testing tools, automation and communication are other factors that can lead to better software structural quality, Curtis said. “Applications have gotten so big and complex that no single team can understand it all,” Curtis said. “It might have five or six languages, multiple databases, CRM systems, and you can’t understand all the interactions. That leaves teams making assumptions that in many cases are wrong.”

He advocated for the use of sophisticated tools for regression testing, static analysis and dynamic simulation. “Augmenting human knowledge is critical with these tools.”

Developers need to look at things that make code hard to work with, so maintenance is less of an issue and changes don’t catastrophically affect an application. For instance, Curtis cited dependencies; perhaps there are too many children for a class, or there are some bizarre inheritances. Or, there might be dead code. “It’s just sitting there, but there’s no path to get into it. But sometimes, an update can somehow trigger access to that dead code. Bad updates can cause problems because sometimes it’s the things around the update” that are affected.

And, there is the cost. “We’re getting into the area of 9-digit costs,” Curtis said. “It’s no longer a CIO issue; it’s a CEO issue.”