Historias
Slashboxes
Comentarios
 

Login Barrapunto

Login

[ Crear nueva cuenta ]

¿Como pagar la "deuda técnica"?

editada por Candyman el 31 de Enero 2011, 05:50h   Printer-friendly   Email story
desde el dept. tú-y-todos,-amigo

Merluzo nos cuenta: «En el trabajo me ha tocado encargarme de un proyecto inmantenible e inactualizable con los recursos disponibles, lo que me tiene un poco abrumado. Leyendo esta semana me he encontrado con la mejor metáfora para describirlo: la "deuda técnica", el conjunto de chapuzas y parches cuyos arreglos se van postponiendo. Como desarrollador, te endeudas cada vez que escribes código sin documentarlo, cada semana que dejas que tu fork local se aleje del desarrollo de upstream. La metáfora funciona porque cuanto más tiempo dejas sin arreglar uno de estos apaños, más tiempo te costará pagar la deuda. Es como si los problemas devengaran intereses. En ocasiones hay que reescribirlo todo, lo que en nuestra metáfora es el equivalente de declararse en bancarrota (y que puede llevar a la bancarrota real si no hay tiempo y dinero para asumir el desarrollo necesario). ¿Te has encontrado tú con problemas de endeudamiento técnico? ¿Cómo te arreglaste sin llegar a la ruina?»

Historias relacionadas

[+] La deuda técnica y la burbuja de los desarrollos privativos en las empresas 21 comentarios

pobrecito hablador nos cuenta: «Interesante comparación entre las prácticas del desarrollo de software a medida en las grandes empresas con la burbuja financiera citando el funcionamiento de las comunidades open source como ejemplo a seguir. Más de uno se sentirá identificado con lo que cuenta.» El artículo usa el concepto de "deuda técnica" del que ya hablábamos aquí en Barrapunto hace unos días.

[+] Empleo: Más empleos para programadores de Perl que de otros lenguajes 13 comentarios

Según analiza el blog nerds-central los datos de indeed.com, en Estados Unidos se ofrecen más trabajos donde se solicita Perl que cualquier otro lenguaje de programación. Incluso si se eliminan los trabajos de administración de sistemas, y se dejan sólo los de desarrollo de software, sólo PHP supera a Perl. Las razones que aduce parecen obvias: los lenguajes con mucha base instalada tienen más código en producción, y la gente extiende los sistemas existentes en el lenguaje en el que están escritos. Porque no tienen más remedio. ¿Conocéis proyectos nuevos que se estén desarrollando desde cero en Perl?

