This is the third column concerned with improving the quality of the information services you deliver to your end users. The first column focused on why you need to pay attention to this aspect of your business and the second on some simple ideas for low cost quality programs. I'd like to continue by outlining another easy to implement idea to gradually but effectively infuse quality into your DP services.

But first I'd like to briefly explore why some of these problems are so pervasive in our industry. One thing I'm pretty sure of is that we're all human (well, the majority of us anyway). Under stress (such as a major system failure), we naturally get a shot of adrenaline to help us cope and this triggers the Fight or Flight syndrome. We fight the problem and then flee the blame. California has just been through some big wildfires and I think there are a lot of instructive parallels in this disaster to most data processing disasters. First, there were visible warnings, from the high brush growth after last years rains to the Fed buster letters. If you had your eyes and ears open you would have known there was an increasing potential for problems. This is usually true in MIS also. Signs of aging systems and error prone design abound if our eyes and ears are open.

Secondly, in some ways the officials aggravated the potential problems -- from not building additional water storage in Laguna Beach to prohibiting brush cutting in Hemit. We need to look at how we aggravate potential problems in data processing. Are we really sure we have adequate backups? Have we taken the time to review designs and code for stability and the effects of business growth patterns?

During the actual fire, the firefighters were reacting to the fire and obviously had a really difficult time gaining the upper hand. Everyone worked courageously and until they were well past exhaustion, but of course that's what a fire fight is all about. A lot of MIS shops seem to be in a continual fire fight themselves -- they have hard working people, but never seem to gain the upper hand. In the middle of a constant crisis it's really hard to step back and address root causes. That's why its imperative to do so in the calms between the firestorms.

Finally, after the fire the investigators fan out. They seek to find out where and how the fire started. They attempt to fix the process that failed and work to prevent a similar situation in the future by building fire-breaks, having reserves of manpower and water, cutting down inappropriate brush and replacing it with more fire resistant landscaping, etc. Again these are great parallels. Are you taking the time to build fire-breaks into your systems? These are places where the data is isolated and recoverable. In today's world these are also the places to partition monolithic systems into client server architectures! Are you driving your machine or your people so hard there are no reserves left to handle a crisis? You need to have the resources to solve problems and handle the occasional crisis. Do you regularly look for and rework or replace the most unstable, crisis prone pieces of code? If you recognize familiar problems in this litany, start to do something about them today. If you don't react, you are sending the wrong signals to your staff and multiplying your original problems. If your tired of feeling like a busy fireman, switch hats and do a little prevention work as a fire marshal.

How about getting down to some specifics in the quest to move from fire fighting to fire prevention? Well, one central theme in good design and good programming is teamwork. Two heads are so much better than one at solving any problem, its hard to quantify the effect. There are several qualitative reasons for this. People are different and these differences cause them to come at problems from a different viewpoint, exposing more of the design to the light of review. Even the thought of working with someone and having them critic your output causes you to be more analytical in the design and take more care in the construction of systems. This brings me to this months key idea for quality improvement -- peer review teams.

I'm a big fan of peer review teams. In outline, this is where individual output is put through a rigorous review by a group. The key word in the description is rigorous. This review process can be applied to any aspect of the business, but for the sake of simplicity, I'll use the terms code/coder to include design/documentation/etc. The review process usually starts with the coder presenting a walk through of the material. This provides an important clue to their preparedness and understanding. If they cannot give a coherent overview of the process, how can they have coded a clear, robust and maintainable product?

Next there should be a formal check list of the quality areas involved in the process. Having a written check list ensures we cover the areas management is concerned about (it also documents them!). The list will be different depending on the type of output being reviewed. For example, design reviews will want to ensure the physical process is correctly reproduced, that the design is robust in the face of errors, that it is adequate for the projected volumes, the user interface is standard, etc. Code reviews will look to insure all elements of the design are handled, that the test data has been run and stresses all decision logic and flow paths, the coding is efficient and within performance limits, the programming standards are adhered to, the user documentation is complete and accurate, etc. You can see how easy it would be to overlook pieces of these lists if they are not down in black and white.

To be effective the review team must have the authority to send output back for rework. If it is just a rubber stamp, why bother? At the same time the rejection of work output must be viewed by both sides as a learning experience, not a judgmental statement. Team members should be 'peers' and should rotate, experiencing both sides as they learn new techniques and grow through self improvement. In fact, this training aspect can be exploited to train junior team members! Add them as members of review teams and they are exposed to the best the group can achieve, including all the standards and the concept of teamwork. This is a much easier and better way of training them than most shops currently employ.

Besides all the emotional issues of submitting to peer review, I can hear people shouting "How can this be low cost? It will slow down productivity and increase my staffing needs." As to the emotional objection, I recommend starting this process in small ways and with small teams (perhaps one on one) to allow the organization to adjust and absorb the new procedures. To address the cost issues are harder, not because it costs more but because costs shift. Done right, peer review adds a minimal amount to the design or coding process. This small investment in extra energy is easily returned in better, more maintainable systems delivered on time and requiring less debugging.

Getting started on this type of project takes commitment and an investment of time and energy but is easily worth it. Studies repeatedly show a variance of more than twenty to one in programmer productivity. How much does your organization gain if you can move average productivity to the high end of this spectrum? While I don't believe in any single "silver bullet" to slay the demon of chaos, peer review teams are a real weapon in the arsenal. If you'd like to read more about quality issues and solutions in data processing, I recommend a series entitled Quality Software Management by one of my favorite authors, Gerald Weinberg as a good starting point. Meanwhile, please don't simply ignore quality. Start small, but resolve to start today.