Three Breaths

Musings on code, management, and life

Just Because You Can, Doesn't Mean You Should

Posted at — Jan 21, 2009

I got a new car recently.  For the last 10 years, I have been driving a Jeep Cherokee with roll-down windows, manual door locks, and no modern conveniences other than air-bags.  Now I am getting used to all kinds of conveniences like lights that shut off on their own when I turn off the car, ABS, stability control, and even power windows and locks.  Basically all the good things that the rest of you have enjoyed for a while.

It took a bit for me to come to grips with the fact that a car with ABS can stop the car better on snow than I can by gently pumping the brakes.   And I am pretty sure that I’ll never get a dead battery because I left my lights on.  So what does all this have to do with software you ask.  Well I’ll tell you.

I love all these new features.  But there are a few things that my car does that I think may have been “cool” to the guy that designed it, but maybe not such a great idea in the long run.  My favorite example is the stability control system.  The stability control feature will do wonderful things like help keep me pointed in the right direction if I start to lose traction in snow.  What’s wrong with that….nothing, I love it.

What drives me crazy is that when the stability control automatically activates, an alarm sounds telling me that it has kicked in.  Now I have one job in all this and that is to drive the car, but when I hear an alarm my first reaction is to look at the dashboard and find out what is wrong.  Whoever designed this “feature” probably thought it was a cool thing to do, and we might as well use the buzzer in the dash for something, but is an unintended consequence of getting a driver to take his eyes off the road while losing traction a good thing?   I don’t think so.

We’ve all been in situations when we have wanted to do something because it would be fun to implement or maybe would use a technology that we’ve always wanted to try.  That isn’t a good enough reason to do put something into a product.  It needs to add value to your product and be the right approach.  If you want to try out a new technology, put it in a spike solution where you are free to experiment and where it stands alone and is easier to be reviewed. Prove that it works and show it to your peers.  Determine how it can make your product better and convince the product owners.

Being agile means responsing to changing requirements and technology, but product decisions need to be made in the light of day.

By the way, this has not been a problem on the teams I have worked on.  It’s just that we’ve been getting a lot of snow lately and that stability control alarm keeps going off.

comments powered by Disqus