"I'm passionate about tools and feel strongly that most of us can benefit from broadening our arsenal of code development tricks and techniques. Yet there's no market for tools. <Snip> Ask your boss for a $1,000 software quality tool and watch the door slam in your face. EEs routinely get $50,000 logic analyzers. Yet software consumes something like 70% of the development cost for electronic products.

The problem of limited use for modern software tools and techniques is real and boils down to three major issues: the nature of developers, the boss, and the vendor itself."

Okay so we don't all work in the embedded software world but is it all that different in our domain? Let's face it, not really!

Our products are designed primarily to provide users with a clean, optimized, flexible software structure, leading to agility not just in their software but also in their business.

There are a multitude of products on the market that help developers with the quality of code-level detail and plenty of products that help with designing your software. But there are not many products that do a good job extracting the “as-is design” (“structure”) from existing software, or managing the structure as it evolves over time. Even if we undertake a lot of up-front effort in the design, how many of us can confidently say the codebase today is accurately reflected in the current design documentation.

No matter how diligent we are, there is a tendency for the code and design to get out of sync. From the architect to the developer, failing to fully understand the current structure of your codebase results in poor decisions which in turn leads to poor 'product'.

An independent study carried out by the Software Technology Support Center and Mitre Corporation has proven that we can produce software better, faster, and cheaper if we can keep it well structured (but more on this later).

First, a simple and obvious example - Figure 2 is intuitively better than Figure 1 below. This is a real example of a customer’s codebase with almost 300 files in one directory. What you see in Figure 1 is mass of dependency lines between those files. Certainly, such a piece of code is impossible for someone to clearly comprehend, is likely to be highly unreliable, and almost definitely extremely challenging to maintain. In Figure 2, you see the results of 2 days effort using our software. By generating and analyzing a dependency map of our customer’s software, the user was able to identify the natural coupling and clusters in the original mass of dependencies. The resulting componentization of the code gives you a well-structured acyclic dependency graph of mind-size chucks of comprehensible code. Pretty impressive for 2 days work!

Figure 1

If you get the structure right, even in the most complex of software systems, it makes it easier to understand, maintain, test and extend.

Figure 2

At Headway, we have identified a simple set of benefits resulting from a flexible and clean software structure:

The source code is simple and easy to understand,
It is obvious where to make changes,
Changes are less prone to introducing bugs,
There is minimal duplication,
The resultant product is more reliable.

Now back to Jack Ganssle’s article, Jack mentions that there is a 'dearth of hard numbers' from vendors in relation to why we should buy their products. This is true for the most part. But it is also true that today very little data is collected in the area of software project performance and metrics, and in particular on the impact of individual tools. Such studies are highly time-consuming and very costly, and where they exist often highly confidential. In any case, does anyone ever believe anything a software vendor says! :-)

Finally, as mentioned above, there is a very comprehensive study carried out by The Software Technology Support Center and The Mitre Corporation, where cold hard data was rigorously gathered and analyzed.

"Architecture design is the key to achieving the cost savings and operational flexibility inherent in software systems. … What is more, under the right circumstances, these changes can be made very quickly."
Guidelines for Successful Acquisition and Management of Software Intensive Systems, a publication of The Software Technology Support Center and The Mitre Corporation.

Figure F-5A - STSC/Mitre Report

“ Virtually no one buys anything that incurs upfront costs for long-term benefits. That's why the rate of personal savings is so low in the U.S. Progress comes, it's felt, only from generating code. ” Jack Ganssle (in same article and presumably wishing to be proved incorrect!)

Legal