The Pain of Paying Technical Debt
Technical Debt had struck again. I was working my way through morning tasks when I started seeing emails customer emails come streaming in — they weren’t happy..
Our team had been developing new features and testing them in our production environment. These errors had been getting further in between, but the fact that they were still happening because we didn’t have a proper DevOps workflow wasn’t okay. Our customers (and their customers!) were being impacted because of our unprotected process.
It’s tough not to be embarrassed when you see support requests coming in for issues like this. Even when they are can be resolved promptly.
Technical debt sucks, literally. It’s a time suck and takes significant resources. Even though it provides more stability and efficiency, our customers typically don’t see or feel the full impact of the effort exerted.
It’s a relentless cycle.
Since our customers don’t feel the immediate impact of these resource hogging builds, we have historically put them off. The longer we put them off, the bigger resource drain they became. We kept using old workflows, new people were trained to use them, and these all became reasons not to pay the technical debt.
But we’ve made a change! We shipped our new Dev & QA environments on Monday, and we have a list of other technical debt yet to pay that we’re going to fix incrementally.
What I’m learning while paying technical debt:
1. It’s often thankless, and I need get over it.
As much as I wish our customers would email me and say, “Wow, thank you so much for putting the resources into making the web app have fewer errors!”, They typically don’t. We still publicize these improvements though. After all, our customers are wondering what we’ve been working on the past few weeks without any other announcements of new features.
2. Delaying it makes leads to bigger problems.
How often do you say, “Eh, it’s probably fine…” and then regret it? Not often? Well, I wish I could be in your shoes. Whenever we get to this point and start to rationalize putting off overdue projects, it almost always comes back to bite us. We didn’t test the content editor thoroughly enough last spring before shipping it. After launch, we found out that *oops* users couldn’t change their font size more than once before saving their page and reloading…Yikes. That was a glaring issue after we were promoting our “updated & easy to use CMS”.
3. Sometimes your developers will push back.
I love that I can have an open dialog with the development team where everyone shares how they feel. Most times, the consensus is that it is easier for things to stay how they are despite the risks. This is dangerous, and another reason I believe in all hands support. It’s hard for everyone to be on the same page when only a few reps interact directly with the end users reporting issues or asking for help. A developer who sees the same issue come through and answers it five times is more likely to proactively fix the issue.
As a non-technical person, I know that I bring up ideas, at times, that make the developers cringe. They help me see the holes in my ideas though and how to tighten it up in a way that encourages healthy adaptations to our app. (So, this isn’t hate mail for you developers out there reading this!)
4. When disaster strikes, own it.
Customers value openness and communication over almost everything else. Don’t try to skirt the issue when your app is having problems and hope a minimal number of people notice. Update your status page, keep your customers in the loop, and attempt to use the situation to build trust.
Even the worst of situations can yield promising customer feedback and reaction if you handle the issues promptly and with clear communication about what’s happening and what you’re doing to fix it.