George called this week. The systemic solution loop in Shifting the Burden has taken over and he’s making the modifications requested by the users. Along the way, he’s read about himself, and has this to say about How Did This Happen? and Shifting the Burden.

The Root Problem

I would say that the root of the problem or “cause” was the pure and simple fact, that a poor decision was made to “band aid” a poorly designed system. If the correct decision was made in February of 2004, to replace the poorly designed, inherited system, it’s unfortunate to say this but, we would not have had the opportunity to meet, as I would have had a turn key system installed. I have proven to management here, … that it was a poor decision to band aid, rather than replace. The unfortunate problem now is that the system is running just good enough that it is much harder to justify a new system. You could argue that “just good enough” means the problem is fixed, but I have showed, using our Quality data, that even though we improved from a 33 %! defect rate down to a 3% average defect rate. That 3% adds up to approx 160K per year. There is more to the equation than just coding issues, you have hardware failures that add to the defect rate, which would be eliminated with a properly designed centralized control system.

One thing to remember that it was one guy who made the decision, I.E. it was not a group decision. In fact I almost had the go ahead to do the upgrade until our friend jumped in and decided to “save” the company money. Our friend moved to other places after the damage was done about 2 months after the decision was made to band aid. Pretty convenient eh? Not to mention the multitude of other management changes that have taken place over the past 2 years, in effort to try to make RTM work. Over all things are better now than they were 2 years ago.

The Sky is Falling

I agree with George. For the last two years we’ve been adding features (complexity) and size (lines of code) to a system that should be replaced. And now he’s adding 1/3 more functionality. The logical conclusion seems that sometime, possibly in the not to distant future, the system will implode from its heritage.

Three Ways to Solve a Problem

The original quality problem had three possible solutions:

  1. Solved: This solution provides the maximum possible benefit. George would have a new system properly designed to handle the process.
  2. Resolved: This is the “good enough” solution. The results are satisfactory, but not maximized. George’s current reality.
  3. Dissolved: By changing requirements (such as quality parameters), the problem could just “go away.” Not going to happen for George.

With my help, George now has a system that satisfices. His new problem is getting management on board to realize a change should be made before it’s too late.