Consejos para priorizar la deuda tecnológica de una manera saludable

Tabla de contenido

La deuda técnica (también conocida como 'deuda tecnológica') se convirtió en un término popular en los últimos años. Nuestras bases de código y sistemas tienden a acumularse con el tiempo, lo que hace que sea más difícil realizar cambios en ellos o desarrollarlos más adelante.

La deuda tecnológica es una metáfora de Ward Cunningham, coautor del Manifiesto Ágil y creador del primer software wiki. Las metáforas, como modelos, ayudan a dar forma a nuestro pensamiento sobre un tema en particular. Entonces, ¿por qué la llamamos 'deuda técnica' y no simplemente 'cruft'? La razón es que, en ciertos aspectos, es análoga a la deuda financiera: si no la devolvemos, pasa factura a las nuevas funciones e incluso al mantenimiento, al igual que se acumulan los intereses de la deuda financiera.

Una fuente de esto son nuestras compensaciones conscientes e inconscientes al diseñar y construir nuestros sistemas, la falta de código limpio, documentación y mejores prácticas. Otra fuente es que los sistemas y su ecosistema evolucionan, y lo que era una solución perfecta hace dos años ya no es tan brillante.

Me centraré en las técnicas para "vender la idea" y priorizaré el pago de la deuda tecnológica en el desarrollo de productos con múltiples partes interesadas en la mesa.

El mito de los dos atrasos

Comencemos con lo que no se debe hacer. Muchos equipos terminan con dos tipos de trabajos pendientes: uno centrado en el producto y otro centrado en la tecnología. No funcionará por varias razones:

Será casi imposible establecer prioridades cruzadas entre elementos en trabajos pendientes separados entre sí.
Alimenta la mentalidad de "nosotros contra ellos", lo que acaba con la cohesión del equipo y los objetivos comunes.
La priorización es trabajo de todo el equipo; dejar de lado a los representantes de productos no funcionará.
Hace que la planificación de sprints sea más difícil a menos que tenga reglas estrictas sobre cómo asignar la capacidad (por ejemplo, el 20% se destina a la deuda tecnológica de manera constante)

Reconoce que cualquier tipo de trabajo es… bueno, trabajo. Mantenga un backlog y agregue cualquier tipo de trabajo allí . Siéntase libre de etiquetar la deuda tecnológica si desea estadísticas o vistas filtradas, pero asegúrese de priorizar todo el trabajo pendiente.

No haga de la deuda tecnológica un juego de culpas.

Otro error habitual es hacer que los argumentos sobre la deuda tecnológica estén llenos de acusaciones. He visto a algunos gerentes (tanto de ingeniería como de producto) decir frases como "bueno, si crearas una mejor solución en primer lugar, no estaríamos en esta situación". Esto es simplemente estúpido, inhumano y, en última instancia, sin sentido. . Nada nunca será perfecto. Somos humanos, el contexto cambia, las cosas evolucionan. Solo acéptalo. Lo mejor que podemos hacer es aprender de nuestros errores de diseño, inculcar buenas prácticas y ser lo más conscientes que podamos sobre las compensaciones que estamos haciendo.

Playing the blame game takes our focus away from solving the issue at hand. It makes most folks defensive, which again shifts the discussion into an unnecessary back-and-forth without getting any closer to solutions.

Blameless retrospectives and post mortems are the way to go. The fix is almost always systemic and not personal.

How to discuss tech debt

Now that we know what to avoid let’s see some ways to argue about the importance of paying back technical debt. It usually comes down to the risk around existing tech debt, the toil (of maintenance) caused by it, and how it hinders the development of new features.

In my experience, most engineers don’t need to be convinced to work on technical debt. In fact, they are the ones requesting that. On the other hand, engineering and product managers often need more context to understand the importance of paying back tech debt.

Your best strategy here is to understand how to give that context in the language your stakeholders speak. “Well, it’s trivial why this is important” won’t work. There are 50 other items in your backlog which is “trivially important” to them. Also, please don’t make it about yourself. It’s great that you’re passionate about fixing this, but if it sounds like your pet project without any further argument, it likely won’t get prioritized. I’ll show you a few ways to frame your views. Spoiler: it’s all about connecting the dots from your tech debt items to your internal or external customers and the product’s performance.

Risk

A certain percentage of technical debt work has a risk profile attached

A certain percentage of technical debt work has a risk profile attached. One trivial example is when your solution uses a 3^rd party (library/service) that is getting to its end of life. The risk here is that if you don’t upgrade or migrate away to another supported solution, the systems depending on the 3^rd party would either be dysfunctional or would, for example, stop receiving security patches in the future, risking a potential breach, which is obviously bad for your users or customers. Not each situation is equal, of course – it does matter whether we’d be going offline next week or there is a low chance of a low-impact security issue hitting you in 2 years. Check the ‘Cost of Delay’ section below.

Another type of risk is also around customer retention, but it’s less direct. The subpar experience caused by not great solutions (think about frequent outages and slow services) creates the risk of customer churn.

Some examples of phrasing technical debt around risk:

We might fix a bug in 2 places but miss the 3^rd due to code duplication.
The design of the current system could lead to a slow user experience at higher usage scenarios.
Lacking security practices could result in breaches and legal liabilities.
Accidental introduction of new bugs into the feature is probable due to our lack of unit tests.
The complexity and inflexibility of the codebase result in us saying no to new features due to long development times.

Para que su argumento sea más sólido y honesto, siempre que pueda, recopile datos y hágalos parte del argumento. Esto no siempre es posible, por supuesto. Recuerde, los datos también pueden ser las mejores prácticas de la industria, por ejemplo, largos tiempos de ejecución de pruebas frente a lo que es aceptable.