In 1964, the Japanese Shinkansen (Bullet Train to you and me) commenced its initial services running from Tokyo and Shin-Osaka. Travelling at an average speed of 131 miles per hour, it was immediately the world’s fastest scheduled rail service. Initially, there was little need for complex signalling control but as more tracks and trains were added to extend the Shinkansen network some form of reliable control was needed.

Hitachi Corporation was engaged in 1970 to deliver a computerised traffic management and control system. A primary requirement of the system was that it should be reliable, ensuring there would be no unplanned downtime and no train would ever be jeopardised by software errors. The system has been running on a Hitachi mainframe ever since. It has been running for 37 years and has never failed.

During the 1980s, at least five people died by receiving incorrect radiation doses delivered by the Therac-25 radiation therapy machine produced by Atomic Energy of Canada Limited. Enquiries determined there were a number of faults with the design of the machine. One of the faults found was software-based. A routine in the controlling software set a flag variable by incrementing it. Under certain circumstances an arithmetic overflow occurred, causing the software to bypass safety checks. A software failure resulting in death. It would seem clear, then, that software can be written to be reliable but software can also be poorly written with unpredicted faults.  

I have a friend  who works for an electronics company. We were at university together and after we both gained degrees in mathematics I went into the emerging world of ‘data processing’ while he went to Nepal and found his Qi or Zing or some other life-giving ethereal must-have. Hair shirts and open sandals seemed to work for him because while I have been talking to machines for much of my working life, he’s been talking to people about Six Sigma (or 6σ as it is often expressed).

Six Sigma is a total quality management methodology that rounds up a variety of quality management strategies and repackages them into a coherent process capable of seriously improving quality when compared with any of its substrate methods (the whole being greater than the sum of the parts). The original aim of Six Sigma when it was introduced by Motorola in 1986 was to reduce rejects in production processes to an ambitiously low level. The numbers come from the notion that if one can design a manufacturing process so well that one has six standard deviations between the mean of a process (ie a perfect unit of production) and the point at which a unit of production would be rejected, then practically no produced items will be rejected. In essence, a Six Sigma process is one that produces no more than 3.4 defective units per million  units of production.

Figure 1 explains what I mean. If we were to measure all units of production for compliance to specification (let’s say the item being manufactured must be 25 millimetres long with a tolerance of ±2mm), they would fall under the distribution curve. If we can show (for the sake of argument) that our curve is normally distributed, then at the extreme left-hand side of the curve would be the number of items that are too small and at the extreme right would lie the items that are too large. If our production process is very well designed, the area under the curve within six standard deviations from the mean would represent all the acceptable units of production and if we made a million units, four of them would be out of tolerance.

Quality initiatives like Six Sigma and others allow companies like Motorola to produce complicated mobile phones cheaply – fewer rejects equals lower waste equals lower cost. Moreover, when quality management techniques are used to manage reliability, impressive things start happening. Look at motor cars, for example. Twenty five years ago new cars came with a one-year 12,000 mile warranty if you were lucky. Today, three, four and even five-year warranties are commonplace. These warranties are feasible because of improvements in reliability, improvements made possible by clever use of quality management.

Now, suppose we apply a Six Sigma metric to software development. If we were to define our ‘product’ as a line of software code , then an application built to satisfy Six Sigma would have no more than 3.4 errors per million lines of code. In terms of ‘construction’ a modern desktop operating system is a pretty big beast. Microsoft (don’t worry, I’m not going off on a tirade here) is in the process of rolling its replacement for Windows XP, Vista, out to its final beta testers (you and me) and the word on the street is that Vista has been built with some 50 million lines of code. If we applied quality management methods that deliver Six Sigma levels of compliance performance we would have a product with something like 170 flawed lines of code. Naturally, this is no indication of quite how reliable the application would be but it’s a start.

When one considers manufacturing paradigms, it soon becomes clear that introducing quality management to a software development process can be problematical. One of the issues with software development is the ‘geometry’ of the development cycle. Whereas Motorola or NASA can introduce iterative cycles of continuous improvement allowing them to home in on their Six Sigma goal, the fact is that software development is something of a one-off. For example, Hitachi do not continually re-write and redeploy their automated Shinkansen management software.

