The process of change in software development brought programmers and managers from government and industry to a meeting at the University of California at Irvine's Irvine Research Unit in Software (IRUS) in Palo Alto, CA, earlier this month. If there was one point of agreement among the speakers and the audience, it was that for change to be successful, it must come from within an organization.
Change is needed to improve the software process, all agreed. However, "Very little change happens from top management," said James Bach, staff metrics engineer in language quality assurance at Borland, Scotts Valley, CA. "True, [the problems are] all their fault, but that doesn't change anything. Maybe we should make some of this our fault so that we can then do something about it. Quality improvement is always and only a personal transformation."
Karl Kelley, a project supervisor at Loral in Palo Alto, and formerly supervisor of software process engineering there, said he wrestles with "the usual suspects" in software process improvement- including Total Quality Management and the Software Engineering Institute's change management doctrine. All the principles are right, Kelley said, but the problem comes in trying to implement them. "If you take principles and turn them into bureaucracy, you get junk," he said.
The issues he faces are that there is not enough money to implement change, the customer won't pay for it, the need is not apparent to everyone, and everyone is too busy. Retraining software developers costs money and high-quality training costs even more. "Nobody wants to sit through low-quality training," Kelley said, and besides that, "You can't train and still get your current work done."
Change is needed to improve quality, scheduling, ease-of-use, maintenance, and upgrades, said Greg Swietek, project manager at NASA Ames Research Center in Mountain View, CA. Software reuse should also help, and all those changes are needed to cut costs. But as desirable as software process improvement is, "The motivation to change current practices must come from within," Swietek said And for that to happen, "The change process vehicle must spontaneously engage line employees, team leads, and middle/upper management." It helps to start slow on single issues, he said. Cross-pollination and a learn-while-doing attitude are also needed, he said. NASA Ames is being reorganized even as it develops projects such as remote control vehicles to explore the Antarctic under water and rove around Mars in 1997.
Another problem with implementing change is that top management may give only lip service to process improvement, while keeping the short-term "bottom line" as their real priority, some in the audience said. And panelist Jim Gibson, a programmer from Recom Technologies, criticized what he called "change by buzzword." Management at his company said they supported TQM, but "We only got a one-day seminar. Then we went back to the old way of doing business. I didn't see a lot of change come out of this very significant initiative."
Bach, who has been designated by Borland to devote all his time to process improvement, said that if he really wants to get things done, "I try to stay away from any kind of committee or task force. Usually you can find two or three people who have decided to do all the work, and work with them." It also helps to experiment informally, be tolerant, and use personal initiative, Bach said. "If I want a change made, it starts with me. My own ability to influence people is the biggest factor."
He illustrated the problem of trying to change by directive with a story from his days working for Apple Computer. New criteria for software releases were issued, calling for no "Level 1" (most serious) bugs in the release. As a result, when Level 1 bugs were still present by the required release date, they were just demoted to Level 2 bugs.
By all means, avoid manuals when deploying a new process, Bach asserts. "If you start with a 50-page manual, you might as well put a gun in their face," he says. "Any more than one page is a tome." Instead, use mentoring and "train ourselves and our teams to think situationally. That means focusing on cause and effect, and letting processes be provisional and experimental."
Gibson agreed that "I think you have a problem when upper level management wants to institute a change but they can't sell it to the lower level."
The meeting was one in a series by IRUS called the Bay Area RoundTable series. For further information, contact Debra Brodbeck, (714) 725-2260; brodbeck@ics.uci.edu.