Articles

If the public literature is an unreliable guide to what the strongest organizations actually do, then the next useful question is not which method is the most popular, since popularity is too often mistaken for effectiveness.  It is how strong engineering foundations can be recognized, and how their absence shows up.

The systems architect role has been around nearly since the birth of the digital age.  While it came a bit later, the need for the “software architect” role was never especially controversial. It was more often esoteric. People viewed it as a need for “big software”, a role that existed somewhere up in the enterprise layer, attached to large corporate systems and remote planning functions, not something that naturally applied to device software or ordinary applications. That has changed somewhat. Big software didn’t stay relegated to big systems.  

A look at why model-based approaches found a home in systems engineering, even as they are cast aside in the software disciplines.

Model-Based Systems Engineering (MBSE) now feels fairly normal in places where system complexity, multiple disciplines, and lifecycle visibility are taken seriously.  This discipline uses SysML models to document, simulate, and formally validate systems; in some cases even generating the VHDL used to program FPGAs.

Some of the strongest software engineering practices may be underrepresented in public discussion, not because they failed, but because the organizations that benefit from them have little reason to explain them in detail.

When a company develops engineering habits that improve predictability, integration, quality, or assurance in ways that competitors struggle to match, those habits stop being mere process preferences. They move into the realm of strategic assets. And strategic assets are generally kept internal.

Software quality changes shape with the consequences of failure, and practice changes with it.

One reason software debates get confusing is that people often talk about software quality through a narrow lens, as though it were a single thing.  It rarely is.

As system complexity grows, software teams are being asked to carry more context than they used to. That much is obvious. But, what can actually make that complexity manageable without turning every serious program into a long exercise in rediscovery?

For context, I work primarily in the world of high-assurance embedded software. Over the years, this has included applications such as safety-critical aircraft navigation systems, life-saving medical devices, toxic gas monitoring systems, and high-risk industrial control systems; among others. The common link here is quality. Without a focus on software quality, attributes like safety, security, and reliability don't stand a chance. Most of the day-to-day software development advice I see is geared toward folks who write websites, business software, and mobile devices; where failure is comparatively inconsequential.

This is the sequel to the article 5 Ways to Boost Software Quality for FREE. The items described there were primarily concerned with the advanced use of the code editor that can reduce developer effort significantly.

In this article, I will go beyond code editor features, and move into advanced tools and techniques that pack some real punch. I'll continue the list where I left off:

In my previous 2 articles, 5 Ways to Boost Software Quality for FREE, and 5 More Ways to Boost Software Quality for FREE, I described tool-supported techniques for raising software quality while simultaneously reducing organizational costs.

So, the natural question is "Does it work?". Are there significant improvements to be made from using these no-cost and low-cost tools and techniques? I'm convinced that the answer is "Yes!" In this article, I will provide one example where the gains were able to be quantified.