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.

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.

Filled in: Software Quality
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