El día de ayer leí un muy interesante post en TechCrunch titulado: "La deuda técnica te matará (si tu se lo permites)", aunque el concepto de deuda técnica no es nuevo, sin embargo no está muy difundido y muchas grandes empresas como RIM, Nokia o Microsoft han dado clara muestra que un elevado nivel de deuda técnica pueden llevar a perder la posición de liderazgo que se tiene. ¿Qué es deuda técnica?, la definición no es sencilla, pero podemos enterderla como todos los compromisos de diseño, programación o implementación de un proyecto de software, que se hicieron para alcanzar una ventaja táctica o estratégica en el mercado, pero que luego muestran sus limitaciones y requiren la inversión de más dinero para resolver los problemas. Me he permitido traducir algunas parter del artículo que me parecieron importantes:

Un proyecto en el que he estado trabajando recientemente para su lanzamiento. Bueno, en realidad relanzamiento. Es una pequeña y elegante aplicación de iPhone que se llama Postography, que le permite al usuario enviar postales con mensajes e imágenes desde tu iPhone. Genial, pero suena bastante sencillo, ¿verdad? Una aplicación que no debería haber tomado demasiado tiempo en ser construida.

Por desgracia, no la estamos construyendo, la estamos reconstruyendo. Y la empresa que puso la primera grieta en ella (sin nombrar nombres aquí) hizo un trabajo bastante bueno en el lado del servidor … pero tuvo una épica falla en la versión inicial de la app en sí misma. Oh, y es que en última instancia se le hizo funcionar, con sus muchos errores y caídas frecuentes. Pero muy aparte de eso, su código base fue un enconado abismo de variables globales, código de espaguetis, hacks, no-ops y las condiciones de operación eran tales que ampliarlo o modificarlo era casi imposible sin una cirugía reconstructiva.

Esto sucede mucho más de lo que nadie quiere admitir. Detrás de las brillantes aplicaciones de interfaz de usuario se esconden muchas arquitecturas dignas de una pesadilla Lovecraftiana, que cuestionan la cordura de toda persona oblugada a darle mantenimiento o agregarle nuevas características. Preguntele a un desarrollador, a cualquier desarrollador, ellos tendrán historias terroríficas que contarle.

Muchos de nosotros que hemos trabajado en proyectos reales de software nos hemos dado cuenta de que este es un problema muy común diría yo, ya que muchas veces las decisiones de diseño suelen estar en manos del departamento de marketing o del dueño de la empresa, que en la mayoría de los casos suele tener muy poca experiencia en desarrollo/implementación de software.

Empresas como RIM que han sufrido varios años (desde el 2008) para tratar de ofrecer una respuesta aceptable a la nueva generación de smartphones de pantallas táctiles como el iPhone o Android, son una muestra de deuda técnica. Pero no es el único caso, por ejemplo Microsoft, ha luchado durante años (más de 15 años ya) en tratar de portar su OS estrella Windows fuera de la arquitectura Intel x86, sin mucho éxito aún, falta ver que tan bien le va a su Windows RT.

Básicamente la idea de la deuda técnica, al igual que la de deudas monetarias, quiere decir que tomamos dinero del futuro para poder crecer más rápidamente en el presente. Obviamente, una inyección de liquidez hace crecer cualquier negocio, pero hay que recordar aquel viejo refran que dice: "No hay deuda que no se pague, ni plazo que no se cumpla". Tarde o temprano, todos los atajos tomados en el desarollo, programación o implementación del proyecto terminarán pasando factura. Muchas veces ese precio es tan alto que puede quebrar a la empresa.

Aquí otro interesante párrafo del mismo artículo:

Al igual que la deuda monetaria, la deuda técnica es perfectamente aceptable, siempre y cuando: a) no se acumule demasiado de ella, y b) usted sabe todo al respecto. Por supuesto que a menudo se deben hacer compromisos entre, por ejemplo, la escalabilidad y la velocidad de desarrollo. Por supuesto, cuando la fecha límite se acerca, o el financiamiento se está agotando, y la tarea parece inmensa, el atajo rápido de aplicar un hack es a veces la mejor opción. Por supuesto que todos los desarrolladores están comprensiblemente sesgados ya sea hacia la herramienta que conocen o, a veces, la herramienta que quieren aprender, más que la herramienta ideal para el trabajo a realizar.

 

La última sentencia es una clara alución a la frase: "Para aquel cuya única herramienta es un martillo, todo problema luce como un clavo". Y ocurre que muchas veces por ahorrar los empresarios contratan personas con limitado dominio del área en que deben desarrollar y que aunque pueden generar resultados, estos suelen tener muchas limitaciones que impiden escalar la solución o incluso añadir funciones adicionales.

¿Qué debemos hacer si nos encontramos ante una situación como esta?, algo que nos enseña la historia es que las mejoras graduales no funcionan, recordemos que desde Windows 3.0 hasta Windows Me, los sistemas de escritorio fueron bastante propensos a pantallas azules y contenían una casi ilimitada cantidad de vulnerabilidades a ser explotadas. Windows XP, trajo cierta estabilidad aunque al costo de romper el 100% de la compatibilidad con aplicaciones DOS. Lo mismo ocurrió con Apple y el OS/X, la compatibilidad con el sistema anterior OS/9 se rompió en favor de presentar nuevas y muy necesarias características.

Pero esas soluciones que pueden funcionar en software que tiene ya un mercado cautivo, puede que no sean valederas para empresas que recien inician operaciones y tienen una base de usuarios casi nula, como es el caso de muchas startup. Así que para los que recien comienzan es buena idea, que antes de comenzar a escribir código para estar en el market mañana, reflexionen un poco en que tan claro y modular es el código que están escribiendo, además de que consideren que tan amarrados están a su sistema de base de datos, ya que al final el cuello de botella al momento de escalar una aplicación es casi siempre la base de datos.

Espero que este post les haya sido de ayuda a aquellos que están pensando iniciar su aventura de empresarios TIC.