Programming the software development process with
- By Dan Romanchik
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
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
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.
Dan Romanchik is an engineering manager turned writer and Web developer. His current passion is amateur radio. You can read his amateur radio blog at www.blurty.com/~kb6nu.