Toma título lapidario, de la pluma del más funesto William Shakespeare nada menos. Que no se disparen todavía las alarmas, no va a tratar el post sobre la muerte de nadie, faltaría más. Pero sí sobre un factor que puede acelerar el fracaso de un proyecto tecnológico. Un fenómeno que toda acometida técnica de cierto calado va a enfrentar tarde o temprano. La crisis económica de los geeks de a pelo, su fin de ciclo particular. En fin, hablamos de la deuda técnica. Para los no puestos en el tema, la palabra “deuda” ha de ser indicativa de que no es éste un asunto baladí. Vaya si no lo es…
¡Palabras, palabras, todo palabras!
Te has embarcado en un nuevo proyecto de desarrollo. Una startup, o un nuevo producto/servicio en tu actual empresa, ambos sirven. Aquí todos somos buenos profesionales, ingenieros de carrera, así que el asunto se empieza por los cimientos: con la fase de diseño. Junto a la gente de producto se han definido unas características para el nuevo retoño, y ahora toca esbozar el esqueleto sobre el que se dará forma final al, hasta ahora, efímero concepto. Arquitectura, diagramas, componentes, escalabilidad, patrones, protocolos y demás frikadas. En fin, el business plan de los desarrolladores, para entendernos.
De hecho, la comparación entre el diseño de una aplicación y un business plan tiene mucho de acertada. Ambos son concisas hojas de ruta, ambos son ejercicios entrañables de wishful thinking, y ambos suelen reventar en 1000 pedazos al primer choque con la realidad. Esto es así. Mucha ingeniería, mucho UML y mucha zarandaja, pero el diseño original de un software tiende a quedarse obsoleto bien rápido. Y lo peor, a limitar la evolución del mismo. A la que empiecen a aflorar nuevas características y necesidades desconocidas durante la fase de diseño, éste se quedará bien corto, y tocará empezar a salirse de la pulcra línea de trabajo que nos habíamos marcado.
En ese ejercicio de creatividad forzosa será inevitable introducir en el software una serie de elementos no contemplados en el diseño inicial, poco acordes con su pulcro espíritu original: las chapuzas. Los tiempos apremian, el mercado no perdona y uno va cediendo al “bueno, como hay prisa lo hago así, que NO es la manera y está MAL, pero en cuanto tenga un rato lo arreglo…”. Y ya está, acabamos de contraer una pequeña (o no tan pequeña) deuda técnica. Cada vez que cedemos en calidad del software para cumplir con otras prioridades, sumamos deuda técnica. Cada vez que tomamos el atajo porque el camino correcto conlleva demasiado esfuerzo, cavamos un poquito más profunda nuestra propia tumba.
Cuando llega la desgracia, nunca viene sola, sino a batallones.
Entonces, ¿dónde radica realmente el problema? Al fin y al cabo, que las cosas no se hagan de la mejor manera posible en cada ocasión es algo previsible y realista. Una característica que no pase del “bien” y que esté lista en una semana puede ser más interesante que su versión “excelente” y que nos lleve más de un mes. Al menos desde un punto de vista de estrategia y negocio, claro. ¿Que no es perfecto? Mientras sea usable, me vale. Pero el problema es más profundo, y no se limita a esa característica coja en concreto. El problema real nace de la naturaleza iterativa del desarrollo de software. El problema es el del castillo de naipes.
Si alguna vez te has entretenido construyendo un castillo de naipes, te habrás dado cuenta bien rápido de su característica estructural básica. Y es que la probabilidad de éxito al construir un nuevo nivel depende más de lo sólidos que sean los niveles inferiores que de tu habilidad. Haz un mal primer piso deprisa y corriendo, poco asentado, y quizás llegues a levantar un segundo piso, pero del tercero seguro que no pasas. Se acumulan y suman las deficiencias con cada nuevo nivel, haciendo más difícil la edificación de uno posterior. Limitamos nuestra capacidad de acción con cada sacrificio estructural. Y el resultado, de un impacto visual innegable, es el derrumbamiento inevitable del castillo.
Pues con el software, igual. Con cada sacrificio que se hace, se suman deficiencias estructurales que van a ralentizar, limitar, o incluso impedir el añadido de nuevas funcionalidades. Cuando el mercado exija esas características, nos encontraremos ante una disyuntiva. O dedicar mucho más tiempo del aconsejable en adaptar el producto para permitirla, o asumir que no es posible implementarla en el estado actual del software. En cualquier caso, un freno a la sana evolución del proyecto. Y, de tirar por la calle del medio e implementarla mal, pervirtiendo aún más el diseño, limitaremos todavía más nuestra capacidad de acción posterior. Si no se paga la deuda técnica, llega un momento en que te acaban embargando.
Ser o no ser. Esa es la pregunta.
¿Nos centramos entonces en reciclar nuestro diseño a cada paso, en dedicar cuanto tiempo sea necesario a asegurar la buena forma del software? ¿Frenar, amoldar el ritmo de crecimiento del proyecto a nuestra capacidad para mantener la base de código siempre impoluta? Eso puede tener sentido en proyectos sin presión de mercado, donde la ventana de oportunidad no es un limitante. Software libre o side-projects, por ejemplo, se pueden centrar en la corrección antes que en el time-to-market. ¿En una startup? No lo creo. Para cuando re-escribas tu aplicación por tercera vez, mejor que nunca, tus competidores se habrán convertido en el único actor de tu mercado. Game over.
Hay algo que los perfiles técnicos tenemos dificultad para asumir cuando fundamos negocios. Y es que un negocio no vive de la pureza teórica de tu diseño, ni de la pulcritud y claridad de tu implementación. Un negocio vive de hacer negocio. Ni más, ni menos. La prioridad es siempre vender, conseguir usuarios, clientes, que tu servicio se use. Que sea rentable para poder seguir. El mejor software del mundo matará a tu empresa igual que el peor si no tiene salida comercial. Sin más. Y entonces… si no combatir la deuda técnica puede matarme, pero centrarme en combatirla puede matarme…. ¿qué me queda? Pues queda pactar.
No sé vosotros, pero yo he vivido en la mayoría de empresas donde he trabajado una clara dicotomía negocio/desarrollo. El lado negocio quiere que el tiempo de desarrollo se centre en funcionalidades (son vendibles), y el lado desarrollo quiere centrar buena parte de ese tiempo en herramientas, mejoras, re-escrituras, y demás (mejoran la calidad). En la negociación de los ciclos de desarrollo, en mi experiencia, suele salirse con la suya negocio. Y es que, como comentaba antes, el fin último de una empresa es hacer negocio, y eso ha de primar. Lo que no he visto tan a menudo es que la mejora de la calidad acabe teniendo cabida en esos ciclos, con la consecuente contracción de deuda técnica.
Mi propuesta es sencilla. El producto manda, y los ciclos han de protagonizarlos, por lo general, las nuevas características vendibles. Pero la deuda técnica es un veneno para el producto, y el lado negocio ha de asumirlo sí o sí. Todo ciclo de desarrollo ha de incluir un pequeño porcentaje de tiempo (¿15%? ¿más? ¿menos? eso ya depende del ciclo y las necesidades puntuales en ese momento) dedicado a subsanar limitaciones técnicas. Las tareas puramente arquitecturales que se lleven a cabo han de definirse previamente, como con cualquier otra tarea del ciclo. Y ha de comunicarse a negocio cual es el riesgo que entraña no llevarlas a cabo: limitaciones futuras, horas malgastadas a causa de falta de herramientas, etc… En fin, dejar claro que esas horas no son una suerte de “recreo” de los técnicos, son tan esenciales en la vida del producto como el añadir nuevas características.
En una startup, donde los conceptos de negocio y desarrollo no están ni tan marcados ni tan enfrentados, es más fácil, claro. Suele haber más equilibrio de poderes, mejor entendimiento y más implicación de todas las partes en todas las facetas del producto. En nuestro caso, por ejemplo, Diego tiene suficiente base técnica para entender perfectamente cuán importante es gestionar esa deuda, y por qué. El riesgo en una startup viene un poco por el lado contrario en ocasiones. Preponderancia de fundadores técnicos que se pierden en un sinfín de re-escrituras y consideraciones estético-filosóficas sobre el código. Es igual de peligroso, si no más, ya que sufres el riesgo de morir antes de haber lanzado nada útil al mercado…
Antes que nada ser verídico para contigo mismo.
Y para muestra, un botón. Toda la teoría es muy bonita, pero suele encajar mejor si se acompaña de un ejemplo. Y por dar uno de primera mano, y porque en Ducksboard no nos avergonzamos de comentar nuestros errores, voy a ilustrar todo lo anterior con un episodio de deuda técnica doméstico. Para situaros, el frontend web de Ducksboard se desarrolló deprisa y corriendo, tras el backend de obtención de datos, para tener una beta lo antes posible. El hacer las cosas deprisa y corriendo tiene sus consecuencias, y en otro post ya detallé el esfuerzo extra que nos supuso arreglar la primera, y muy deficiente, versión. Pero quiero detenerme en un aspecto concreto del frontend que todavía hoy nos da problemas por un diseño inflexible: los widgets.
Un widget es cada uno de esos cuadraditos que muestran datos en el dashboard. El diseño original satisfacía las necesidades primigenias, claro. Esto es poder mostrar varias fuentes de datos prefijadas, cambiar título y colores y poco más. Al principio eran pocos widgets, y aunque cada uno implica ciertas nuevas filas en base de datos, algo de Javascript y un poco de CSS, no era un trabajo excesivo. Pasan los meses, y se van a añadiendo características. Los widgets tienen varios tamaños, las fuentes de datos ya no son prefijadas, la cantidad de visualizaciones se multiplica… Y surgen dos problemas. Por un lado, la cantidad de trabajo para crear un widget aumenta, porque son muchas más variables. Por otro, el diseño original de widget no soporta las nuevas características, así que se workaroundea duplicando tipos de widgets prefijados al no disponer de flexibilidad en el modelo existente.
Resultado, tardamos en crear un widget bastante más tiempo del que solíamos, y mucho más del que debiéramos. Desde un punto de vista de producto no es tan malo: el usuario no percibe la diferencia, funciona igual. Pero desde un punto de vista de desarrollo de producto tenemos un problema: perdemos muchas, muchas horas en hacer widgets (tenemos cientos, y no dejan de hacerse nuevos) que podrían dedicarse a añadir y mejorar otras características. Un caso clásico de deuda técnica. No hay nada “roto” que impida comercializar el producto, pero una limitación de diseño nos está robando horas de manera poco tangible pero constante, y compromete el crecimiento posterior.
Lo he comentado antes, estoy muy a favor de priorizar las tareas con influencia directa en la comercialización del producto. Con una larga lista de nuevas características y productos y una planificación exigente, no era el momento de acometer cambios estructurales. Pero una vez capeado el chaparrón, y tras justificar la tarea con la gente de negocio, ya toca poner solución a un lastre que nos está robando tiempo y energías. El resultado será más tiempo que dedicar a lo realmente importante, menos fricción en el desarrollo (vamos, quemar menos a los técnicos) y más calidad final del producto. Un win-win en toda regla. Frenar un poco para correr más rápido después.
Morir, dormir… ¿dormir? Tal vez soñar.
En un mundo ideal sería posible anticipar todas las funcionalidades que un software vaya a integrar a lo largo de su ciclo vital. Quién sabe. En el mundo real, eso es prácticamente imposible, una quimera. El software es cambiante, se adapta a nuevas necesidades y cambia de foco. No hay diseño que soporte eso. Manteniendo eso en mente, hay que buscar un equilibrio entre dejar que tu proyecto se degrade tanto que se hunda bajo su propio peso, y aspirar a una perfección inasequible y estéril. La deuda técnica carcome el software a medida que crece, pero obsesionarse con ella puede crujirlo antes de empezar. Las cosas en su justa medida. La planificación es la clave.
Si te ha gustado, sígueme en @aitorciki dónde además hago chistes de PHP ;P
