Technical Debt - Our Approach to Building Cool Tech Profitably

This week Josh, Ben and Starr talk technical debt and how to cope with it. They also discuss "suits" vs "hackers" is a trope as old as tech itself. Suits want to make money and cut costs. Hackers want to build cool things the right way.

Full Transcript:
Ben:                If I start selling my kidneys, I'll let you know.

Starr:              Okay, that's cool. Do I get a friends and family discount?

Announcer:          You are in a maze of twisty little passages, all alike. Time to start a fire. Crack open a can of Tab, and settle in for Founder Quest.

Starr:              I thought originally that this podcast would be called something like Hard Technical Decisions, which sounds pretty hitting to me. Like, I like that, cause I think of myself as a dyed in the wool realist.

Josh:               Mm-hmm (affirmative)-

Starr:              Who's unafraid to face hard facts, you know? But, then we were talking about it in Slack and it turns out that some of the things I was originally going to highlight, as tough Hard Technical Decisions, were mistakes. Rather, were actually forms of technical debt that we kind of took on on purpose, that we knew what we were getting into. Maybe not exactly to what depth we were getting into them,. But, we knew that something was happening.

Starr:              And, so, this week's topic has kind of blossomed into something a little bit more interesting I think. So, yeah, personally, running a business and being an engineer means there's this sort of constant struggle between the engineer in me and the business man in me. But, what I mean by that is that there's this constant desire to want to do things right, the engineering way. But, then, you always have to trade that off between, what is the return on investment?

Starr:              Like, what are my business outcomes that I'm trying to achieve by doing this engineering.

Josh:               The engineering in you wants to achieve technical perfection but the business person in you wants to make money.

Starr:              Yeah. Exactly. So, I guess maybe we should go into like, what is technical debt. Let's talk a little bit about technical debt and stuff like this in general and then maybe we can go onto some specifics about our

Ben:                When I think of technical debt, the first phrase that comes to my mind is: "it seemed like a good idea at the time."

Ben:                Right? I think it's those things that you do with good intentions that just over time, didn't continue to scale, which is just a normal outgrowth of scaling. Or, over time became an obviously bad decision based on new information. So, you just have to change your mind and go back and fix it.

Josh:               Yeah. I tend to also throw maintenance costs in there. There's extra things that you have to do that come with the technical decisions that you have to make. And so, like, things like putting off, deferring some things like maintenance costs. For instance, like on Rails, like a Rails upgrade for instance.

Josh:               I know you can kind of get behind on those, or like push them down the road, and those can build up like a large overhead that you have to think about all at once, which to me is technical debt. And, there's all kinds of maintenance costs, I think, associated with software or infrastructure.

Starr:              That's interesting because my take on technical debt is maybe a little more specific? I've always considered technical debt as a way to bide time with shitty code. Right?

Starr:              When we first launched Honeybadger, I felt that the market was super rife for a competitor in the space. So, I felt like we really needed to ship something out very fast. And, as a result we made some decisions that made us able to get to market much more quickly than we would have otherwise. But then maybe, a year or two later, we came to regret those decisions. Maybe we didn't really regret them. Maybe we just had to come back and clean them up a little bit.

Starr:              So, one thing that we did, that I think falls definitely into the category of technical debt is that when we started ... Well, our service for people who don't know, is an exception monitoring service, right? We have a little snippet ... well, it's not a snippet, it's a library, that goes into your application. And, it sends us information whenever errors happen.

Starr:              And, what we did when we first started out, is that we actually kind of you know used the library of the main competitor, which was totally legal. Because, it was MIT licensed. And, we always knew we were going to replace this with our own library. And, we got a little bit of flack for it.

Starr:              But, in the end, I think it was sort of the right decision. What do you guys think about that decision?

Josh:               I think it definitely bought us some time of not having to like figure out or reinvent that wheel, basically, because it was a pretty well-established pattern. And, if you look at those same libraries, today, of everyone who does this, basically, they're pretty much all doing ... they're all basically copies of each other. They're all basically doing the exact same thing. It's a pretty well-established pattern of code.

Josh:               So, it definitely helped us get to market quicker. And, as you said, it's MIT licensed. SO, we included attribution and all that stuff.

Starr:              I suppose we should say it was MIT licensed before we did that.

Josh:               Yeah.

Starr:              And, then they changed the license. Which I don't really blame them for. But, it took a while. Josh, you were the one who was in charge of version 2 of the [gem] that was 100% developed by you. How long did that take? That took a while, didn't it?

Josh:               It took a number of months. It was a not a small project. I know by the time we got to that point obviously there were a number of reasons we wanted to re-write that code, or re-implement it. We wanted to kind of custom-tailor some things to our particular service. By that time, we had made enough decisions with the service, where we knew where we wanted to go and we could bring that to the client side and it made sense to re-do it. And, it also gave us the opportunity to re-think some of the decisions that we didn't get to make as a result of using that code from someone else up front.

Josh:               So, that probably added a little time to the project. But, I think, overall, it was useful to us.

Starr:              Yeah. So, it saved us several months maybe coming out of the gate.

Josh:               I think it would have been ... I mean we, obviously, wouldn't have started with probably ...