Tag Archives: software development

what is tech debt or technical debt and how to manage it

What Is Tech Debt And How Do You Manage It

Image it’s crunch time… you’re focused on shipping, so things like tech debt aren’t on your mind.

Maybe you’re already thinking: “When is it NOT crunch time?!”

You’ve got eager customers who are waiting for you to ship product, your teammates are desperate to complete the release and move on, and you don’t want to be the bottleneck.

So what to do you?

You rush through writing your code and put in a quick fix. It’s good enough to pass tests and a quick code review.

Or maybe you’re not the one coding. You maybe one of the people encouraging someone else on your team to put in a quick fix and move on.

Unfortunately, crunch time doesn’t come around once in a blue moon. It happens more often than we’d like. Sayings like these don’t help: “Move fast!” “Break things!” And, “Ship code!”

As designers, product managers, and developers we are eager to share what we’ve built with customers. However, constantly operating by the seat of our pants comes at a price and that price is tech debt.

Whether you have or haven’t heard of tech debt, I’m pretty sure you’ve experienced its effects. If you’ve been on product teams that seem to constantly be putting out fires, you’ve probably noticed that over time all those quick fixes add up. And when it comes time to build something brand new, what would normally take a few hours or days, suddenly takes weeks or months.

The reason it takes so long is because there’s a lot of cruft built up in the code base. Continuing to layer on quick fixes will only destabilize the code and impact its quality.

If you’ve struggled to deal with tech debt on your product team, or want to educate new teammates on how to manage it, then today’s Build Tip is for you!

I’m joined by Jay Hum who is a Product Manager and Pivotal, and together we’re going to be sharing:

  • What tech debt it is and how to recognize it
  • When it make sense to accrue tech debt – yes there are time where it makes sense to let it build up
  • How to pay it down or just continue to ignore – unlike other types of debt, you don’t always need to pay down tech debt
  • When it’s too late to pay down debt tech and what to do


Be sure to share the episode with your teammates to help them understand the importance of tech debt!

Tell us in the comments below how you handle tech debt in your company.


Listen to the episode on iTunes!

You can listen to this episode of Build on iTunes.

Enjoyed this episode and want to watch more?

Subscribe to our YouTube channel to receive additional episodes.

Want more resources on tech debt? Here’s a link to the post Jay mentioned in the episode: Introduction to the Technical Debt Concept

Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.

What is tech debt and how do you manage it full transcript

Poornima: When your product has a nasty bug that’s impacting a lot of users, your first priority is to put a fix in that’s going to help resolve it. You might hear your developers say something like…

Developer: Yeah, I’ll just put in a quick fix.

Poornima: A week may go by, maybe possibly a month, and you’ve got another nasty bug on your hand. Your developer might tell you…

Developer: No problem, I’ll have that bug resolved by the end of the day.

Poornima: Later on, you might ask them to put in a new feature, and they may respond with…

Developer: Yeah, it’s going to take a while.

Poornima: How long?

Developer: Weeks, possibly months.

Poornima: “Weeks, possibly months!?” Why so long?

Developer: Tech debt.

What is tech debt?

Poornima: Wondering what’s tech debt, how to avoid it, and prevent it before it gets too unwieldy? I’m going to answer these questions and many more, in today’s quick *Build* tip.

Welcome to *Build*, brought to you by Pivotal Tracker. I’m your host, Poornima Vijayashanker. Today, I’ve got a *Build* tip for you. I’m joined by Jay Hum, who is a product manager at Pivotal. Jay, tell me what’s tech debt?

Jay Hum: Tech debt is the effort that builds up when a team makes a conscience decision to implement code that’s easy, instead of building out a best solution.

Poornima: OK, so what does that actually…

Jay Hum: The easy-to-implement, quick, messy code, is the debt. Like any type of debt, it accrues interest over time, and so the additional effort that is built up that could either be time, money, or resources, is the technical debt that builds up that makes it much more difficult in the long run to implement a better solution.

How do you avoid tech debt?

Jay Hum: Here is the interesting thing. Tech debt is usually thought of as a bad thing, something that needs to be paid down very quickly, or avoided as much as possible, or all together. However, tech debt is actually unavoidable. Much like financial debt, there is not necessarily good technical debt, but there is technical debt that you can deal with.

An example is, in the mortgage or student loan, where the principle plus the interest that you accrue could be lower than what you actually yield in terms of the investment. Any experienced or seasoned developer are always wanting to create the best possible solution that there is out there. However, sometimes you need to incur technical debt in order to get a product out to market quicker. Generally, the time to market, or the time pressure, is what makes technical debt unavoidable.

How do you manage tech debt?

Poornima: OK, it’s unavoidable. How can we manage it, while continuing to meet customer needs and pushing features out?

Jay Hum: Here’s the thing about technical debt that makes this sort of the analogy to financial debt a little dissimilar. You don’t actually have to pay down technical debt. For instance, when you’re building out a product or service, there could be parts of the code that aren’t used very often, or are not touched, that don’t need to be changed. The ROI on actually paying down that debt, or refactoring doesn’t get you much, or doesn’t get you anything there.                                                

