Contact Us for a Free Trial Subscription Read a Sample Issue

SHOW ME HOW TO DO THAT: "JUST ENOUGH" SOFTWARE PROCESS FOR THE 21ST CENTURY

by Dwayne Phillips

Software process in the 21st century will best be described by two words: just enough. People will want just enough knowledge; people will use just enough process; and they will want this just in time.

Process, both big and little, will continue to be necessary. It is when and how people will learn it that will change. People will resist process until they feel they need it to do their job. At that time, they will welcome just the required process in a quick, concise format.

Advice givers (i.e., consultants and process proponents) who can adjust to this new paradigm will prosper. What these advice givers need to do is not complicated. Doing it, however, requires changing with the times, and that might be difficult for many.

THE 21st CENTURY IS PLAYING PLAYSTATION IN MY DEN

Recent experiences at home and at work lead me to believe the just enough prin-ciple. The most influential example I've seen is my 14-year-old son (currently blasting or racing or whatever on the PlayStation in the den). He and his peers were born with computers in the home. He has written some programs for home and school and likes it.

There is a good chance that this 14-year-old will be programming for pay in the next two to three years. The Northern Virginia suburbs of Washington, DC (our home), make up one of the biggest high-tech areas in the US today. Growth of companies is limited by the number of people they can hire who can program at any level. These companies are turning to high school students in the summer and evenings. Some kids skip college because they are earning $40K at age 18.

My son would obviously want to learn about programming process from his dad, a professional and author. Not!

His reaction to my attempts to teach are typical of a teenager: "I know enough, I'm doing this fast enough, I don't need to do that." This reminds me of the reaction of adult programmers and project managers who don't want to change.

The exception comes when my son sees that I can do something he needs to do. All the reluctance to change disappears with a burst of "Show me how to do that!" After that, he soaks up just enough knowledge like a sponge. He then flies off and does his work at lightning speed.

This is living and learning on Internet time. A generation can read, write, do math, and think. After that, they pick up just enough skills just when they need them. This phenomenon is challenging the traditional system of education in America. It is also triggering a multibillion-dollar job training industry, typified by Learning Tree International and other such enterprises.

Rumblings at work are also pushing the just enough principle. Government, my field, is dominated by process. In my office, however, process has become an unmentionable. The "P" word is not used when trying to convince people to do the right thing. Uttering the "P" word ends the conversation.

Either way, people don't want to study and consider process. For a few years, people considered general principles, learned about types of processes, saw how to extend them, and learned how to choose which to apply when. That is rare today.

If, however, I know how to do something someone needs to do, the situation changes -- "Show me how to do that!" The other person becomes attentive to a short demonstration and goes off to his or her task. That is just enough knowledge, just in time.

PROCESS LIVES ON

The "P" word may be unmentionable, but process will live on. Process is how people do things. People will continue to do in the next century, and they will need to know what to do, when to do it, and how to do it.

People do what they need to do on a project. The how (process) depends on who (people) is building what (product) [1]. This is common sense. It has been true on projects in the past and will continue to be true in the future.

The big process followers will survive and grow in influence in the 21st century. This will be a result of the Year 2000 problem. Year 2000 will spawn a new type of software project -- the government-regulated software project. This will be similar to government regulation of airline safety and maintenance. There will be plenty of government-regulated projects. Those projects will follow government-stipulated process standards. (Big process lives on!)

Year 2000 disruptions will also increase the number of government contracts at all levels. The government will take a stronger role in essential services like healthcare, utilities, communications, and transportation. I don't think this will be good, but I think it will happen. The stronger role will mean more software contracted by the government. Software projects under government contract will use processes familiar to military contracts. (Big process lives on again!)

The minimal process followers will also survive in the next century. Commercial projects concentrate on getting to market quickly. Those projects will use processes that speed delivery. These best practices will cut whatever they can for short-term gain.

Both types of projects, government and commercial, will use the just enough principle. Groups writing software for, or regulated by, the government will learn the government-mandated process. The government will specify a standard and monitor adherence to it. This is how developments for military software have been run for years. The developers will become expert in just the specific standard but will know nothing else. They will learn it just before the project starts. If you know that standard, they will pay great attention to you for just enough time for you to show them how to do it.

Companies writing commercial software will do just what they need to do to get to market. Success on a few projects will convince them that "that is the only way to do it." These people will become experts at a specific, minimal process that optimizes time to market. Like their government-project counterparts, they will know nothing else about process. If you know how to get to market quickly, these people will listen to you just long enough for you to show them how to do it.

PREPARING FOR THE FUTURE

The future of process is bright for everyone who is ready. Process, even big process, will still exist. The just enough principle tells us that how and when people learn about process will be different. It is up to everyone to understand what this means and act accordingly.

Project managers will be at the center of activity. They are responsible for the people on their projects knowing what they need to know just in time. They will have more than enough writers, consultants, and speakers anxious to give advice. I count myself as one of these advice givers.

The advice givers on process will need to do three things to help project managers. We will have to:

