Building less than you know you’ll need

In the past, I’ve been guilty of this sin: gold-plating.  Back when I was a solution architect, I would (often) think about the things that the business is going to need, but never asked for.  I would occasionally include elements in the design to support those needs, even though the business didn’t ask for them.  Here’s the sad thing: I considered it to be a good practice.

I was wrong.

Let’s pick a situation that most folks understand: e-commerce.  If you visit an e-commerce site and you buy something, you (the customer) will want to be able to track and cancel that order.  One common additional feature is the ability to track the shipment itself (through UPS, Fedex, or DHL).

You are building a brand new e-commerce system.  Let’s say that the business requirements ask for a set of pages for a shopper to view and cancel their orders.  But there is no requirement for tracking the shipment. 

Still, you know that someone will ask for it someday, so you build in some features to allow the shipment to be tracked.  Perhaps you hold on to the tracking company id, the tracking number, a URL for tracking, and some logic to pull it all together.  You even build a generalized “tracking API” so that a REST client can track the shipment in a mashup.  How cool is that!

That would be gold plating. 

Is it a sin?  Is this good or bad?  Well, occasionally it’s good.  I would suggest that most times, it is bad.  That is because I’m making many assumptions about the future of the software I’m writing. 

I’m assuming:

1. that the software will live long enough to get that requirement.  It is entirely possible that the software I’m writing today will be phased out long before that particular requirement is expressed by the business.  My software may even end up being replaced by a commercial off-the-shelf package, or online service, that has that feature already in it. 
    
2. that I am understanding the requirements correctly.  It is entirely possible that my assumptions about the “right” way to implement the “future feature” are incorrect, and that the cost to fix my guess may very well exceed the cost of fixing the software without my guess.  In other words, I could make things worse, not better, by guessing.
    
3. that my guess is not adding complexity and therefore increasing the cost of ownership unnecessarily.  This is a big one.  The cost of owning a system (managing it, maintaining it, hosting it, recovering from errors, etc) is directly proportional to the complexity of the software.  All those “hooks” for the future can add up.
    
4. that the time I’m spending putting in those hooks is spent in a valuable manner.  Business folks will often find themselves with a long list of features that they want in their software, and when developers hit them with the cost estimates, they will inevitably cut back on some of those features.  If we take time to add in features that they did not ask for, what about the features that they did want?  What of those?  The money we are spending belongs to the business.  The business should have the right to decide how that money is spent. 

In conclusion: It is often far better to write LESS software.  Just say “no” to putting in all the hooks that we believe that the business must want, but has not asked for.