• What you can do about Technical Debt


    In my last post, I introduced the ‘technical debt’ metaphor and talked a bit about why it makes a lot of sense.  In this post, I’d like to dive into why technical debt is so important and what you should be doing about it.

    Why is technical debt important?

    Technical debt is often overlooked because it generally has symptoms that lay ‘beneath the surface’ to the average user or manager.  By the time the symptoms become visible to the real world, it’s generally too late.  Those who ignore the importance of technical debt do so at their own peril.  Here’s why it should be top of mind:

    • You are likely to face challenges with technical debt at some point in the future.  That is, of course, unless you are already have accumulated some and don’t know it yet.
    • It is a problem that you sort of want to have.  That’s because it is a problem that scales with success and growth of your organization.  The faster the outside world makes you go, the more likely you are to rack up debt.
    • If you don’t deal with it, it will catch up to you.  And when it does, it’s likely to be a big problem, such as downtime, slow velocity, or low engineering morale.

    However, if you are smart enough to actually take the concept into account and work diligently to ensure you don’t go bankrupt, you’ll be a much better company.   You’ll be more agile and lean in the future because you’ll have a codebase that is ready for change and quick iteration.  If your code and/or infrastructure become stale and brittle, then you are simply asking to eventually become irrelevant.

    In my opinion, velocity is the key competitive advantage in any business: young or new.  If you don’t have the foundation laid to go fast when you need to, your competitors will be able to out-innovate you.

    What should you be doing about technical debt?

    Step 1: Acknowledge it

    Now that we know how important technical debt is, we can look into figuring out how to stay ahead of it.  The first thing to do is acknowledge that it exists.  While this sounds sort of simple, it actually can be more challenging than you think.  Most organizations have cultural elements that impede progress in recognizing debt.  In many organizations, sweeping things under the rug is a great way to keep management off of your back.  If you admit that something out there is sub-optimal, you’ll often get hounded and reprimanded by superiors.  In many organizations, the working environment doesn’t exactly value honesty and openness.  Mistakes are embarrassing, so you are better off not bringing them up.

    You cannot let this be your organization!!  Work to create a culture of honesty and open communication.  People shouldn’t be embarrassed of finding sub-optimal technical issues.  Instead, they should feel a sense of ownership and empowerment.  The best way to get issues like this on the table is to explicitly set aside time for digging into them.  I’ve had a lot of success with carving out time to talk about technical debt at the sprint/release planner level as well as bringing it up in team retrospectives.  If you don’t explicitly ask for people to think critically about areas for improvement, they may never bring them to light because they are so focused on driving velocity with the upcoming features.

    Step 2: Pay it back

    Now that your organization knows that technical debt exists, you need to start allocating time to pay it back.  The best way to allocate time to paying down technical debt is to build it into the velocity calculations of your existing iteration planners.  That approach works whether you are using story points for estimation or hours for estimation.  Let’s say that your team has an average velocity of 10 story points for each iteration.  But you’ve come to find that there are is some sub-optimal code sprinkled throughout the  codebase.  You can start by allocating 20% of your time to paying down the debt.  So the team can take 8 points of normal feature work and 2 points of technical debt work off the backlog.

    The key here lies in staying consistent.  Whatever you do, try to keep it up and make it part of your normal team process.  If you decide to maintain a backlog for technical debt, or you want to build technical debt tasks into your main backlog, just be sure to continue revisiting it and re-prioritizing it (like you should be doing with all your other tasks).  And be sure to consistently spend some velocity, even if its a very tiny amount, paying down the debt.  Just like with any amount of debt, you don’t want to continually be running a deficit.

    Occasionally, you may find yourself in a place where you can do a ‘big payback’ of debt.  That’s sort of like overpaying on your mortgage to pay down the principal — it can’t hurt.  Sometimes the urgency of feature velocity is lower than others.  Also, sometimes there are bottlenecks in other parts of the organization that give you some time to focus.  At ModCloth, we engage in a ‘feature-lock’ around Holiday time, which gives us the ability to spend a little more time on debt than usual.

    Some takeaways and other insights

    So we’re done exploring some of why technical debt is so important and what you can be doing to stay ahead of it.  Some things to keep in mind going forward are:

    • This is one of the more advanced concepts of engineering and product development.  Don’t beat yourself up if you aren’t effectively managing it yet.  If you’re thinking about it, you are ahead of most of the game.
    • Effectively managing your technical debt really falls under the bigger umbrella of staying relevant and agile.  Agility allows you to be ready for change.  Anyone that has been in product development for long enough knows that your product is likely to become more of a liability than an asset at some point in the future.  The degree to which you can keep your technology relevant is the critical factor in how long your product remains an asset.
  • 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!

  • Goodbye work-life balance!


    Why ‘Work-Life Balance’ is a bad phrase

    We’ve been talking a lot lately about building a great business that endures here at ModCloth over the last several months.  One of the phrases that often comes up in this context is “work-life balance.’  The more I think about the phrase, the more I realize that it is framed incorrectly.  It drives people towards an unhealthy way of thinking.  So we should change it.

    When I search the net for the definition of the word ‘balance,’ here are some definitions that come up:

    • a state of equilibrium
    • equality of distribution
    • harmonious arrangement or relation of parts or elements within a whole
    • the difference in magnitude between opposing forces or influences

    All of these definitions get me to thinking the same thing: balance is about having the ‘right amount’ of something.  If you have too much or too little of something, you are inherently out of balance.  So the term ‘work-life balance’ makes me feel like my work and my life are somehow at odds.  They are opposing forces that I must find a way to balance.

    Bottom line: I don’t like it. I want more from life.  I spend my time working because I want to — I enjoy spending my time doing it.  The things I enjoy should not be at odds with my life; they are my life.

    So, it’s time to use a new term: Work-Life Alignment.

    Why ‘Work-Life Alignment’ is better

    Now we’re talking!  Work-life alignment jives a lot better with the kind of life I want to live.  The thing that I do for more than 10 hours a day should not have to be ‘balanced’ with my life.  It should be aligned with my life.

    When I look up the word ‘alignment,’ I find:

    • bring into proper or desirable coordination correlation
    • alliance or union with a party, cause, etc.
    • integration or harmonization of aims, practices

    I spend my time working with excellent people who  challenge me everyday.  The skills I want to hone align directly with what I do for a living.  I also am fortunate enough to spend some time ‘working’ with my wife — on a business that she started and I invested in.  For me, my work happens to be a big part of my life.   The word ‘alignment’ captures that much better than ‘balance’ does!

    When people ask me about ‘work-life balance,’ I have a hard time answering them because I think their question is framed incorrectly.  Next time, I’ll tell them that I don’t believe in work-life balance; I believe in work-life alignment!