Curing Software Engineering’s Chronic Concerns: Part 3/3

See part 1 on this valuable series posted here March 8th and part 2 on March 10. Here's the final piece from Paul Bassett...


Curing Software Engineering’s Chronic Concerns: Part 3/3

My previous blog delved into the nature of frames, and how frame technology enables us to move from traditional craft techniques to a more mature, asset-management style of building systems, one that has greatly improved system quality. In this, my concluding blog, I want to explain how FT affects the rest of software's life cycle, from requirements gathering to maintenance, and to summarize some amazing statistics on cost-effectiveness that were gathered and published by independent project auditors.

In the FT world, requirements-gathering becomes a process of test driving industrial strength prototypes, settling on what features need to be added, modified, or deleted, and iterating on this two step cycle until the results are accepted by all stakeholders. This approach allows users and technical professionals to understand each other with a speed and a precision that conventional requirements gathering cannot match.

Testing: While you must test thoroughly and at every level just as you always have, the fact that most of a system's frames are robust (having been tested over and over in prior systems) reduces the likelihood of errors dramatically. Moreover, most errors that do occur can be diagnosed and repaired much faster. This happens because the causes of error are almost always localized in the system's novel elements, typically 5% - 15% of the total code-base. These novel elements are permanently segregated from the other 85% - 95% that comes from the robust frames. The combined effect of fewer errors and faster repairs means far less time and money is spent in the testing phase.

Last but certainly not least, let me mention maintenance, the phase of the life cycle that historically accounts for 80% of system costs. The frame paradigm eliminates application maintenance as a distinct methodology and mind-set because the system is engineered to evolve from the outset. Remember that you only maintain the novel parts of the system (5% - 15%). Whenever a frame needs to evolve, the changes can always be expressed invisibly to existing systems. Hence you are never forced to retrofit. On the other hand, should you want to retrofit, the "where used" list - a database populated by the frame processor - tells you exactly where to rebuild and retest. Even better, a change that is needed by all systems is often localized in a single frame - make the change once, then rebuild, recompile and retest all the instances of use.

Because the anecdotal evidence sounded too good to be true I asked software project auditors, QSM Associates, to conduct an objective study. It was fully funded by nine corporate participants (most were named in the report [[1]]). QSM compared 15 FT projects to industry norms, finding that on average project schedules shrank by 70%, and costs were cut by 84%. QSM has seen nothing like these statistics for any other approach, before or since, not to mention improvements in quality, customizability, maintainability, reliability, portability, etc.

As I mentioned in my first blog, what's wrong with this picture is the challenge to our core beliefs. FT not only flies in the face of our conceit (that we are the only agents smart enough to modify programs), it also threatens jobs, both managerial and technical. Yes, the number of programmers will continue to shrink, just as we need far fewer farmers now than in decades past, even though demand for food is higher then ever. The good news is that FT has been realizing its potential for more than 20 years in all manner of applications - from complex business applications, to real-time systems, to sophisticated websites - and using a variety of languages from COBOL to OO's C++ and C#.

Those willing and able to thrive with automated adaptability can bring back onshore the wherewithal to resume our place as cost-effective IT professionals. If you wish to pursue this further and are prepared to do what it takes, I can help you get off on the right foot.

[1] More of QSM's report is found in chapter one of my book: Framing Software Reuse: Lessons from the Real World, Prentice Hall, 1997. For a copy of the complete report contact Michael Mah at


Paul, we found these series of posts of great value and welcome future contributions.

Thank you,
Stephen Ibaraki

Comments (2)

  1. Tim says:

    How come we don’t see more on this in the news or from vendors?

  2. Stephen Ibaraki says:

    That’s a great question and it’s an area that Paul and I have dialogued about. My feeling is that it’s keyed to building critical mass or momentum and this requires concentrated and frequent messaging about the idea. Roger Sessions has looked at Paul’s work and it has sparked interest so the dialogue between the two would be interesting. I talked with Barnaby about this and he suggested a panel discussion/podcast. This should be of high value and interest to the audience if we can work out the logistics and get agreement. You have two noted experts discussing real challenges and issues and in real-time—you can’t can better than this! It is about solutions right?


    Stephen Ibaraki

Skip to main content