Managing Software - Part I

There is a certain brand of humor that only a software developer can understand. Writing computer code well requires not only remarkable logical or linguistic skill, but the ability to translate through layers of abstraction (from the "real world" to the machine) as well.

And so, managing software projects and people is a bit different than managing other things. The biggest single risk in any software project is "lack of communication" (see the cartoons above and below), and this blog is one small step in hopes of opening lines of communication.

It is sometimes hard to communicate even the most basic elements of a development effort. In search of better communication I've been working with Darcy to try to implement a means of tracking Development that is gentle on the developer, but rich in the information it provides. We're working to implement a form of painless schedule.

A bit of scheduling can really open channels of communication, as a decent schedule and trends provides a ready, day-to-day answer to some key questions:

• What's the next milestone?
• What's in it?
• Who is working on it?
• When is it expected to be delivered?
• Where are the biggest risks?

It's hard to believe that such fundamental information can be had with about 5 minutes per day per developer, but I've seen it be so. In my experience the ability to answer such questions routinely completely changes the communication dynamic for teams writing software.

More on this to follow...