Program Report

Idea Watch SIG Examines the Development Process

By Carol Macbain

Steve Maguire's book Debugging the Development Process was the topic for June's Idea Watch SIG meeting, led by Colleen Strahs. Maguire's many years of experience as a project lead at Microsoft convinced him that software development teams can write high quality code while sticking to the development schedule—a realistic schedule, that is.

Improving the Product Comes First

One of Maguire's key principles is that a developer's primary goal must be to improve the product. This means eliminating, as much as possible, the small daily interruptions that keep team members from writing code. Number one on his list of things to avoid is meetings, which not only take up valuable time, but can also demoralize the team if they focus on things that have not been done. Maguire says email messages can effectively keep people up to date on what has been accomplished.

For necessary meetings, Maguire says:

Email and reports also distract developers from their work. Maguire suggests checking email at fixed times, up to three times a day, and acting on or deleting each item on the spot. He says reports are usually not worth the time it takes to write them, especially when the information has already been communicated orally.

Where Do We Fit In?

As technical writers, we certainly understand the distractions of email and meetings when trying to focus on a project. But we hope it is not our documentation reviews and our email requests for clarification that are being "ruthlessly" eliminated from the developer's daily grind. Maguire does include a quick mention of documentation as one of the things that indirectly improves the product, but members felt that Maguire's focus, totally on the developer, was a little out of date. Now, companies are increasing the role of writers in the development process by integrating them into the team.

Given that writers could be dumped into the category of unwelcome interruptions, we need to respect the developers' time and do everything we can to make it easy for them to give us the information we need to do a good job.

Work Smarter, Not Longer

Maguire is not a fan of the 80-hour workweek. He prefers to analyze the situation when the schedule starts to slip, find ways to solve the problem, and adjust the schedule to reflect reality. He shows how—after time for lunch, dinner, a little down-time, and a few personal errands or tasks—the twelve-hour day looks more like the usual eight or nine hours. He strongly warns against expecting longer hours to fix a project that's slipping. We can all attest to the fact that people deserve to have a personal life, and it's gratifying to know that a good product can be released on time without undue stress on developers and writers

Team flexibility is also something Maguire values. When training new team members, he makes sure they work on a variety of projects. He even recommends getting rid of your best programmer in order to let him or her move on to more challenging projects. Other members of the team will improve their skills and fill in the gap. The company as a whole benefits from more people with varied skills and less mental stagnation.

Develop Systems

Another key technique that contributes to a good product delivered on time is to always develop systems that will improve the development process. With software, this translates into fixing bugs immediately and requiring the person who wrote the messy code to debug it. Not only does this reward the more efficient programmers who can move on to new features, but it makes the schedule more accurate by avoiding a lot of unplanned work at the end.

Improving the process by planning ahead to avoid pitfalls and developing systems with positive feedback loops is worthwhile for software development, documentation, and almost anything you set out to do. Steve Maguire's book, published in 1994, still has useful tips for project management of any type.

What's Up Next

The Idea Watch SIG is starting up again in September with a new list of books on business, usability, project management, and other topics of interest to technical writers. Please share your book suggestions with Colleen, and join us next month.

Carol Macbain is a technical writer and Idea Watch member. You can contact her at CJMacbain@aol.com.