How to determine when to put the brakes on
late-running projects and untested software patches.
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
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.
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
iLLustration by aLexey DuDoLaDoV / istockPhoto.com