Kode Vicious: Obvious Truths

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 supposed to when—bang!—it breaks. With a bit of debugging and a bit of time in the lab I can explain what’s broken to the vendor. I even have source code for the driver so I can patch it when I understand what’s broken and send them patches; sometimes they send me patches.

It’s the part where they send me patches that has been a bit more interesting. I had been faithfully applying patches from the vendor and testing their fixes and I kept getting this sneaking feeling that they were not testing the patches before they sent them out. I had that feeling not just because I’m a naturally paranoid and suspicious person, which I am, but because each patch would fix say, only 70% or 80% of the problem and then I’d have to provide the remaining bit of the fix. Finally, I got a patch that proved that although I am paranoid, it is not without reason. I applied a patch and it didn’t compile: the C keyword struct had been spelled incorrectly. Ha! I had them. They had not even applied their own patch; they were just sending me hacked bits of the driver that they thought would work. All I could think was, "Did you even compile this!?!?" But of course I already knew the answer.

---

People who send out a "small patch" without even compiling it are far too confident in their own abilities.

---

Now I don’t bring this up just because I like to say, "I told you so," because I don’t. I’d much prefer the code I received worked the first time, since my employers expect the same from me. I bring this up as yet another example of unwarranted programmer optimism.

People who send out a "small patch" without even compiling it are far too confident in their own abilities. Please! Stop! Don’t do that! I don’t care if you see bits in your dreams and they assemble correctly in the morning when you type them in. The amount of time you waste by not doing the most basic tests on code you’re patching isn’t only your own; it’s multiplied by all the hapless suckers who took your patch and tried to use it.

Returning to my earlier remark, I would have thought this was obvious—as obvious as how to spell "struct"—but I have discovered this is not the case.

KV

Back to Top

Back to Top