Friday 21 June 2013

The true cost of any given feature

There is a new wave of discussion lately in the evergreen topic of estimates and planning (e.g. #NoEstimates). But all sides seem to agree on the motivation for estimates, they just want to answer the need by different means. The need namely is to know the cost of any given development. The return of a feature is then estimated on the business side, and if cost < return then we should implement it. The cost of maintenance is very rarely considered seriously, even-though we all know that maintenance can cost just as much as development. But it's not what I'm getting at. My problem is that the unconsidered cost is usually much higher than what you would typically assume as the cost of maintenance. Any additional cost varies greatly depending on how well the feature was

  • concepted
  • implemented
  • documented
  • communicated  

Here is how it usually goes down:

You have a huge application, with tons of interrelated features. And/but the customer/product manager has yet a new idea about a relatively small enhancement that would make the customers' lives much easier.  (You know it's small because you hear phrases like "It shouldn't take more than a day", "It's just an extra checkbox that we can even hide optionally". ) It gets specked out. It turns out that it's not that simple because many surrounding feature, that seemed unrelated at first, are interfering. The effort start to seem more like 10 days now. This is an important moment because you have to make a choice: 

  • Option A: you go ahead and do it anyway
  • Option B: you build lots of limitations around the new feature as to protect it from all the interference that would screw up the initial estimation

The problem with Option A is obvious: you mess up the original equation of cost < return. So you are left with Option B, and now you are in real trouble, because you didn't even notice, you just got into trouble.

The trouble is that a half-baked, poorly concepted feature is very hard to communicate. The harder it is to communicate, the more questions and complaints you get, typically placing you at the beginning of the loop: "And/but the customer/product manager has yet a new idea about..." And to make everything worse you just added yet another feature to your system, that will once again increase the interference with the next new thing. 

You do this loop enough times and even the really small enhancements will take ages to implement. I wouldn't be in your shoes, man.

Is there a Option C? Think about what that could be? In the next post I want to talk about my Option C.

Read full post...