The opportunities for code iteration do exist, however. Almost all code has been written before. Consider the case of an RPG programmer who continually uses a favourite code construct to manage a sub file (I know RPG programmers who only ever use two models or patterns to build a sub file). By using a software pattern that is tried  and trusted, the programmer is in a position to deliver a predictably reliable software construct and do it very quickly. The fact is, all of us who have written software tend to archive bits of code that are particularly appealing or elegant.

The management of patterns in construction was first proposed by the Austrian architect Christopher Alexander who in the seventies realised that the recurring patterns found in architectural edifices around the world could be described within what he termed ‘a pattern language’. In 1987, Kent Beck (one of the fathers of extreme programming) and Ward Cunningham (inventor of the wiki) collaborated to produce an important paper delivered to the Association for Computing Machinery at which they proposed the application of Alexander’s theory to software development. Beck went on to collaborate with others and has produced an amazing volume of work on the subject of pattern management in software engineering but if you read nothing else, I would suggest you take a look at his paper Patterns Generate Architecture (you can download it free from here: http://tinyurl.com/2h2t4e).

Within his paper Beck explains the concept of pattern-led design. Beck makes the point that each pattern follows a consistent format. The following examples are taken from Kent’s paper.

Preconditions. The patterns that must be satisfied before this one is valid. The sequence in which patterns are considered is one of the most important skills possessed by experts.

Problem. A summary of the problem addressed by the pattern. The problem statement is used by the reader to decide if the pattern is applicable.

Constraints. The constraints describe the conflicting (sometimes mutually exclusive) forces acting on any solution to the problem. Typical examples are tradeoffs between execution time and execution space, or development time and program complexity. Clearly stating priorities between constraints makes patterns easy to debate.

Solution. A two or three sentence summary of the solution to the problem. The solution is often accompanied by a diagram illustrating the activity required to transform a system from one that doesn't satisfy the pattern to one that does.

By way of example, Beck applies his rules of pattern format to describe the model-view-controller (MVC) architecture.

Preconditions. A system is going to have a graphical user interface.

Problem. Graphical user interfaces can be hard to build. Users demand programs that are easy to use, easy to learn and powerful, and a good user-interface is necessary to achieve these goals. How should the responsibilities of implementing a user interface be divided between objects?

Constraints. Modern graphical user interfaces have a small number of recurring visual elements. Because user interfaces need to be consistent, we depend on a few interaction techniques such as menus, buttons, scroll-bars and lists. The effort that someone puts into learning how to use one program, or one part of one program, should apply to other programs and other parts of the same program. In implementing a user interface, we must strike a balance between a design that uses many objects but is difficult to learn and one that uses few objects and sacrifices flexibility.

One important axis of flexibility is the information that is displayed. A second axis of flexibility, independent of display, is interpreting user gestures and mapping them into state changes. A third degree of freedom is the ability to put multiple user interfaces on the same information. Therefore:

Solution: Divide your system into three objects: a model, view and controller. The model is responsible for maintaining state and surfacing the behaviour necessary to support the user interface. The view is responsible for displaying an up-to-date version of the model. The controller is responsible for mapping user gestures to changes of state in the model.

It is clear that by adopting an architectural approach to the assessment of code, more can be done with any given code construct (even across programming languages depending on the description model endorsed).

So, where is this all going, I hear you ask. We are getting to a point where powerful, functionally rich systems will no longer be built by software developers, they will be built by a new breed of architects.

Look at Figure 2. A common temporal model for any software application from inception through to decommissioning will form an iterative cycle with many people involved at various phases of the cycle. There is ‘knowledge loss’ throughout the cycle as people come and go over time. Historically, this loss has always been costly in terms of product maintenance.

However, by applying a pattern-based approach to the development a number of things begin to change. Firstly, the role of the coder is reduced (in terms of man days, not importance) while the role of the analyst is bolstered. Essentially, the analyst, by describing the pre-conditions, problem, constraints and solutions, becomes a dual-functioned entity combining the  needs of the analyst with the role of a high-level software architect. The impact of pattern-based development is to refocus the project on design (ensuring the produced application delivers more closely against user expectations) as opposed to code-cutting per se.

When a development team finally has at its disposal a sufficiently large portfolio of patterns, the opportunity to improve quality and achieve the levels of product quality routinely enjoyed by the likes of Motorola will become an exciting reality.

John Amans has been involved in supporting the AS/400, iSeries and System i family of midrange computers since their launch.
john.amans@x4solutions.co.uk

This article first appeared in the April, 2007, edition of System i NEWS UK