Most organizations have started to realize that code quality is an important root cause to many of their issues, whether it’s incident levels or time to value. The growing complexity of development environments in IT -- the outsourcing, the required velocity, the introduction of Agile -- have all raised the issue about code quality, sometimes to an executive level.
Business applications have always been complex. You can go back to the 70s, even the 60s, and hear about systems that have millions of lines of code. But here’s the rub: In those days it was millions of lines of COBOL or some other language. But it was all one language. All one system. All one single application in a nice, neat, tidy package.
Today, millions of lines of code means applications built with several different programming languages -- some compiled, some object oriented, some interpreted, some SOA-enabled, some dynamic scripting languages, and some mark-up languages (not to mention database languages) -- with a complex data model controlled by hundreds, if not thousands, of business rules. It’s beyond time for developers to innovate their level of thinking about how to adequately test the quality of their applications.
Firstly, modern business applications are too complex for any single individual or team to understand the entire application and the technologies it interacts with. Even if a developer is a master at two or three different programming languages and the tiers they reside on, he or she can’t have a complete mental model of how his software will interact with other technologies. To compensate, he or she makes assumptions that are difficult to verify, and when wrong can lead to damaging incidents (glitches, crashes, etc.).
Secondly, recent research on large software systems contradicts the old model that a defect can be traced to a single source. Of the faults that lead to failures, 60 percent required changes to two or more files (lowest level system elements), while 30 percent involved three or more files. One third involved multiple system components, while 10-20 percent crossed major segments of the architecture.
Is there any application quality in your code quality?
So, when we examine code quality we’ll have to think of it in two stages. First is basic code quality, which measures individual or small collections of coded components written in a single language or occupying a single tier in an application. The second is application quality, which analyzes the software across all of the application’s languages, tiers, and technologies to measure how well all of the app’s components come together to create operational performance and overall maintainability.
We would be the first to shout that code quality is important, but high quality code by itself will not ensure a high quality application. Checking code quality can be as simple as running your thumb through the code; however, application quality problems are difficult to detect until components have been integrated with components from other tiers in the build process. This means they’re often detected at the last stage of integration testing, causing delays, frustration, and potentially, business losses.
Here are some typical application quality problems that can occur even with high quality code:
Each of these problems will result in unpredictable application performance, business disruption, and data corruption, including making it difficult to alter the application to respond to pressing business needs. An evaluation of application quality, rather than code quality, can detect these problems.
So how do I assess application quality?
There are many tools available that measure code quality. They’ve been available for many years and increasingly becoming standard components in developers’ tool sets. However, when it comes to application quality, it’s only in recent years that some tools have been introduced by various software vendors and consultancies. Indeed, organizations need the help of application quality diagnostic services because this is not something that can be done only manually, given the scope of the complexity of modern development tools.
The good news is, when organizations do start analyzing their IT systems for application quality, they will gain a variety of benefits:
Fundamentally, all the application weaknesses I mentioned earlier -- bypassing the architecture, failure to control processing volumes, application resource imbalances, security vulnerabilities, and the lack of defensive mechanisms -- can be found and addressed, as well as many more.
Since even the most talented developers can no longer know all of the nuances of the different languages, technologies, and tiers in an application, their capability needs to be augmented by automated tools to evaluate the entire application. Without it, defects hidden in the interactions between application tiers will place the business at risk for outages, degraded service, security breaches, and corrupted data caused by poor quality applications.