• Hedonistic pricing and the problem of shared cost..

    I was reading this great blog post about the problems with estimating business value by Mike Cohn, and found that it identified a problem that has been nascent in my mind for a little while now.

    I won’t summarize the whole blog post here (you should just go read it!), but I will talk about how it gets me to thinking.

    We’ve recently started our company-wide steering committee process, and I have had a hard time deciding how fine or coarse-grained we should get when we make the relative priority tradeoff decisions.

    One of the values of getting fine-grained is that you can, theoretically, maximize ROI.  You can identify the lowest-hanging fruit by getting to the user story level.  Instead of looking at a large grouping of stories, which may have varying levels of importance to the business, you can look at the stories one-by-one and decide which ones are the most relevant right now (particularly based on their level of effort.)

    The problem with this approach, however, is that this approach can be more complex than it seems in practice.  The core reason is shared costing.  There is often times architectural work that is shared across multiple stories.  Or, there is work that can be combined and will take less time than if done separately.  One example we’ve thought about recently is our checkout system and our return system.  It’s probably more important to us to tackle the checkout enhancements.  But, if we combine the checkout and the returns in one initiative, then we can tackle much of the architecture at once, and it will probably take us 60% of the effort that it would if we did it separately.

    How do we take that into account at the ‘steering committee’ level?  I think the answer is that we don’t.  There are too many complex tradeoffs that exist like this when you get to the user story level.  I think we are better served at the epic level.

    I’ll experiment more soon and report back!

  • Technical debt

    Oh, the power of metaphor.  I have been thinking a lot about how powerful metaphors go a long way in creating effective communications and laying the foundation for solid teamwork.  One of my favorite metaphors currently is the term ‘technical debt.’  It draws an excellent parallel between the worlds of technology and finance.  Also, it is a very important concept that I think anyone in the world of technology should be aware of.

    What is technical debt mean?

    Technical debt is a metaphor that was originally coined by Ward Cunningham in 1992.  It likens the ‘cost of going fast’ in the world of technology to the ‘cost of buying something you can’t afford today’ in the world of finance.  Technical debt often refers to writing sub-optimal code for the purpose of shipping a product on time (or within the current iteration).  Like financial debt, the goal in taking out these ‘technical loans’ is to eventually pay them back.

    I sketched up a quick visual in the form of a box that explains the effort needed to do a technical task.:

    The area of the box is the total amount of effort needed to complete the activity.   The total effort of a task can be broken into two main parts: a) the part that makes it work and b) the part that makes it work really well (under the hood).  The issue here is that folks in the business care only about the blue box.  But, of course, technologists care about the green box.  Focusing on the blue box can drive a lot of business value in the short-term, but foregoing that ‘green effort’ does not come without a cost.

    Why is technical debt such an excellent metaphor?

    The power of any metaphor is driven directly by its ability to create a picture in your mind that quickly and efficiently gives you a model of how to think about something new.  The ‘technical debt’ metaphor is such a good one because it really does give us a clean, simple, and familiar framework to think about something that most of us don’t currently understand.  Let’s explore some of the similarities between technical and financial debt:

    • They both trade now for later.  When people go into debt, they are borrowing money to purchase something now as opposed to ‘saving up’ to buy it later.  That’s concept aligns perfectly with aiming to get some code out the door quickly.  You could ‘save up’ and do it elegantly and nicely, but that would take longer.  Might as well ‘borrow’ and get it out the door now.
    • They both build up over time.  People don’t get into money trouble overnight; and they often don’t get into technical trouble that way either.  It’s a slow and steady progression of taking some liberties that you should eventually rectify that really gets you.
    • Neither is necessarily a bad thing.  Debt is simply a financial instrument.  Many people use it quite effectively.  In fact, for very large purchases, most Americans would not be able to survive without debt.  (Imagine cutting a check for your house!)  Technical debt is the same.  The goal is to drive user value, and ‘borrowing time’ allows you do that more effectively.  Debt only becomes a problem when it spirals out of control.
    • Both can be paid down.  Just like you can make monthly payments to slowly chip away at your financial debt, you can incrementally pay back your technical debt.  The secret for both is the same: budgeting for it.
    • You CAN go bankrupt.  In your financial life, a series of small gaps can turn into a really big one.  If that happens, you might find yourself in a situation where you simply can’t get there from here.  Technology isn’t much different — at some point, the gap between where you are and where you need to be becomes too great.

    It’s importance and what you can do about it…

    I have lots more to say on this subject, but I don’t have the time to write about it just yet.  Stay tuned though!