One of the other ways to really look at it and approach it is build in technical debt into the product role map, or how you plan out your releases. When you think about it, you should be thinking about it in terms of what’s the upside potential versus the downside risk of either paying down technical debt, or not paying down technical debt, and relate that, to again, getting a product or service out to the market quicker, or spending more time and writing more cleaner quality code.

Poornima: All right, that’s great that we don’t have to always have to pay down tech debt, and that it’s OK to accumulate it, but how do we know when to make the trade off of paying it down, versus just letting it exist?

Jay Hum: Right, so one of the things that you want to look at, is what is the probability of the occurrence of something bad happening, or the probability of the occurrence of you having to do a major refactor because the technical debt has just gotten so big. Coupled with that, you also want to look at what is the impact.

Again, there is smaller technical debt, where the impact of paying it down is not very big. Again, there’s other parts where the technical debt can be very big, could lead to a big regression, and what is the impact on the delay to the market, or the impact to the customers that are actually using your product that’s in the market right now.

When you don’t need to pay down tech debt

Poornima: Do you have a example of a situation where you don’t need to pay down the tech debt, versus one where you do?

Jay Hum: Sure, yeah. I think a really good example would be if you take a look at an app through your analytics, and you’re looking at one of the features that you’ve implemented is not being used very often. This is a good example of, you probably don’t want to pay down technical debt on that feature, because again, it’s not a lot of people that are using it.                                           

Versus the flip side, so if you see that there is a feature that’s being used very heavily by your users, and that they’re clamoring for a feature that is sort of an add on to that feature, this is an instance where you would want to pay down technical debt quickly, so that you can build out that new feature that is an add on to the existing feature.

Is it ever too late to pay down tech debt?

Poornima: What happens if you leave tech debt around for too long? Is there ever a point where it’s too late to pay it down?

Jay Hum: There are instances where it is too late. Usually what that manifests itself is that you have to do a big rewrite. Which not a lot of people enjoy doing, both from a customer perspective, as well as the development team. If you go back to what I said earlier, if you realize that tech debt is unavoidable, and you build it into your product strategy, and your product roadmap, then there’s ways of being able to manage that tech debt at a good pace. So that you never have to end up with having to do a big rewrite.

Poornima: Thanks, Jay. This has been really helpful. Do you have any other resources for our audiences to check out?

Jay Hum: Yes, they should check out this article written by the Agile Alliance called “Introduction to Technical Debt Concept,” and it goes much more deeper into some of the concepts that I discussed here around technical debt.

Poornima: Now, Jay and I want to know, how do you guys handle tech debt at your company. Let us know in the comments below this video. OK, that’s it for today ‘s *Build* tip. Be sure to subscribe to our YouTube channel to receive more great episodes of *Build*, and *Build* tips like today’s. Special thanks to our sponsor Pivotal Tracker, for their help in producing today’s episode. Ciao for now.

