What's "Faster"?

The first hurdle that The Faster Software Project has to overcome is figuring out how to objectively measure the speed of software development. Fortunately, for us, there's an easy answer: you can't. Sure, if all our programmers worked on the exact same project, with precisely the same set of instructions, with all the same resources, and started at exactly the same time -- yes, then I suppose we could be objective about it. But because that will never happen in the real world, we have to compromise.

One idea that is often proposed at this stage is to somehow quantify software development effort. These discussions lead directly to the idea of measuring lines of code or kloc. Most programmers know instinctively that this is folly. My favorite rebuttal of it is to repeat a simple status update once given by one of our lead developers: "I fixed that bug by removing a line of code."

Nonetheless, I'd entertain the idea as a very loose way of measuring programmer output if I could do it secretly. After all, I suspect that there's a decent correlation between those programmers on our team who I consider to be the most productive and the lines of code they produce each year. However, one technique I plan to exploit in my effort to improve software development speed is the Hawthorne Effect, which states roughly that people tend to be more productive when they know they're being watched. And the second you tell a group of clever programmers that not only are they being watched, but that they're being measured by the number of lines of code they produce, well -- stand back. I can only imagine the horrors that would ensue from written-out for loops, cut-and-pasted code, and -- from the cleverest -- automatic code generators. The simple idea that huge productivity gains can be achieved from code re-use is enough to kill the idea completely.

And so, having nixed the easiest option, what are we left with? Nothing terribly useful, I'm afraid. So unless I learn of a better idea -- and I'd be most grateful to hear everyone's suggestions -- I'll settle for an unquestionably non-scientific approach: for each project our team tackles this year, I'll record my own private estimate of how long I think it should take. Then I'll compare my estimates to the actual time taken. Hopefully my standards for estimation will remain consistent throughout the year, and this will yield some useful data that can help us get a sense of whether we're improving.