Este hilo ha sido archivado. No pueden publicarse nuevos comentarios.
Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • Magia de las cookies otra vez

    (Puntos:1, Divertido)
    por pobrecito hablador el Lunes, 31 Enero de 2011, 06:48h (#1263226)
    El que no hace una cosa por falta de tiempo es porque jamás tendrá tiempo para hacerla. -- E. Jardiel Poncela --

    Las cookies de barrapunto a veces ayudan mucho. Por mi parte, le diria que si intenta llevar el asunto antes los mandamases, posiblemente acabe en un dialogo para besugos, ellos lo quieren "para ayer" y no van a entrar en razones. Es mas, lo del futuro se puede convertir en negocio extra.

  • reescribe

    (Puntos:4, Interesante)
    por Molleradura (19661) el Lunes, 31 Enero de 2011, 06:54h (#1263228)
    ( http://barrapunto.com/ | Última bitácora: Martes, 27 Enero de 2009, 22:47h )
    Si, es normal.
    - Código en lenguajes obsoletos o que nadie controla.
    - Código demasiado dependiente de software, que hay que reescribir o modificar para seguir funcionando tras un cambio o actualización. (windows, librerías obsoletas, ... )
    - Código que podía ser más sencillo, pero es muy complejo porque no se tenía experiencia en ese apartado.
    - Código que tocaron tantos, descoordinadamente, que es un desastre...
    - Parches rápidos para salir del día, pero que luego nadie reescribe...
    - Decisiones rápidas que implican una modificación del análisis, y que implican fallos de lógica
    ...
    Ante todo esto, yo sólo se de dos soluciones:
    - Prevenir: si tienes buenos analistas muy experimentados, un buen análisis ayuda mucho.
    - Mantenimiento: "refactorizar" (reescribir) código frecuentemente, rompiendo la regla "si funciona no se toca". Si ahora sabes hacerlo mucho mejor, rehazlo.
  • por obreiro (37284) el Lunes, 31 Enero de 2011, 08:23h (#1263239)
    ( http://www.galizalivre.org/ )
    aprovechándose de un becario
    --
    nem guerra entre povos, nem paz entre classes!
  • Mis dos centimos...

    (Puntos:2, Informativo)
    por sammael (16347) el Lunes, 31 Enero de 2011, 09:30h (#1263248)
    ( http://barrapunto.com/ | Última bitácora: Viernes, 08 Abril de 2011, 12:00h )
    Lo primero, considero que la deuda tecnica es un concepto que todo jefe de proyecto, gestor de IT y demas deberian de conocer y muy pocos lo hacen o lo tienen en cuenta.

    El como pagar la deuda depende de si eres desarrollador o no.

    Si eres desarrollador, preocupate sobre todo de hacer tu parte, no esperes a que alguien te diga que algo no funciona, intenta de vez en cuando revisar trozos de codigo o librerias antiguas para ver si hay algo que se pueda arreglar. En general, olvidate del "si funciona, no lo toques" (me dan escalofrios cada vez que lo oigo), si algo funciona durante mucho tiempo cuando todo lo demas esta cambiando a su alrededor es generalmente porque no se usa o porque tienes a todo el mundo haciendo encaje de bolillos para sortear los errores y limitaciones de ese algo.

    Como no desarrollador, intenta mantenerte informado de como va el proyecto, no solo con lo que te digan los desarrolladores (tendemos a ser demasiado optimistas) sino tambien con herramientas automatizadas[1] y, sobre todo, escucha a los desarrolladores, si varios se empiezan a quejar de algo, generalmente merece la pena tenerlo en cuenta. El ignorarlos suele hacer que se callen, pero no porque el problema se haya solucionado, sino porque estaran haciendo las cosas por su cuenta ignorandote del todo. Algunas veces que me ha tocado ser jefe en proyectos con muchisima deuda incluso haciamos las estimaciones sobre semanas de 4 dias y usabamos el viernes para arreglar y refactorizar las areas que mas lo necesitaban. Como no desarrollador, tu control sobre la deuda tecnica es indirecto, pero de ti depende el poner las herramientas necesarias a disposicion de los desarrolladores para que ellos puedan hacer bien su trabajo.

    [1] Findbugs, PMD, Checkstyle... las hay a patadas. En mi caso, desarrollando casi siempre en java, encontre una que se llama sonar [sonarsource.org], se integra con ant y maven y da una cantidad de informacion impresionante en una sola pagina (incluso una cierta medida de la deuda tecnica).
    --


    Dale fuego a un hombre y estara caliente un dia, prendele fuego y estara caliente el resto de su vida.
  • Este me pegó

    (Puntos:2)
    por snookiex (35574) el Lunes, 31 Enero de 2011, 13:47h (#1263300)
    ( http://www.kuwaiba.org/ | Última bitácora: Martes, 19 Abril de 2011, 14:25h )
    Directamente. Vivo endeudado y reconozco que es una muy mala práctica. Cada dos meses intento desatrasarme y y no alcanza el tiempo. Supongo que tendré que cambiar de estrategia.
    --
    ¡Inventario de red para las masas! Kuwaiba Open Network Inventory [sourceforge.net]
  • Consejillos surtidos

    (Puntos:4, Inspirado)
    por Pirx (15304) el Lunes, 31 Enero de 2011, 15:08h (#1263314)
    ( http://barrapunto.com/ | Última bitácora: Miércoles, 06 Julio de 2011, 10:26h )
    Tomado de algún sitio por ahí... pondré de quién es si consigo encontrar la fuente.
    • Lo primero es intentar, con toda la diplomacia posible, que los jefes sean conscientes de la situación y de cómo afecta económicamente al trabajo que haces. No es necesario que se comprometan a arreglarlo, pero sí que admitan el problema y estén dispuestos a dar pequeños pasos para su arreglo.
    • NUNCA propongas reescribir. Si un programa está falto de documentación, el código ES la documentación. Si reescribes, la pierdes. Busca el artículo clásico de Spolsky sobre Netscape, para más argumentos. Primero hay que intentar mejorar el código, al menos hasta el punto de hacerlo tratable. Después puedes plantearte su sustitución.
    • Cubre todo el código con bloques de control de excepciones (uno por cada acción de usuario) que detengan todos los fallos, escriban toda la información posible en un log, den al usuario un mensaje con sentido sobre qué ocurrió, libere los recursos comprometidos y vuelva a un punto conocido de la ejecución.
    • Asegúrate de que existe un proceso de instalación del entorno de desarrollo, cómo bajar los fuentes, compilar y desplegar, reproducible desde cero. Es bueno que se pueda hacer mediante scripts... las dependencias ocultas de los IDEs son veneno.
    • Crea un instalador para el programa (ayuda a detectar requisitos de instalación).
    • Crea en el inicio del programa un proceso lineal, claro y robusto que compruebe las dependencias, arranque el programa y compruebe que se puede acceder a los recursos necesarios (bases de datos, ficheros, conexiones de red).
    • Escribe una documentación básica (ficheros de texto empezando por el clásico README.txt, mejor no uses plantillas) donde vayas metiendo todos los problemas técnicos (y cómo los resuelves) que vayan apareciendo. Menos es más, pero que esté actualizado.
    • Mete el código en control de versiones y define un proceso para seguimiento de fallos (no digo "bugzilla" porque me da cosa).
    • Concentra todo el código de acceso a base de datos en un módulo (o en una serie de ellos si el programa es grande) al que se acceda mediante una interfaz mínima. Lo de dejar regado el SQL por el código... como que no.
    • Lee algo sobre "refactorización". La idea es ir pagando la deuda técnica en cómodos plazos: cada vez que tengas que tocar en un módulo, intenta hacer algunas pequeñas mejoras en él. Los jefes no suelen oponerse y, si haces eso durante el tiempo suficiente, la situación puede mejorar muchísimo.
    • Huye de los jefes que dicen que si no se cobra no se hace, como de la mierda (que son). La consultora para la que trabajas puede ganar más dinero trabajando peor, pero va contra un comportamiento mínimamente ético y te están puteando a ti, mucho más que al cliente. Trabajar removiendo mierda va contra la dignidad del trabajador.
  • por Carnil (11361) <Carnil en jabber.org> el Lunes, 31 Enero de 2011, 19:57h (#1263345)
    ( Última bitácora: Martes, 18 Mayo de 2004, 09:30h )

    En mi caso la deuda técnica ha sido el principal problema con el que me he encontrado en mis últimos 5 años de trabajo, en dos proyectos distintos. Principalmente debido a un código que había pasado por muchas manos y se habían realizado muchos parches para arreglar fallos rápidamente.

    La experiencia me ha enseñado que por desgracia nunca hay tiempo en un entorno empresarial para dedicarse solo a pagar esta deuda, así que lo único que se puede hacer es pagarla poco a poco. Mi consejo es aprovechar cada cambio que se tenga que hacer para arreglar un fallo o para aumentar funcionalidad para pagar un poco de esta deuda.

    La forma de hacerlo es empezar dividiendo las funciones y clases grandes en unidades más pequeñas ( intentando usar buen criterio para que las funciones tengan sentido conceptualmente ) alterando lo mínimo posible la funcionalidad ( hay que acabar con esas funciones de 2000 lineas, y no es una exageración, me las he encontrado ).

    Una vez tenemos unidades más pequeñas, hay que crear unit tests ( http://es.wikipedia.org/wiki/Prueba_unitaria [wikipedia.org]) automatizados para ellas. Esto es clave por varios motivos:
    • Al hacer unit tests de funciones y clases nos daremos cuenta de donde están las mayores dependencias innecesarias y que clases tienen demasiadas responsabilidades, rompiendo el principio de única responsabilidad(http://en.wikipedia.org/wiki/Singl e_responsibility_principle [wikipedia.org]).
    • Estaremos realizando test de nuestras funciones, mejorando la calidad.
    • Y lo más importante, tendremos una cobertura que nos permitirá refactorizar estas unidades asegurando que no rompemos nada y que siguen funcionando igual.
    La refactorización constante y las pruebas automatizadas son técnicas básicas de las metodologías ágiles, y son muy útiles al aplicarlas sobre código heredado, te recomiendo leer más sobre ellas.
  • No hay solución mágica

    (Puntos:3, Informativo)
    por faragon (17575) el Lunes, 31 Enero de 2011, 21:49h (#1263353)
    ( http://www.voluntariado.net/ | Última bitácora: Domingo, 17 Julio de 2011, 20:01h )

    ¿Cómo te arreglaste sin llegar a la ruina?
    Partiendo de la base que lo que tenéis en uso/producción es "más o menos usable/vendible", y que lo queréis hacer sobre la marcha:

    Paso 1, localización y segmentación de problemas:

    A) Dividir entre lo que afecta (A.1) y lo que no afecta (A.2) a la experiencia del usuario.
    B) Diferenciar lo que no funciona o funciona pero no es escalable (B.1; crashes y problemas que ocasionan "consumo" del staff de soporte técnico, querys de 5 minutos, etc.), y lo que es horrible a nivel de código "pero funciona bien como caja negra y no hace crash nunca" (B.2).
    C) Diferenciar lo que funciona pero supone gastos fijos (C.1; e.g. cosas sin automatizar que requieren procesos manuales como pueda ser el despligue de contenido a N nodos remotos, el no usar gestores de versiones adecuados, no tener backups, etc.), de lo que no tiene coste dejándolo como está (C.2).

    Tras el primer paso, el problema se reduce a modificar: A.1, B.1, C.1 (si lo queréis es vender un buen producto, reduciendo los fallos y el tiempo dedicado a mantenimiento).

    Paso 2: priorización

    Pasada de priorización #1 (sobre A.1,B.1,C.1): Elimina todo lo que veas en A.1, B.1, C.1 que puedas dejar de hacer, por no ser vital para el negocio, de A.1, ya sea simplificando procesos o haciéndolo de otra manera (e.g. cambiar Intranet hecha "a mano" por un CMS, sin tunear a medida, algo austero pero que cumpla lo mínimo que necesitáis). Tras la limpieza, quedaría: A.1', B.1', C.1'

    Pasada de priorización #2 (sobre A.1, B.1): Juntad el 80% de los casos más graves de A.1' y B.1', que se puedan resolver en el 30% del tiempo sin generar dependencias en los casos restantes (tuneado de la "Regla de Pareto" pero con un 80-30 en lugar del 80-20). Etiquetad esos casos como "AB.1-rápido", el resto, dividirlos entre "AB.1-fácil-pero-lento" y "AB.1-muy-difícil"

    Pasada de priorización #3 (sobre C.1): Determinar los gastos fijos que suponen, separándo en dos grupos: C.1-pinchazo (hasta el 5% de los costes fijos de la empresa, i.e. la empresa podría ir boyante, pero las chapuzas se comen los beneficios) y C.1-sangría (riesgo de cerrar la empresa).

    Paso 3, ejecución:

    Pre-ejecución: No asignar a nadie una tarea para la que no esté capacitado (la buena voluntad no siempre es suficiente), la pueda hacer en un tiempo razonable, y el resultado sea de calidad. Si esas restricciones no son posibles, volved al paso 1, y simplificar más todavía las tareas hasta que las podáis acometer (si es imposible, y depende del cierre de la empresa, pagad a uno o varios figuras un pastón -p.e. pasta por delante y además, si en 3 años le va bien a la empresa, te llevas un X como bonus-).

    Ataque #1: "C.1-sangría"
    Ataque #2: "AB.1-rápido"
    Ataque #3: "AB.1-fácil-pero-lento"
    Ataque #4: Volver al Paso 1, con sólo "AB.1-muy-difícil" y "C.1-pinchazo"

    Notas adicionales:

    - No desatender a los usuarios actuales: es un tren en marcha.
    - Caña [youtube.com], y distorsión [youtube.com]
  • 3 respuestas por debajo de tu umbral de lectura actual.