Managing Software Complexity with Virtual Chapters
A Simple Tool for Mid-Sized Projects
One of the big challenges in today's complex environment is getting software done in some close relation to the schedule. I refer to projects with multiple programmers and a team leader or project manager.
Of course, there are a number of planning tools, and project management software has long been available. But there are two problems with this type of software: One is the cost; the second is getting programmers to actually use it.
The second problem is the big one. No matter how good the software may be, if the programmers don't fully adopt it, it won't be very useful. Unfortunately, most programmers find the idea of filling out task reports as much fun as driving in rush hour. The net result is that such software is rarely successful and ends up as “shelfware”, only dusted off when the process auditors visit (or, worse, is updated cynically, with invented information more or less pulled out of the air).
For very large projects, with multi-year durations and dozens of programmers, a professional software package designed for this task is the best alternative, even allowing for the significant management effort needed to get the programmers to use it properly. But for many smaller projects, there is a simpler alternative: I call it the "Virtual Chapter".
The Virtual Chapter is usually one “chapter” per programmer in the virtual project book, where he/she keeps notes on each External Entry Point (EEP) used by other programmers. It is simply a text file that can be directly copied from the current code, identified by virtual chapter number.
Each EEP should have comments that explain the purpose of the code. This can be a straight copy from the working code, with comments on valid parameter ranges. Additional status comments such as 'Design Done', 'Code Complete', 'Clean Compile' and testing results can be added as the program develops.
The Virtual Chapter is easily updated by the programmer - no fancy reports to fill in; once a week, just a straight copy and a status comment. The benefits of this simple tool are several:
- Team leaders can check project status every week by collecting all of the chapters in sequence, creating a Virtual Status Report. Progress can be identified by highlighting the differences from the previous week's version. Other programmers can see if a calling sequence has changed and check the specific parameters.
- Once the Virtual Chapters have stabilized, writers can begin user documentation without programmer assistance. Test programmers, or a Quality Assurance group can begin building a full QA test. A first pass at unit testing can be semi-automated by specifying a range of values and using a program to scan the entry points for variables, creating a series of calls.
- While the test and documentation cannot be completed without knowledge from the programmers, much of the preliminary work can be done in parallel with the code development. This eases the generation of test cases and QA and should have a positive impact on the schedule.
All of these benefits flow from a very simple concept. It is tempting to enhance this design to perform other tasks, but that desire should be resisted. The key to its value is the simplicity and low effort required from the programmer, which makes keeping his or her Virtual Chapter up to date an easy two minute exercise.
The value of current information to the team leader and the rest of management should not be underestimated. Just knowing where a problem is, is half of the battle. As is documented in "The Mythical Man-Month" by Fred Brooks, the earlier you find a problem, the exponentially less impact it has overall.
Using this information to pressure or punish the programmers is the wrong choice. When a problem is found, programmers will accept help just as long as they know this won't be a black mark against them. This is the commitment management has to make for the best results, but if it makes this commitment, then better information on mid-sized projects is just a 'Virtual Chapter' away.
Bill Nicholls is an IT industry veteran. From 1964 with Univac; to 1985 with Weyerhaeuser; then software developer and writer for Byte and Byte.com. The Virtual Chapter is his own invention, based on some work he did when he was managing QA for American Totalisator, a division of General Instrument.
I thought that this problem was solved years ago with CVS
John Werner beat me to it, but I was going to say doxygen too. I'll go a little further and point out that doxygen lets you define custom command via alias definitions. This lets you write comments like this (C code):
// \chapter Blah blah blah...
You make doxygen run as part of your overnight build script, and the resulting output (under Windows) can be a compiled help file with all the \chapter comments pulled together into a single window. So you can implement the 'virtual chapters' via doxygen aliases.
This tool is used to compile each individual programmers notes for his/her part of the project. Each programmers part is a chapter in a book just means that an individuals comments are kept together, rather than spread over an entire piece of documentation. Speaking on the Determined by chapter number is just a reference to which "chapter" the programmer writes in. For example, using:
///176 **place your virtual chapter comments here ** 176 ///
This allows the programmer to go through his code using a find or search function to pull specified comments out. The reasoning behind the chapter number is to simply allow one programmer to pull only his comments out, and not those made by a coder with the chapter number 188.
Hope this makes some sense for you. I would say that it seems a bit complicated, but whatever helps the dev team keep docs organized.