#technical-debt

La metáfora de la deuda técnica

  El equipo acaba la primera parte de sprint planning desgranando os PBIs en tareas, estimándolas y cada miembro del equipo empieza a trabajar en un ítem distinto. Esto lleva a problemas de integración y silos de implementaciones en los cuales no tenemos ni de lo que está sucediendo. Las tareas quedan a mitad de desarrollo al final del sprint y no da tiempo a integrar (ofreciendo algo de…

by John

A lot has been written about paying down technical debt. We all know that we are better off making the effort to regularly pay it down then to let it grow until it becomes unmanageable and you are forced to stop pushing features. Unfortunately, software is built by humans, a species not known for acting responsibly with regards to debt.

Last week, we decided to not act like humans and spend a few days paying down the interest on our technical debt. Specifically, we focused on a subset of technical debt: removing unused code.

I'll start with some numbers. After the code cull, reckoning, whatever you want to call it, we were left with:

~180k fewer lines of code

63 fewer models

50 fewer PostgreSQL tables

3 fewer gems

1 less (enormous) MongoDB collection

Numbers are fun, but I'd also like to explain our reasoning behind the cull and why now seemed like a good time to do it.

Every pivot leaves a scar

Here at Versa, we've experimented with a variety of different products to help people have access to the information they need to be engaged, effective citizens. We've pivoted... a few times. During last week's cull, we successfully removed 3 products from our codebase that we no longer support. Whew.

Onboarding

We are growing our engineering team and one of the more awkward moments of on-boarding someone is saying "oh, see those 63 models (or controllers, views, stylesheets, etc.)? Don't worry about them. We don't use them anymore."

This is akin to saying "use a percentage of your cognative resources to remember to forget about these 180k lines of code." I know it sounds ridiculous to say that, but it's essentially what we are doing whenever we tell someone to ignore chunks of old code.

Reliable Testing

Around the end of the last Mayan baktun we started taking testing seriously. Sure, we'd had tests around some of the more important processes in the system, but it was in December 2012 when made tests first order citizens in our codebase (side note: here's an awesome AirBnB blog about getting their team to this place).

The problem with this, though was that our test suite took forever to run - in part because we lots of tests around complex logic in code we no longer used. The solution at the time was simply rspec spec/ --tag new_baktun and we added the new_baktun tag to all new tests.

Tagging like this works fine until you want to get an idea of your test coverage. Again, we're to a place where we've got to use precious mental resources to remember which code we actually use and which we don't.

Post-cull, we can just run rspec spec/. All our tests run and our test coverage is accurate (even if it's not 100%).

Catharsis / Reflection

Deleting old code is a lot like burning a pile of love letters to an ex. You poured your heart and soul into them - you really meant it at the time, but now you are a different person they represent the old you (2 or 3 products ago). Time for a new dress. Say an incantation and torch the lot of 'em. Cleanse.

Decoupling and removing old products also brought to our attention a few bits and pieces we didn't even know existed. This included a lightweight billing system and a sweet helper for adding/removing foreign keys in Rails migrations. That last helper also showed me an awesome gem from my predecessor that we will start using again.

Unlike the love letter analogy, we can always go back and see our old code on GitHub - because who puts love letters on GitHub? (Oh, wait, this Korean dude did)

What's next?

After all this work we aren't technical debt-free, but now that we've paid down all the interest in the "unused code" category we get back into build mode.

As fun as it is to have more deletions than additions on our main app, it's time to get back to iterating on our JS app to serve smoothly over 1.5M times a day, to refine and expand our predictive models (which analyze thousands of news articles a day) and to add features to our internal & client-facing services to keep our clients & publishing partners excited to work with us.

Yo mismo, acumulando deuda técnica :-(