Creeping Featuritis War Stories

WarStories about mismanagement of software features.

Lots of projects get in trouble because of what seems like CreepingFeaturitis. If you've been on some, and learned anything, pass it on here.

OakTreeSoftware

It seems to me that Oak Tree got in trouble in part because management, sales, and marketing had long lists of what was "necessary" to the product. The guy doing the product part of the development had a pretty good list of what he thought would be done and what wouldn't. It seemed to me that no one really believed the list, instead just demanding that more be done.

On the technical side, we hadn't learned how to estimate how long things would take - we just kept accepting priorities and working as hard as we could. So even though the product guy had his list, our behavior wasn't supporting the use of the list.

What if the product guy and I had put our knowledge together and estimated all the features, perhaps on cards? What if we had sat down with management, sales, marketing and said: "This is how long all these things will take. These are the (few) dependencies. Your job is to put them in order, so as to have the best product by any given date."

They would certainly have railed at us to go faster. We could have said, "We'll try to go faster. We'll get together frequently to tell you how things are going. Meanwhile, this is our best estimate of how long things will take. Your job is to put them in order, so as to have the best product by any given date."

Maybe we were good enough, maybe we weren't. We were, however, the team they had, and we could have done better at informing them where we were going to wind up.

They would at least have been better equipped to make tradeoffs, such as not investing quite so much in human factors frills and more in performance or function. As it stood, we just did our best and it wasn't quite good enough.

They might have cancelled sooner. They might have decided to send us away and get better techies. I believe that neither would have happened. I believe they would have made better decisions on how to invest, and would have had a better shot at a successful, if smaller, product. --RonJeffries

In among the successes (half a billion dollars of software sold), I've had plenty of setbacks. These mostly seem to me to have been of the same form: the sales guys weren't getting what they wanted when they wanted it. Sometimes these were because we were working on something other than what they wanted. Sometimes that was necessary, sometimes it was a mistake.

In all cases, the sales guys and the techies weren't working from the same list. What if we had done something like PlanningGame with them? Again, I feel that we could only have done better. Maybe I'd be up to a billion ... --RonJeffries

I was on a project once that had grossly underestimated the effort required to produce some of the features in the customer specification. So the project manager met with the customer to see if there was any way to extend the deadline, so that we could finish the features they wanted. He returned with good news - the customer was ok with moving the deadline out. But then he said "But to get them to agree with this, I had to promise them we'd deliver these 3 additional features". Stunned silence ensued; we were unable to comprehend the total lack of logic the PM was presenting us. --PeteHardie

Back in the early '90s I was working for The Hedman Company (defunct, or not, since 1995, depending on whom you believe) making check protection equipment and teller machines. One particular model, the HE-1700 (http://www.moneyprocessingsystems.com/products/Hedman/HE1700.html), was a horrid pile of compromises. This machine was based on an 80286 ISA main board running MS-DOS 5 with a Phar Lap DOS extender and a dot matrix printer for check writing and signing. The only hardware I had to "design" was the pullup resistor on the optical sensor for the paper position registration, and that resistor ended up being crimped into the connector pin along with the sensor wire. Heh.

I was the firm's only hardware/software engineer working on the product, so they brought in a couple of alternating rent-a-bodies for more development horsepower. (Naturally, I was responsible for getting all the work done, even though I had no authority to actually assign specific tasks to specific people. I tried, but they didn't want to pay me "manager's" wages. <sigh>) After a few months of trying to get various people to agree on what the product was supposed to do I finally wrote a memo to all concerned pointing out that we had no spec. There were something like 14 individual memos and publications regarding the requirements for the HE-1700 (!), but no central spec. I called a halt to product development until we could get all the sales, marketing, and upper management people on the same page as far as requirements went. My boss, the second worst boss I've ever had, actually backed me up on this. I worked on other stuff for a week or so whilst the furrowed brows at Hedman put their noggins together and decided what to do. At the end of that period the sales/marketing/management geniuses came up with a New! IMPROVED!! document that was supposed to "clarify" what the new product would do.

It was a fantasy describing a completely new product.

The original concept for the HE-1700 was a feature-based check writer/protector that could do everything the current line of products did but with more oofta. The braniacs came back with a description for an application-based product that resembled a desktop computer running multiple simultaneous, interactive applications rather than a set of buttons to do certain things. Uh, huh.

The bickering went on for a while, but I was laid off before too long, so I never saw the final result. Not much longer after that the company closed its doors, or so I understand. You can still find Hedman products from several decades spread all over the Internet. Good luck getting parts and service, though. Heh, heh.

-- MartySchrader