Columns

Programming the software development process with

• By Dan Romanchik
• October 31, 2002

Managing a technology development group is a tricky business. I spent several years doing just such a thing, and I don't think I ever got close to being really good at it. How could I? I am an engineer by training, not a psychoanalyst, and managing a development team is almost as much about psychology as it is about technology.

A manager must deal not only with the technical challenges a project presents, but the challenges of managing a mixture of personalities and skill levels -- prima donnas and shrinking violets, gurus and newbies. Getting them to work together toward a single goal can be a nightmare. No doubt this task has kept many software managers up at night.

This is the problem Software for Your Head purports to tackle. The authors start with the premise that ''Team = Software.'' That is to say that the behavior of the team will have a direct effect on the quality of the software. The reverse is also true -- to develop a product with certain characteristics, you will need to build a team that possesses compatible characteristics.

After the book's promising start, the authors define a set of protocols for how team members should interact with one another, much as you would define a set of protocols for computer systems interacting with each other. These ''core protocols'' are supposed to help the developers on a team create a shared vision of their project and set the rules for how team members are to work together. These protocols carry names such as CheckIn, CheckOut, Alignment and Decider.

The book also defines what the authors call patterns and antipatterns. Patterns are behaviors that produce desirable results, while antipatterns are behaviors that produce undesirable results. The authors also offer ways to deal with antipatterns.

As presented, the system is very complicated and would seem to take quite an effort to learn -- and this is on top of tackling the software development project at hand. It is perhaps do-able on a small scale, but to ask a large group to adopt these methods as well as complete a development project may be asking too much.

I suppose what bothers me the most about the core protocols is their rigid structure. The authors contend that this structure will actually free up developers to express their creativity and focus on their work by eliminating a lot of unproductive behaviors. I can see their point, but I wonder how well it would work in a real-world situation.

Software for Your Head: Core Protocols for Creating and Maintaining Shared Vision by Jim McCarthy and Michele McCarthy; Addison-Wesley; Boston, 2002.