<Previous Next>
Q7: Fascinating revelations, Paul, about how to manufacture custom software cost-effectively. Does frame technology affect other phases of the lifecycle?
A: Indeed, it's been called a "paradigm shift," a greatly overused term. I'll let you judge if I'm entitled to use it.
Let's start with the requirements phase. In mature frame environments it's never acceptable to start from scratch, so-called green-fields. Almost for free, a frame engineer can quickly generate an industrial-strength prototype from frameworks that are relevant to broad-brush requirements. Non-technical users relate to WYSIWYG executables, not abstract technical specs. The prototype also incorporates high quality architectural, safety and security features that such users usually don't know enough to ask for, and in the current paradigm, are not implemented until much later.
"Test drivers" of the prototype express feedback in a "same as, except…" fashion, where the "exceptions" can range over the gamut of high and low-level, functional and non-functional features. Frame engineers design frames that extend and customize the prototype based on these informal, evolving requirements. Next, they regenerate and integration-test the system to ensure the new and revised executables interoperate properly with the rest of the system. The new version is test-driven again, and the cycle repeats. At some point, test-driving becomes acceptance testing, but refinement cycles continue indefinitely. The so-called maintenance phase, as a separate process and mind-set, disappears. The same tools and techniques used to create the system are used to fine-tune and evolve it.
Quality and testing deserve special mention. There is a natural division of labour:
Domain-expert frame engineers design and write frameworks of high quality - functionally rich, robust, efficient…. Because such frameworks supply the bulk of every program, quality necessarily goes up, compared to conventional programs. Also, because frameworks are reused, hence tested in diverse contexts, they have fewer defects than un-reused code. Application developers write specification frames using templates - each template already knows what frameworks to adapt, and explains the use of various parameters. Most errors are fast to find because all un-reused code is in specification frames. This combination of fewer defects, defect-localization, and functionally rich frameworks provides a powerful punch. Bottom line: faster better cheaper.
The anecdotal evidence sounded too good to be true. So I asked 15 corporations to hire an independent auditor, QSM Associates. They compared 30 frame-based projects, ranging up to 10 million lines of non-comment code. QSM confirmed that 85 to 95% is a normal reuse range. The auditor also found that a typical project was completed in 70% less time, with 84% less cost than their database of industry norms predicted. So, is this confirmation of a paradigm shift?