1. Know our stuff

2. Be able to observe and think

3. Be able to package what people need in a just enough format

Knowing Our Stuff

First, know all there is to know about process (well, almost all). We must know the general principles and how they apply to different situations and people. The just enough trend will mean there will be fewer people available who have this type of knowledge.

One challenge will be dealing with the just-in-time buzzwords that abound. People catch buzzwords like RAD, JAD, prototypes, spirals, user-centered, object-oriented, 4GL, etc. Then someone decides that the buzzword will be just enough answer to their next problem, whatever their next problem might be.

We must be familiar with the buzzwords, what they mean in general, and how and when they apply. Each buzzword is based on an idea that works in its place. For instance, prototypes are wonderful when trying to understand what a user really wants. Therefore, they are a requirements gathering technique, not a design method.

Observing and Thinking

Second, a successful advice giver will be able to apply the general principles properly. The first step in this is analysis of given situations. Every project has a different combination of people and product. The process used on that project must fit [1].

If the people are experienced with the product, they can build it in a straightforward manner. That calls for a relatively simple waterfall process. It is the fastest to market and most efficient process in that situation (Waterfall? Fast? Yes, in this case.)

If the people have some but not much experience with the product, it will be more difficult. They will need time and an opportunity to experiment and learn. An evolutionary process with increments in the product is appropriate. The experimenting and learning are not efficient, but attempting this kind of product with a waterfall process is grossly inefficient.

If the people have no experience with the product, if no one anywhere has any experience with the product, it is a high-risk project. A spiral process is appropriate. The spiral gives many chances to learn, examine the progress, and either cancel or continue the project.

Packaging Just Enough Knowledge

Finally, an advice giver must be able to give just enough advice just in time. The final recipients of the advice will be learning on Internet time. They want just enough of the necessary process. There will be neither time nor patience for a discussion of general principles, analysis of the project, derivation of an appropriate process, etc.

An example of such packaging can be found in Watts Humphrey's text on the Personal Software Process (PSP) [2]. His text is excellent for those wanting general principles and specific application. It is not for 21st century learn- it-now programmers. Nevertheless, inside his text, Humphrey shows how to package a specific process in a just enough format.

Humphrey lays out the PSP with a set of scripts, forms, and checklists. The scripts state do this first, do that next, and then that next. The forms are fill-in-the-blank. When all the blanks are filled, you are done. The checklists remind you of key points. That is what the programmers in the next century want in process advice; just enough knowledge about process to do today's job today.

Packaging the information in such a format will be the biggest challenge. This is because concise presentation is always difficult and because giving instructions without background is wrong. It is hard to boil down a full process into a script. That requires thought, experience, drafting scripts, trying them with people, changes, changes, and more changes. Few of us have the skill and patience for that.

Regardless of the difficulty of this, it is the key to thriving in the 21st century. Process users in the next century will not dig through textbooks for the information they need for their project. They will, however, listen if they see that you know something they need and can show it to them now. Any advice giver who can do this will have more work than he or she can possibly handle. This is an excellent business opportunity.

IS THE FUTURE WORTH ENDURING?

Process in the 21st century and the just enough principle will be hard for some people to accept. Real engineers and scientist understand basic principles, think, and apply them to specific situations, right? That is the way we have always done it and the way we should always do it, right? Why should we work so hard to please these kid programmers? I can't wait to hear someone say, "Hey old man, this isn't the 20th century anymore."

Packaging the punch line without the background material is wrong -- isn't it? It is wrong as long as we use the principles used when many of us learned. That is the hard part. The next-century programmers are using a different principle, the just enough principle. They just want just enough to do their job today. Tomorrow is far away, its problem will probably be different, and they will deal with that when it happens.

The future is worth enduring. Advice givers communicate, and the first rule of communicating is to know your audience. The audience is different and wants the message packaged in a different manner. A good communicator will adjust and may even have fun doing it.

Some of the 21st century audience may surprise us. There will be some who soak up the just enough knowledge and then search for more. They will dig, learn the general principles, see how to apply them to different situations, and become advice givers themselves. After all, someone will need to carry on when we 20th century dinosaurs retire.

REFERENCES

1. Phillips, Dwayne. "People, Process, and Product." American Programmer, Vol. 8, No. 1 (January 1995), pp. 15-20.

2. Humphrey, Watts S. A Discipline for Software Engineering. Addison- Wesley, 1995.

Dwayne Phillips has worked as a software and systems engineer with the US government since 1980. Dr. Phillips helps people manage software projects; that is, he is an advice giver struggling to adapt to the 21st century. He has written The Software Project Manager's Handbook, Principles that Work at Work (IEEE Computer Society, 1998). That text discusses different types of processes and how to apply them to different situations. He has a Ph.D. in electrical and computer engineering from Louisiana State University.

Dr. Phillips can be reached at 2315 Ballycairne Court, Reston, VA 20191-1633, USA. Tel: + 1 703 476 1951; E-mail: d.phillips@computer.org.