OK, with a name like Rocket Science Games you had to expect that things might 'crash and burn' now and then, didn't you? Just before the CGDC, Rocket Science laid off all the development personnel and became something approximating a virtual corporation — it still exists, but it doesn't do much. You might, I suppose, say the Rocket is drifting in space, working to stay alive, hoping for rescue.
And just as I was getting used to having a regular job, too. That part alone took almost a year.
Still, it's not all bad. I've actually had a month to realize that there is a season called Spring (usually spent inside trying to get product ready for Christmas, which comes in September or so). I've had a chance to visit a lot of companies and see what kind of cool stuff they're doing — especially the small ones. And I've come to realize that I've grown up enough to be able to appreciate leisure time. You wouldn't think that would be a problem, but it always has been for me. I have the first inkling that, were I independently wealthy, I might NOT spend my life just the way I have, building cool stuff. Scary.
Everyone should have a break now and then, just to see what it's like. I can't recommend the way I got here — having a company flame out under me was no fun — but I can recommend the results.
NuMega BoundsChecker Version 5
Anybody who does development for Windows needs...well, needs as much help as they can get, frankly. Windows is an immensely complex system for which we build horrifically complex software. And it's easy to get screwed up by relatively simple errors when you code in C or C++ for Windows. BoundsChecker is an automated debugging tool which can help you find significant errors without significant effort. It's not a cure-all, but it's a useful tool that I think every development team programming for Windows should have.
BC 5 comes in several flavors. I have the Visual C++ Edition, designed to integrate specifically with Microsoft Visual C++ and knowledgeable about certain internal formats it uses. Unlike previous versions of BC, which were compatible with multiple compilers and debuggers, the Visual C++ Edition contains features and benefits usable ONLY with Visual C++. There's another version of BC 5 (Standard Version) which is usable with most other compilers. and there is a Delphi edition. In the works is a version compatible with Borland's C++ Builder (basically a C++ version of Delphi).
BC 5 supports two levels of error detection, each level requiring a different amount of interaction from the user (and a different level of intrusion into your normal process). The simplest level is ActiveCheck, which can be used without recompilation or relinking, and which detects Windows function failed, Invalid argument, Stack overrun, Dynamic memory overrun, Memory leak, Resource leak, and Unallocated pointer. The more intrusive (and more comprehensive) level is FinalCheck, which requires that BC "instrument" (insert error detection code into) your code. FinalCheck detects (in addition to the problems found by ActiveCheck) Reading/Writing overflows memory, Reading uninitialized memory, Array index out of range, Assigning pointer out of range, Dangling pointer, non-Function pointers, Memory leak by free, Memory leak by reassignment, Memory leak leaving scope, and Returning pointer to local variable.
In addition to the above error detection, BC also does event logging so that you can see what system events occurred before a problem happened; checks for Win32 compliance for NT, 95, and Win32s; checks for undocumented Windows calls; and highlights library calls not supported by ANSI C.
The major problem with BoundsChecker has always been the slow speed of instrumentation and instrumented code. The Visual C++ edition is intended to improve the performance of instrumentation when used with Visual C++ by instrumenting intermediate code instead of source code. I was unable to run head-to-head comparisons between BC5 and the previous version I used (BC 3), but my gut feeling is the BC 5 is substantially faster when instrumenting. Running instrumented code (especially with extensive event logging) is still too slow for some real-time applications.
But that's no reason not to use BoundsChecker where you can. Especially with the new pricing, every development team should have at least one copy for testing at least periodic builds. It's not out of line to have the BuildMaster use BC on every daily build or every build posted to source control, but at least every milestone build should be checked.
Introduction to the Personal Software Process
Watts S. Humphrey
Addison-Wesley, PB, 278 pp.
I first used a time log when I was a TD at Electronic Arts and had to account for my time so that it could be billed to various projects. The first surprise was in how easy it was to do. The second surprise was where my time was actually going. Once we had information about where our time was going, the next step was to prioritize projects, and pretty soon we could say "sorry, you're below the line and I do not have time to do that" (a wonderful thing in a company that wants to take every second of your life). If you log your time and find out where it's going, you too may suddenly discover that you have MORE time in your life — or at least that you can make better choices about how you spend the time you do have.
Time logging is probably the central thrust of this book. Watts Humphrey has written a number of significant volumes on software engineering and management, including Managing Technical People, Managing the Software Process, and A Discipline for Software Engineering. Introduction to the Personal Software Process (hereafter, IntroPSP) is his latest, and I find it a worthwhile addition to his section of my bookshelf.
I was first introduced to Humphrey's writing by A Discipline for Software Engineering (hereafter, DSE), which introduced the PSP (Personal Software Process) for engineers to improve their ability to create code and to schedule their creation of code. I didn't agree with everything in DSE, especially the emphasis on Lines of Code (LOC) as a productivity metric. But I did (and do) agree with the fundamental idea that you must measure your productivity and your daily activities in order to improve your efficiency. Lord Kelvin is generally credited with the quote "You can't control what you can't measure", and Humphrey takes the idea to heart both in DSE and in IntroPSP.
The heart of the PSP is: Record what you do and use that information to plan your time. Once you know how long it took you to do a task of a given size, you can use that knowledge to plan how long a task yet-to-be-done will take. Of course, then you have to accurately estimate the size of a task before you've done it. The PSP covers that, too, although I think it's better covered in DSE than in IntroPSP.
Once you have information on your daily activities, you can use it to determine useful tidbits of information like the number of minutes you spend per debugged LOC, the number of LOC per hour, and so forth. These numbers give you a reasonable idea of your productivity (albeit in a given language, even a given development environment) so that you can correctly determine if a change in your techniques or behavior generates a positive or negative effect upon your efficiency. Without good data, you're really just guessing whether that new tool you started using really helps you produce code faster or just moves time from writing code the first time to debugging it later.
IntroPSP is just what it says — a nice little introduction to a more precise (OK, some might say compulsive) method of time management and what I might call "productivity engineering". I don't really think it takes the place of DSE, but it's a much lighter introduction and contains quite a bit of useful information — the survey or course notes, if you will, to DSE's textbook. It will certainly give you enough information about the PSP to decide if you want to use it or not.
One caveat, however — it appears that Watts Humphrey is now teaching courses in the PSP, which gives him an additional financial incentive in its popularity and success. I would think carefully (and read both volumes very carefully) before committing myself (or my entire department) to training in any technique claimed to be an across-the-board benefit. It smacks of Silver Bullet Syndrome (see Assessment and Control of Software Risks, by Capers Jones). If you're going to try it, try it with just one or two people first, and see what it does for them.
See you next time....
Evan Robinson is the former Director of Games Engineering at Rocket Science Games, Inc. Before becoming a manager he was a consultant, programmer, technical director, and game developer. He is now eking out a tenuous living writing review columns and going on job interviews. You can email him to offer him a consulting opportunity or a job, or just to talk (well, OK, type) about books, software, development, or the meaning of life.
Copyright © Evan Robinson. All Rights Reserved.