By Splunk September 17, 2007
Having lived through the software-as-building-architecture argument every few years i am accustomed to thinking of (refuting) how software and software development is (not) like the traditional field of building design and development. The analogy driven mind needs something to reference and i guess us noobs in software are desperate to find something historical to feel validated.
Every discipline needs a role model and building design seems to be our adopted hero.
This post proposes an analogy that is far less intellectual than a typical comparison between Christoper Alexander and the design of an EventLoop Abstract Factory class.
My analogy here is based more on THIS weekend with MY wife.
Our house is full of stuff.
This stuff; chairs, tables, artwork, rugs,… we have acquired for good reason – and we could use it. The problem is that despite all good intention these hand-me-downs, gifts, rash purchases, sometimes just don’t work.
Yes we need a coffee table in the front room – but not THAT one.
Maybe the design is wrong.
Maybe the size is wrong.
Maybe the idea of a coffee table that is also is a fireplace seemed like a good idea at the time but WTF.
Sometimes you just need to throw stuff away.
In fact, its best if you institutionalize the process so that you actually do it.
For us its a quarterly Sunday where we drink lots of coffee, send the kids out for the day, get worked up, and throw (give) shit away.
So my analogy here is not about refactoring or deleting obsolete/deprecated code – its about the stuff on the surface – Features.
At least at Splunk, features are a bit like the coffee table we bought on sale because we had guests coming and the fact that it was also a fireplace was a double win. Useful features in theory, and perhaps even for competitive reasons we *need* to have them. But man – like that awkward sofa that you got on craig’s list – the feature has to go.
Once a feature is in a product and in the docs and perhaps even some users might be using it the act of removing it because it does not fit requires a *process*.
We follow what WE call a scum process, and at a distance it might actually look a bit like scrum. These scrums are brilliant at ( in a controlled fashion ) adding new features to the product.
Now we are thinking of adding wholesale feature removal as a part of the process. A bit like those big company techniques of managing ( laying off ) the bottom 10% every quarter – how about managing out the bottom 10% of features every sprint. Even if it’s an “OK” feature, you must throw way to make way for the new. If there were a way to measure the desired surface area of a product ( like sqr footage in a house ) perhaps there should be a maximum number of features per some measure of software surface area. Beyond that – the bottom 10% features must go.
Back at home it was another successful Sunday purging useful crap.
I will miss the two pogo sticks that my wife finds in the bottom 10%.
Oh well…
e.