Escaping the Eagle
or How We’re Biting the Bullet and Deciding to Start Paying Our Technical Debts
We’ve all heard of messes like these. We’ve read horror stories about some dev team loaded with pressure from upstairs to ‘get it shipped’ and someone said ‘hey, we have X that kinda looks like Y, why don’t we build Y on top of X!’ and at that point in time, it sounds like a brilliant idea.
A couple of smart hacks later and there’s a shippable Fave app, which under the hood was a modified KFit app that would serve either Fave or KFit stuff depending on how you connect to it. Sounds lovely doesn’t it?
Bugs were under control because the original team was there and they knew the code inside out. They were on top of things. Users were loving the app and their numbers were growing fast. Champagne and balloons! Life is peachy!
But then the numbers started growing faster. The app (the Fave bits at least) started becoming bigger and bigger. Some of the original devs moved on to other endeavours at other companies. The people who knew the code inside out were an endangered species.
Features would be baked on top of an already multilayered lasagna, the Fave meat melded in with the KFit cheese. And if you weren’t careful when digging in, you’d end up with a shirt full of 500 Internal Server Error sauce.
Everyone kinda knew what needed to be done, but from a business standpoint new features always trumped refactoring code. Companies need to grow to survive, and rewriting code so that it does the same thing as it did before only faster isn’t exactly the kind of milkshake that brings all the boys to the yard.
Retro after retro (at least since I joined just over a year ago) would disintegrate into an all out kick-boxing match about how we really need to do something about this KFit thing. (Actually I exaggerate. It really is more like someone will anonymously post a ticket in the “Try” column saying something like “KFit. Watdo?” and when we get to that ticket there’ll be like a collective sigh and a mass shaking of heads, everyone internally contemplating how they’d like to kill it with fire. I might have exaggerated again).
But this week, something interesting happened at Fave. It was a culmination of all the frustrations and discussions we have had as Fave Engineers. All the tiny annoyances that have plagued development and progress — we finally said enough is enough.
<a_menacing_picture_of_eyad.jpg>
A couple of weeks ago, Eyad, our VP of Engineering, started putting in place a new initiative where we would address the many technical debts, hacks and temporary fixes that we’d accumulated over the years. The rest of Fave were informed that Engineering is taking on the motto of the Lannisters. We were going to start paying our debts. Features will still get built, no doubt, but a significant portion of our time will be dedicated to internal plumbing and fixing. Things that usually take a back seat because “ROI” and other fancy business acronyms. Not this time.
The plan was that we’d get everyone in Engineering to suggest ideas for what we envision Fave should be like, and we’d vote to pick and work on one. The first change we’ll make in our journey towards Fave 2.0
On Monday, we voted.
And we voted to Escape the Eagle.
p.s. A little bit of context about this Eagle that I talk about from our on-boarding document:
Slow clap.
p.p.s. This is meant to be the first in a series of articles documenting our Escape from the Eagle, and various other cleanups and fixes we might make in our journey towards Fave 2.0. This series (and other articles I might write) will be attempting to “Document. Don’t Create” because we ourselves are going through a journey. While we might be pretty good engineers, we don’t know what kind of lasagna you’re dealing with, so instead of saying “this is what you should do” we’re saying “this is what we’re trying”. If it works out (or doesn’t) we’ll let you know once we find out. So stay tuned!
