Schedule Disease

Septermber 22, 1998 - Jack Harich - Home Page

There is a massive plague in the software industry which, until the specific viral strain is identified, we will call Schedule Disease. It is a silent killer of schedules, projects, products, managers and developers. The infected host is the software organization. The carriers are infected developers and managers. Schedule Disease multiplies most rapidly when the host attempts to repeatedly hit overly ambitions schedules while sublimating all else. Left untreated, Schedule Disease weakens the host to a state of chronic dementia where it cannot survive serious competition and is forced, often without even knowing it, to compete in small, worthless markets. The weakened host exudes decayed, destroyed or burned out cells, also called people.

I first noticed this phenomenon when called in to provide "Java training and general consulting" to an infected host. Like most, they were unaware of the infection since they had no regular physician. During the interview a few probes detected no trace of object-oriented practices, so I expanded my role to include that. A non-confrontational series of dialectic probes and responses revealed the host's flagship product had a few milestones for its 3.0 release, but no serious planning, analysis, design or detailed schedule to get there. This was a 2 year old host with 20 cells (employees) growing at about 2 cells a month due to the product selling like hotcakes.

By Day One I'd prepared the usual:

This pre-prepared dose of medicine, I thought, should be sufficient to wipe out the infections I usually encounter, and innoculate the host against further attacks. Wrong...

But let me first explain. Innoculation is the practice of implanting a disease in a person or animal by the introduction of germs or virus, as through a puncture, in order to produce a mild form of the disease and therefore secure immunity. Typically the innoculated organism feels a bit of puncture pain, followed by minor swelling and discomfort.

However, in this case the host was already infected and the vaccination, while praised, had no effect. After 4 weeks of patient treatment, the observable symptoms include:

For example I proposed 2 hours a day of project management, process and object-oriented training. "No way, we don't have the time." I countered with a 1 hour a week software review. He responded with "Is 1 hour enough?" This was good news of course. We were now making some progress. So we scheduled a 2 hour review.

For the first one I passed out project notebooks with sections for Notes, Project, Models, Reference and 5 blank sections for custom use. The Reference section had chapter 11 (25 pages), "Guidelines for Software Quality", from "Program Smarter, Not Harder" by Johnson et al. We started by reading this quietly. It explained a ton of stuff quickly, notably SEI's Capability Maturity Model (CMM) and "Walkthroughs, Reviews and Inspections".

The reactions were varied and telling:

This laid the stage for a hopefully productive first encounter with a formal sofware review.

BTW, this was the third week, and we had completed a solid high level design for the client portion of the client/server product using layered architecture with frameworks and plugpoints. They were working on learning Java and developing plugpoints. I was doing the high level design and infrastructure implementation. My generic schedule, to my surprise, had served well for three weeks unmodified. Things were going moderately well on the surface, considering the advanced state of the patient's infection.

It's important to let people learn by doing and making decisions themselves, so I offered the choice of reviewing the client architecture, the transaction subsystem, the infrastructure or some plugpoint implementations. They chose the transaction subsystem, because it was high risk, incompletely implemented and untested.

We walked through the subsystem design, explaining and examining each aspect and assumption. This was easy to do, since we had good models, a partial implementation and related APIs. But the subsystem design had been rushed, and was preceeded by no analysis, I noticed. So I identified key use cases and we hit the design with them to see how it would hold up. Guess what?

Boom! The design broke down quickly. It seems that the client had responsibilty for transaction logic. Their strategy had been to go for a multitude of server APIs and put the real value and logic on the client in Java. But this greatly complicated the steps the client had to take to manage transactions, and left the entire system vulnerable to broken connections, server bugs, changes in server logic, etc. The review also revealed a whole category of server mutations that were uncovered by the client's transaction logic. In short, the design would not work. Why? They had skipped any real analysis or formal design long ago, when the strategy was set. They had relied on good sharp seat-of-the-pants development and heroic efforts to save the day, as it always had when the product was simpler. BTW, they consider the 2.0 version of the product to be hard to maintain, feature short, hard to add new features or reuse, plus the GUI is terrible, so the 3.0 version is a complete redesign and rewrite.

Opening my own project notebook and flipping to the Notes section, I see my notes for that meeting. It was falling into chaos and panic, so I summarized and suggested with:

And pointed out this was all standard practice. This all greatly focused the discussion, and they proceeded to flesh out details. It took a bit of effort to keep discussion at a high level, because they were not used to thinking abstractly or planning anything in detail. The net result was a huge defect was detected and resolved, with a 1 week schedule slip.

This meeting was on September 18. Although FCS is not until March 99, the current prototype with Java GUI, transactions and about a dozen user tasks is due October 10 for presentation to a major customer. So as you can see, a 1 week slip is disaster. The manager was upset. The meeting took 5 hours instead of 2 hours.

That's what a single review accomplished. My concern is there are many more such time bombs lurking. There is a clear need for training in crucial areas such as analysis and design. Above all, the organization needs to move to an attitude of continual improvement first and hitting schedules second.

Over the past week I've noticed I felt odd, kinda tense, no longer focused on improving my reusables and process, and instead preoccupied with quickly getting the project done. Although my frameworks are getting their second real world test and are holding up well, I find myself taking more and more shortcuts. It's code, code, code like mad.

My preferred ratio of 1/3 analysis and design, 1/3 implement and test, 1/3 improvement of self, resuables or organization has suffered.

I suspect I'm becoming infected with Schedule Disease. This has me worried.

The host has been diagonised with Schedule Disease. But they refused to take any medicine.

We end with a single question: - What would you do?

After you have pondered, try this link. We talked about all this on the JSL list and had a good thread going. The above was the thread kickoff. The link is my summation. Surprise Ending.