SRE's impact on technical debt
Technical debt is everywhere. From illogical code to rudimentary architecture. It’s all there. And SREs have to put up with it too. Or do they?
You might remember about 10 years back when move fast, break things became the mantra for tech. It gave developers the green light to speed up their work. Commercial software could finally be updated every few weeks rather than every year.
My guess is that it also led us to come face-to-face with the dreary concept of technical debt. You know, when you have to push through the rough, crusty stuff (weird code) to get to the smooth, tasty stuff (proper code).
Technical debt has become more apparent as it’s now normal to make “quick and not-perfect” (aka agile) updates to the codebase in order to:
Meet deadlines and
Hit a constant barrage of product goals
You might not see it as quick and not-perfect at the time, but the spectre of less thought-out code will loom in the form of lengthy bug fixes and system crashes.
The end result: volatile performance. I’d say that’s more than a mere annoyance for highly committed SRE teams.
Can you think of some ways that contribute to technical debt build-up?
I’ve done some of that legwork for you. They are:
Weak Dev and Ops practices — the connection is weak and/or poorly defined
Poor documentation — can’t blame devs for this when the work is timeboxed
Ineffective automated testing — miss those obvious gaps, why don’t we?
But wait, SREs can’t tell developers what to do. Yes, that’s right, but you can influence the bits that make sure their code is of a reasonable standard.
And you can do that as an SRE by constantly working on your system’s testing apparatus (better automation) and bringing Dev and Ops closer (show the way).
Newer tools that help with code review can help with the latter. You can show developers how specific lines of code are impacting the application’s performance in production.
The ball is in your court.