For Software Quality, Context Matters


If you've been in any airport in the last few years, you've seen ads from HSBC - the global bank that prides itself on local knowledge.

HSBC Leader Follower

The point is, context matters. The same outfit means opposite things depending on where you are or who you're with. The same thing applies to software quality. Quality is not just a local thing -- only when you have global knowledge can you act effectively on the local level.

Two of my colleagues, Olivier Bonsignour and Bill Curtis recently wrote an article explaining this at length. Here is a summary of their excellent article -- well worth checking out in full.

"Quality is not an intrinsic property of code: the exact same piece of code can be excellent in quality or highly dangerous depending on the context in which it operates. Analyzing the quality of modern applications in the context of the numerous interconnections with other code, databases, middleware, and APIs is monstrously complex. It can only be accomplished with automated software that analyzes the inner structure of all components and evaluates their interactions in the context of the entire business application."

They go on to show the quality problems that arise when context is ignored. Again, I'll summarize. You can find the detailed examples here.

Typical application quality problems are listed below to clarify the distinction between application and code quality. Performance testing alone is not sufficient to detect these application quality problems.

A. Bypassing the Architecture. Components in one tier of a multi-tier application are typically designed to access components in another tier only through an intermediate “traffic management” component. Bypassing this traffic management component will usually result in a cascade of problems.

B. Failure to Control Processing Volumes. Applications can behave erratically when they fail to control the amount of data or processing they allow.  This problem is often caused by a failure to incorporate controls in each of several different architectural tiers.

C. Application Resource Imbalances. When database resources in a connection pool are mismatched with the number of request threads from an application, resource contention will block the threads until a resource becomes available, tying up CPU resources with the waiting threads and slowing application response times to a crawl.

D. Security Weaknesses. Applications are vulnerable to security attacks when they lack appropriate sanitization checks on user inputs in all relevant tiers of the application.

E. Lack of Defensive Mechanisms. Since the developers implementing one tier cannot anticipate every situation, they must implement defensive code that sustains the application’s performance in the face of stresses or failures affecting other tiers.  Tiers that lack these defensive structures are fragile because they fail to protect themselves from problems in their interaction with other tiers.

Each of these application quality problems will result in unpredictable application performance, business disruption, data corruption, and make it difficult to alter the application in response to pressing business needs. Reliably detecting these problems requires an analysis of each application component in the context of the entire application as a whole – an evaluation of application rather than code quality.

Filed in: Technical Debt
  This report describes the effects of different industrial factors on  structural quality. Structural quality differed across technologies with COBOL  applications generally having the lowest densities of critical weaknesses,  while JAVA-EE had the highest densities. While structural quality differed  slightly across industry segments, there was almost no effect from whether the  application was in- or outsourced, or whether it was produced on- or off-shore.  Large variations in the densities in critical weaknesses across applications  suggested the major factors in structural quality are more related to  conditions specific to each application. CRASH Report 2020: CAST Research on  the Structural Condition of Critical Applications Report
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
Making sense of cloud transitions for financial and telecoms firms Cloud  migration 2.0: shifting priorities for application modernization in 2019  Research Report
Load more reviews
Thank you for the review! Your review must be approved first
New code

You've already submitted a review for this item