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.
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:
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.
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.
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:
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.
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.
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:
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!
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:
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.
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:
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!