Tag Archives: women in tech

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.

Calling all women: Contribute to Wikipedia

Wikipedia LogoWhile the tech industry is a lovely melting pot of people and innovation, it can be overwhelming to stay abreast of it all. New technologies, companies, and acronyms pop up all the time. We work with people from varied cultures, with traditions and holidays different from our own.  I’ll admit that I’m regularly in meetings where I hear something I don’t know — a technical buzz phrase, a reference to an Indian holiday or Hindu god, or a colloquial expression whose meaning I’m not quite sure of. When this happens, I tend to look it up on Wikipedia. It’s a quick way for me to get a general grasp of the topic.

A few years back, I was in a meeting for an upcoming software release, and the engineering leader said, “That feature will be a cake walk.” While I thought “cake walk” meant something easy, I started second guessing myself. What if it meant it would be a difficult feature to build? I didn’t want to sound stupid when I started talking about the feature, so I quickly looked up “cake walk” on Wikipedia, clicked on the “Modern Times” heading, and read that it’s used to describe something that’s very easy or effortless. Got it! I then returned my full attention to the meeting…

Ever since then, I’ve thought about making a contribution to Wikipedia. Not only do I want to pay it forward and help others who use Wikipedia like me, I also want to help change the ratio of how many contributions are made by women. While I don’t have anything against men editing pages for Wikipedia, I don’t want them to be the only ones writing our history. I think it’s important that women’s memories and perspectives are included and preserved.

Did you know that less than 15% of Wikipedia’s contributions are made by women? Of the 30,000-40,000 daily edits to the English Wikipedia site this month (June 2013), only about 1500-2000, or roughly 5%, are made by women. (Note about chart: Drop-off on June 24 is due to the time of day – early morning – that the snapshot was taken.)


Chart showing gender gap in Wikipedia edits during June

Even though I wanted to make a contribution to Wikipedia, I just never got around to it. Well, until I wrote a blog post about professional bucket lists where I shared what’s on mine. Yup, writing for Wikipedia was on my bucket list. Boring, but true.

What changed when I wrote that blog post? Research shows we’re more likely to accomplish something by sharing it with others. (You can read a summary of this research by Gail Matthews, PhD, published on the Dominican University web site.) In fact, as soon as I wrote the first draft of that blog post, I took the plunge into Wikipedia. And, it was a cake walk! I chose to contribute to two software projects that I had worked on earlier in my career:


If you’re a woman and you’re already contributing to wikipedia, thank you!  If you’re not already on Wikipedia, please consider creating an account and sharing your knowledge. Either way, be sure to specify your gender in your account preferences to have your contributions count towards changing the ratio. (The default gender setting is “Undisclosed.”)


P.S. Interested in more statistics about Wikipedia? Here are just a few:



A simple yet powerful phrase

by Karen Catlin

[dropcap bg=”#ba82e0″ color=”#ffffff”]If[/dropcap]you receive the Femgineer weekly email, you’ll remember that last week’s theme was about clarity, and how we often beat around the bush instead of just asking for what we want. I’m as guilty of this as the next person! Even if I think I’m being direct, I make mistakes such as:

  • Using passive voice, which dilutes an otherwise direct request. “The dishwasher needs to be emptied.” vs “Please empty the dishwasher.”
  • Using extra words that take away from the clarity of my ask. “It would be great if you could take out the trash.” vs. “Please take out the trash.”


Yes, the simplest phrases are the most powerful. My favorite is one that I heard at a seminar for parents at my children’s high school. The speakers shared statistics about teenage drug & alcohol use and told us about their first-hand experiences with addiction. They also recommended that we tell our kids, “My expectations are that you won’t do illegal drugs and that you won’t drink until you are 21, and then that you will do so responsibly.”

I felt like hitting myself on the side of the head. While I wanted my children to stay away from drugs and alcohol, I don’t think I had ever explicitly told them. At breakfast the next morning, I mentioned the seminar, and I replayed the exact phrase, “My expectations are…”

Will these words alone be enough to keep my kids from experimenting? Of course not. But, by saying them, I reinforced our family values in the context of drug use and underage drinking, and I felt I was doing so in a way that was respectful and demonstrated that I trusted them to make good choices.

[dropcap bg=”#ba82e0″ color=”#ffffff”]It[/dropcap]got me thinking about the equivalent in leadership, and how I could make use of the phrase, “My expectations are…” when I delegate projects, write performance reviews, and speak at employee meetings. Using these words, I could describe things in a way that would show my trust, motivate them, and perhaps even inspire them to achieve more than they thought they could. E.g., “My expectations for the budget proposal are that you will deliver an executive summary with a detailed spreadsheet, by the deadline, and that you will identify the right people to work with so that the proposal is accepted quickly.”

To explore using this phrase in a written performance evaluation, I decided to dust off some of my past reviews. In one, a manager gave me somewhat vague input into what I should be doing:

  • “Over the coming year it will be very helpful for you to continue your advocacy for your group and the collaboration with the business units…”
  • “I encourage you to focus more time on a longer term roadmap for your group…”
  • “I also encourage you to continue building out your thoughts on areas for you to have greater impact than you even do now at the company and where that may lead to developing skills further…”


Imagine how much more effective and empowering his guidance would have had if he had used the “My expectations are” phrase:

  • “Over the coming year, my expectations are that you will meet with all the key players in the business units, ensuring that there is excellent collaboration…”
  • “My expectations are that you will deliver a 3-year roadmap for your group…”
  • “My expectations are that you will identify two new service offerings, along with a plan for developing and rolling them out to the company.


So much better!

[dropcap bg=”#ba82e0″ color=”#ffffff”]?[/dropcap]Do you have a favorite simple yet powerful phrase to convey values, rules, directives, or goals? Please share it in the comments. I look forward to hearing from you.


Karen Catlin, a former software industry executive, is now a leadership coach and the latest member of the Femgineer team. She is passionate about helping women have successful careers in tech. She’s also the author of “Use Your Inside Voice“, a blog about the intersection of leadership and parenting; a version of this post was originally published there. Find her on Twitter at @kecatlin.