The runaway product

A couple of days ago I read The Mythical Business Layer on Worse than Failure.

There's nothing at all shocking in there.  However, the article did provoke me to think about a few cases of over-engineering I've seen (and participated in) where features were added to the underlying abstractions that were never exposed to end users due to "limitations in the UI."  *ahem*  Those "limitations" existed because the core development team lost sight of the product and introduced excess flexibility complexity in the system that was completely irrelevant to the business.  The UI team had a more stringent specification to work from so they could not go quite so far astray.

A story that sucks

I think one of the ways this happens goes a little bit like this:

Business Analyst: Our Vacuum product is doing great.  We've got 13% market penetration in the Light-Duty Household market segment but only 2% of the Families With Children segment.  I think we can do better than that.
Product Manager: How about adding a feature to provide more power for cleaning up tough spots?
Marketing Manager: Yeah, we could totally sell that to those people.  Let's call it the Ultra-Suck option.
Business Analyst: I think that might appeal.  Let me go crunch some numbers...

Time passes...

Project Manager: Ok, so we'll be implementing the Ultra-Suck option for our Vacuum product.  Here's how it will look.  We'll add this button over here under the handle that provides a 10% power boost.  We'll also beef up the thermal cut-offs on the motor in case of overheating.
Engineering 1: Ho hum.
Project Manager: This is a cool feature!  Heck, maybe in the next release we can add multiple boost settings and an adaptive power meter...
Engineering 2: Okay.
Engineering 1: !!

Time passes...

Engineer 1: I'm bored.  Another stupid Vacuum feature.  The business guys just don't understand what people want.
Engineer 2: Heh.  But did you hear about that adaptive power meter?  That sounds pretty cool.
Engineer 1: Yeah.  I guess since we should plan for it then.  We'll need a way to measure the current load and scale the output power to multiple levels.
Engineer 2: Maybe.  But there's no point trying to measure the load now if we aren't adaptively tuning the output power.
Engineer 1: Ok.  But it's pretty easy to add support for scaling the power output.  Right now we need need 100% and 110%, but later we'll probably want a range from 50% to 120%.  The circuit won't be that much different.  We can just hardwire the Ultra-Suck button to the 110% level.
Engineer 2: I'm not so sure...

Time passes...

Project Manager: Is the Ultra-Suck button done?
Engineer 1: No.  I'm having trouble with the circuit that selects a range of output power levels.
Project Manager: Don't we just need two levels?
Engineer 1: Yeah but later on we might need more for the adaptive power meter feature.
Project Manager: But right now we only need two.  Get it done.

Eventually the project schedule slips due to "unforeseen difficulties" in the implementation.  The fanciful features of the anticipated future model may never come to be.  Meanwhile the product has acquired a lot of added complexity and has shown no net gain from all of this work.

The moral

While this story is somewhat contrived in the world of mass-produced physical consumer goods where unit production costs are very high, it happens all too often in software.  Somewhere along the way, the original narrowly focused business objective is lost.  "Just a little tweak here, a little tweak there."  But each tweak raises the cost of development, testing and maintenance.

That's not good!  There is zero business value to any of this extra work until it becomes relevant to the product.

Aside: I'm lying a bit when I say there is zero business value.  After all, the extra complexity may help to provide motivation to get things done.  Good people are hard to replace so there should be some allowance for keeping them happy.  However, I strongly prefer reserving 20% time for such projects in lieu of allowing the core products to become unnecessarily complicated.