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.

Comments

• Anonymous
  April 09, 2010
  i know!!

• Anonymous
  April 09, 2010
  Well Said...Sometimes we jump into Value Added Service wagon without giving it another thought... Does the client really need that value is never thought and it might be possible that a Value we are adding is never used by the client. And if that is the case then putting time to implement that feature is waste of time which means uneccesary cost...

• Anonymous
  April 12, 2010
  Yes! In fact, I'm tempted to toss all of my other (motherhood and apple pie) architectural principles (like "loosely coupled" and "data is an asset") out the the window and go with the three that pretty sum up what really matters:

1.  YAGNI (You Ain't Gonna Need It)
2.  DRY (Don't Repeat Yourself)
3.  KISS (Keep It Simple & Stupid) In that order.

• Anonymous
  April 14, 2010
  Yes ! and there is another option :

4. Call the business and ask ! If you can contribute to better requirements, just do it. Then it may come up with issues on time, budget ... but at least, you asked. Imagine in other business if there were such practices !! I included a coffee machine in the iPad just in case because I like to drink coffee while reading and a fan because it is warm where I live !!

• Anonymous
  April 15, 2010
  Hi Frank, The danger of "adding a requirement" and then asking the business if it is actually a requirement is that the business may make the assumption that your requirement is free, precisely because it came from you.  Make sure that the business understands the costs of the requirements that you added to the scope! Of course, good communication is key here, but I would also suggest that you start by mapping requirements to capabilities and mark the "value" of the requirement by the "value" of the capability that it provides.  The value of the capability is the difference between where the capability needs to be, in order to serve the business strategy, and where it currently stands.  Therefore, a requirement that closes a big gap in needed capabilities is more valuable than a requirement that adds on to an already mature capability. That way, when it comes time to cut scope in order to meet a delivery or cost target, the business gets what it actually needs.