Communications - June 2009

V
viewpoints
DOI: 10.1145/1516046.1516057
Kode vicious
obvious truths
How to determine when to put the brakes on
late-running projects and untested software patches.
Dear kV,

I’ve been working on a project that, like all software projects, is late. And we’re not just late a little, but a lot. The project was supposed to take four weeks and we’re now in our third month. People are blaming the usual suspects: poorly spec’d-out work, management interference, and lack of proper infrastructure. What I want to know is how late is too late? How do people decide to just stop a project?

Late and Getting Later
Dear Later,

If I understand you correctly, and I hope I can because your email message is both short and direct, you are involved in a project that has now taken more than twice as long as predicted to implement and is approaching the thrice mark. I would say this is scary if it weren’t so common. Projects take on a life of their own at some

point and when a group of people get together and continue to try to “look on the bright side” they keep finding “silver linings,” even though they are now drenched by the rain. It is amazing to me that a group of people who often seem so hard-headed and pragmatic—that is, engineers—can continue to believe there is a pot of gold just over the rainbow somewhere. Many projects can go on for years when they should have only gone on for months, so long as the money doesn’t run out.

From my point of view there are a few good places to pause and reflect in the life of the project.

1. You have gotten to the end of the

originally published schedule and the work is not even 50% complete.

2. The originally published schedule has been extended by 50% or more.

3. The schedule is updated daily and the dates keep getting further out.

4. The engineers avoid coming to team meetings and when they do attend they: a. break down in tears; b. pretend to be asleep; c. bang their heads on the table.

KV is in category C, but then I bet you knew that already. All of the above are indicators of schedule creep and a loss of control of the project. They are all good times to consider pulling the emergency brake handle. The reason the handle gets pulled so rarely is the aforementioned optimism of the staff, whereby if they “just work a little harder” the project will get done. I have never, in my entire working career, seen a project that is 50% off course get back on track because the team worked 80 hours a week instead of 60. Most people in high-pressure professions know how this works. The harder they work past a certain point, the more mistakes they make

and the worse their output becomes. Pilots, fire fighters, emergency-room doctors, and the like all know that past a certain point everything they do will actually cause more trouble than if they did nothing at all. Because our profession is not as extreme as theirs we seem to never learn this, which is a shame, because it’s an important lesson. Learn when to stop.

kV
Driver education

In this month’s installment of “things that ought to be obvious” I discuss patching, compiling, and testing code. I’m sure many of you have had these experiences before, and if you have a fun one to share please write to me and tell me about it.

I am sure most of you have heard the old programmer’s joke, “It compiles, ship it!,” which gets a good guffaw now and again from the denizens of cubicle land. I’m also sure that many readers have been subjected to using code that clearly compiled, ran maybe once, and then actually was shipped. But have you ever had to deal with people sending you patches that just didn’t work?

Recently, KV has been fixing a device driver that seems always to be very close to working. The driver wasn’t originally written by KV, and it certainly wasn’t originally tested by KV, although it now seems that the company I’m dealing with is using me as their unwitting alpha tester. There are few things more frustrating than a piece of software that almost works. It might tick along for days, doing just what it’s