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

See part 1 on this valuable series posted here March 8th. Here’s the next post from Paul Bassett…

____________________

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

My previous blog introduced you to frame technology, explained how it dramatically amplifies conventional manufacturing techniques, and made some rather strong claims about FT’s potential to overcome our industry’s chronic problems. This time I want to dig under the surface so you can understand how you use a FT to solve such problems.

Let me begin with FT’s beguiling simplicity: It’s just a text processor on steroids! To wit, virtually all word processors can combine a list (of names, addresses, or other data) with a generic template, producing a list of custom documents. Generalize this 2-level approach to handle any number of levels; allow any kind of logic to control each customization; and allow any kind of information, including lower level customization logic, to be further customized at any higher level. Now you have a frame technology. As you may have guessed, a FT allows you to use any language(s) to express yourself, including English.

The universal stratagem for creating frames is called same-as-except: How often have you heard: “Y is like X, except …”? “Binoculars are like telescopes except …” “Programming a VCR is the same as setting a digital alarm clock, except …” This manner of knowing things is ubiquitous, and drives the design of all frames. Making a frame is easy:

Start with a good example of X (expressed in ordinary source code of your choice);

Turn all details that might vary – data structures, argument lists, logic, any string of symbols – into frame parameters whose default values are those details. Thus when X is processed by itself (not adapted by any other frame), it defaults to its original text.

X is now a frame such that an unlimited number of Y frames can adapt it by overriding just those defaults that Y needs to change (to suit Y’s context). The idea generalizes: “Z is like Y, except …” where Z’s exceptions can override details of both X, and Y’s exceptions to X. Also possible: “Y is like W + X, except …” And on it goes.

A small group of frame engineers design, build, and evolve frames. They do these tasks in concert with application developers who design, assemble, and evolve systems out of frames. Developers, in turn, work in concert with users and other system stakeholders who debug their requirements by operating said systems. And the whole process iterates. Indefinitely.

Over time, a library of mature frames evolves that captures more and more of the organization’s intellectual assets, leaving less and less to be done from scratch. Most user-requests become small deltas from frameworks that are already on the shelf. At that point all you need is a small core of frame engineers together with appropriate IT professionals who understand business needs well enough to resist frivolous or counterproductive requests.

Even better, the division of labour associated with frame engineering enhances quality. Only the best experts record their solutions in standard frames, thereby propagating their expertise into every application. Software development is transformed from a craft to an exercise in asset investment and management. And those assets continue to produce ROIs for the organization long after the original authors have been promoted or hired away. 

In my previous blog, I contended that FT has far reaching effects on software’s entire life cycle, not just construction. That will be the topic of my next and concluding blog.

_______________

Paul, we look forward to your final installment.

Thank you,
Stephen Ibaraki