A certain former professor of mine, a teacher of graduate-level management courses in the business school of a comprehensive university, remarked one night in class that managers don’t really care if there’s any merit to the latest hot management technique. What seems to matter, according to him, is that every few years, a hot new philosophy comes along for them to adopt.

I have noticed that the world of application development is like that. I can remember several occasions during my career when some new philosophy, product, or technology was going to reduce the backlog of needed applications and make every programmer 100 times more productive. Yet here we are, years later, still laying code one line at a time. Projects still come in late, over the budget, and bug-infested. So, please forgive my skepticism while I make a few observations about light methodologies.

A Different Philosophy

The term light methodologies is a blanket term for various approaches to the management and delivery of software projects. Light methodologies share common characteristics:

• Short deadlines—Project deadlines are usually four weeks or less. If the project cannot be completed in that time period, it is too large and must be divided into two or more smaller projects.

• Highly modularized code—Each module of code should do one thing—no more, no less—and interfaces should be strictly defined.

• Common code ownership—Everyone who works on a module of code owns the code. No more panic attack syndrome when the only programmer who understands billing leaves for greener pastures.

• Minimal requirements—Programmers using traditional techniques often make a module do more than requested because the additional capability is easy to add. Using light methodologies, requirements are limited to the necessary. If an additional feature is needed later, it will be implemented as a separate project.

• Collaborative development and coding—Two people design. Two people code. Only one person can type on the computer, but both are involved in the thinking process. This is one of the main tenants of extreme programming, a light methodology that Don Denoncourt discussed in “Extreme Programming,” MC, October 2000. In some cases, only one person works on a module at a time, but the shop uses groupware to help everybody work together. It is thought that greater collaboration results in fewer bugs, lower costs, and quicker delivery.

• Skilled people—Light methodologies require experienced people. This reminds me of when I was trying to move from the S/36 to the S/38. The shops I talked to wanted people with S/38 experience. I never could figure out how I was supposed to get that experience if no one would hire me. Be that as it may, it seems to me that light methodologies would provide a good way for newbies to learn from experienced people, especially when two or more people share a terminal.

Light methodologies are intended to find a balance between two common extremes: The bureaucratic shop, where nothing gets done until it works its way through a long and arduous process, and the anarchic shop, where people code by the seat of their pants. Light methodologies have as their goal “just enough,” i.e., just enough design, just enough coding, just enough testing.

Do People Really Do This Stuff?

Interest in light methodologies is growing, more so in Europe than in the United States. Some universities have begun to include discussion of light methodologies in their curricula.

The editors of Midrange Computing recently met with a software architect who works in a California C++ shop where extreme programming has become the norm. He assured us that extreme programming has revolutionized their shop and has helped them meet their goals for reliability, delivery, and cost.

Is It for Midrangers?

Using light methodologies sounds good to me. Upon occasion, I have had the rare privilege of being able to sit down with another programmer and work through a problem in tandem. I have always enjoyed such experiences, because one programmer thinks of things that never occur to the other. The technical term for this is synergy, but maybe the old common sense proverb is better—two heads are better than one. I have followed a lot of code, and written a lot of code, that could have benefited from synergy when it was first written.

But management is not going to buy it. While we who work with computers would like our departments to be seen as strategic weapons, high-level managers typically view IT as overhead, to put it nicely. Perhaps a more appropriate term would be “waste.” Tell the head boss that you’ll only need half as many terminals in your department, because people are going to start programming in pairs, then let me know what reply you get.

Even if management were to buy into cooperative analysis, design, and coding, it probably wouldn’t matter, because light methodologies are more than that. Light methodologies assume an environment of modularized code, and that’s why I remain skeptical. I hear of too many iSeries 400 and AS/400 shops that are making no attempt to modularize code. Many will not even consider using a language like Java, ostensibly for performance reasons, but one would think they’d at least consider using RPG IV.

We Do Need to Do Something Different

Because of the Internet, businesses no longer have only a limited number of internal users, but many external ones as well. Businesses can no longer afford long, drawn-out projects if they are to remain in business. I doubt that light methodologies will cut project times in iSeries shops, but I hope someone will prove me wrong.