Lesson 1: Why do so many MVPs Fail?

  • This is the first lesson in the series: How Non-Technical Founders Can Bring a Product to Market.

    By Poornima Vijayashanker

    One of the most common stories that I hear from people who reach out to me is the following: “I’m really stuck, I’m tired, and I’m about to burnout.  I’ve rebuilt this product 6 times and we’ve had 10,000 people download it or 10M people sign up, but we just cannot monetize. I don’t know what to do or what to build to get people to pay for our product.”

    So then I ask them 2 very basic questions: “What is your value proposition? And, what problem are you trying to solve?”

    Their response is of course a head scratch followed by, “What do you mean, we built this thing.” And they point to the product.

    I dig in a little deeper, “Well what problem does it solve?”

    But they’re just not sure.  It’s composed of a lot of features

    So then I move on to asking them, “Who are your customers?”

    And they respond once again with something generic like, “Ugh, women…”

    That’s when I have to tell them, “Stop building! Don’t build anything more.”

    Of course they are baffled, “You’re an engineer, why are you telling us not to build anything?”

    “You’re problem is not that you don’t know how to build a product or that you don’t know how to get people to try-it-out.  The problem is that you don’t know how to convey the value of your product to people.  So you don’t have an engineering problem, which is why I don’t want you to build anything more.  I want you to think about running an experiment.”

    Now you too as entrepreneurs and founders can run an experiment without a product.  I’ll explain the specifics of the experiment in the next lecture, but for now I want you to understand two concepts:

    The first concept is called an early adopter.

    An early adopter is someone who is eager to try new things, that is their mindset.  As a result, they are open to trying new products, solutions to acute problems, and having interesting experiences.  They do not expect a fully polished product.

    Contrast this to a mainstream customer who needs validation in one of the following forms: hearing about it from several friends, seeing that the company manufacturing the product has several seals of approval, or that it’s been around for awhile.

    Before you have built up an credibility as company or built a product, you need to find early adopters.  People who are willing to use and pay for your product, despite what it might lack in terms of features, and what how many bugs it might have in it.

    The second concept is called value proposition.

    You are proposing that a customer can expect to receive a certain experience or benefit from your product or service in exchange for a certain amount of money.

    Notice that this definition does not include, “My product has XYZ feature.”

    Before building anything it’s important to understand who the early adopter of your product is, and what the value proposition of your product is.

    In the next lecture, I will explain how to run an experiment in order to figure out who your early adopters are, and what your startup idea’s value proposition is.

    Did you enjoy this lesson? Got any questions for me on it? Please let it the comments below and I’ll be happy to answer it!

    Want more content on this topic? Checkout the following posts:

    Already built an MVP and ready to attract customers and generate revenue? Then check out our upcoming GROW IT Course here.

  • Growing Pains? Try Retooling.

    Growth is fun and exciting in a startup, but it can also be just a little painful and scary.

    Its scary because people can’t anticipate problems that arise from growth such as having customers, supporting them, answering their requests, and fixing the issues they experience with your product.  Or adding employees, training them, educating them on the vision of the company, keeping them motivated and collaborating with each other.  And then there’s the product itself!  More customers are using it, and generating data which leads to a less than awesome experience for your customers.

    This isn’t the time to feel overwhelmed.  Its the time to pat yourself on the back: you found product market fit and you’ve recruited some stellar people to help you out!

    Now you’ll need to change some processes to handle the growth which can be the painful part.  Its easy to throw money at the problem, but lets just say you you may or may not have access to a seemingly bottomless pit of cash.

    Figure out what you need not what you want.

    It all comes back to milestones.  Where do you want to be in 3 months, 6 months, and 1 year?  You don’t need to have definitive growth numbers for your startup but you need to put things in perspective.  Lets say you’re shopping around for a customer support ticketing system, and right now your growth is fairly predictable and manageable by a single human being and possibly part time.  In that case don’t buy something that’s going to cost more than what a single customer is paying you monthly.  You might even be fine  doing support via email and phone, and it will probably aid in your customer development process to have someone listening for feedback.  If your customer support person starts to get inundated then its the time to look into a system to organized.

    Start shopping for products when you want to cut down on human labor costs that are quantifiable by time and money.  The people you hire are smart, so invest in their productivity and happiness, and don’t let them become drones by having them do repetitive mundane tasks that aren’t advancing themselves or the company.

    Building vs. buying?

    You’ve isolated a few areas in which you need to put a new tool in place or replace an old one.  As engineers running a company its easy to say: “Oh I’ll just build it!”  Wrong answer.  Yes it might be super easy for you to whip something up, but who’s going to test that new tool, maintain the code base, and add on to it?  If its you great!  You now have a new department: internal tools.  Oh you’re small… well then you just cut down on product development.

    Save yourself some keystrokes and shop around for products instead.  As I mentioned before, if you identified your needs then it becomes easier to tell people what you want and to shop around for it.  Yes there are times when you might not find what you’re looking for, and it might make sense to build it in house if its cost effective (cost == time + money).  If you find a product that satisfies 70-80% of your needs and is within your budget buy it!

    When I was working at Mint I had the painful task of searching for an email provider to handle all the outbound emails we were sending.  Integration was a nightmare especially given the products that were in the market at the time.  Had I taken a little more time to do research I would have found MailChimp and been happier.  Live and learn.

    Fortunately I did learn, a different lesson while working there, put off managed hosting for as long as possible.  Which is why  when I started BizeeBee I went with Heroku.  Could I have written deploy scripts, and the add-ons that they offer on my own?  Sure, in fact I wrote some of them at Mint (sms and email messaging, performance monitoring, etc) in Java!  But going with a solution like Heroku for less than $100 a month gave me the freedom to build, iterate, and launch BizeeBee all in the same year!  Did I mention $100 is also less than the going rate of a developer pretty much anywhere.

    How long will the solution last?

    Remember the title of this article is retooling.  If your startup is on a growth trajectory it will outgrow tools, and you’ll need to refine processes.  Get comfortable with it.  They key is to identify when you’ve outgrown a product or anticipate when you will.

    Sometimes you can live with a less than perfect solution for awhile, especially if its cheaper than the alternative in terms of setup and maintenance.  Just acknowledge the limitations, and prepare to fix them if they cut into progress.  For example, at BizeeBee we have a customer support tool that I built.  Its not perfect,  it drags the system down a little when we run large queries, but we’re operating with limited resources.  I’ve optimized the queries once they really start to impact application performance, but I haven’t yet setup a dedicated database, and optimized the heck out of it, because I have other priorities.  I’ll throw resources at it when it start to cost us customers and time, or isn’t serving its purpose.

    ROI

    Retooling is not a cost.  Its a cost if you do it prematurely.  If you do it when you absolutely need to or when you anticipate a need arising then it can actually be aid in the growth of the company.  Once again figure out what you need.  Do you need to grow your user base?  Do you need to keep your customer happy?  Do you need to get paid on time?  Do you need your employees to be happy and productive?  Those should translate to what you’re looking for in a solution.

    Retooling isn’t just about finding the right tool, its also about finding the tool that will help you you meet your next milestones, and once you reach them you’ll need to retool again.  Happy retooling! 😀