Historias
Slashboxes
Comentarios
 

Login Barrapunto

Login

[ Crear nueva cuenta ]

¿Qué es la deuda técnica?

editada por rvr el 18 de Junio 2010, 10:00h   Printer-friendly   Email story
En Código Comestible Alberto Fernández-Capel cuenta Qué es la deuda tecnológica: «¿Os habéis encontrado alguna vez con código mal escrito que es difícil de mantener y más difícil de reutilizar? Apuesto a que sí. [...] Para explicar las consecuencias del código hecho con prisas Ward Cunningham acuñó el término deuda técnica. Hacer código de mala calidad a toda prisa, es como pedir un crédito: puede que obtengamos un beneficio a corto plazo pero si tenemos que seguir desarrollando ese código, tarde o temprano tendremos que pagar todo el tiempo que nos habíamos ahorrado y los intereses. Refactorizar código mal escrito es siempre más difícil que escribirlo bien desde el principio».

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

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.
  • No solo a medio plazo.

    (Puntos:3, Inspirado)
    Desde sistemas demasiado a menudo has de sobredimensionar infraestructura para aguantar malos diseños/implementaciones de software (eso repercute en precios de CPD, consumo de energía, hardware, contratos de mantenimiento, etc).
    Aparte de las horas que hay que pagar al equipo por horas extras causadas por cagadas en el código y la pérdida de clientes por el "aburrimiento" estar viendo siempre fallos en el software.
    --
    Pué fueno, pué fale, pué m'alegro.
    Maquinavaja.
  • por pedro_fortuny (29526) el Viernes, 18 Junio de 2010, 13:35h (#1223626)
    El problema es que esto

    a) No es así de cierto sin más.
    b) Cuando uno hace los "cálculos mentales", siempre da más valor a la posibilidad de que "no lo voy a tener que refactorizar yo".
    c) ¿Cuánto es de más caro?

    "Refactorizar TODO un código MUY mal escrito PUEDE ser más caro que HACERLO desde el principio entero", pero claro:
    a) si voy a hacerlo mal otra vez, pues no lo refactorizo.
    b) "Si funciona no lo toques..."

    Las cosas son más complicadas que una frase bonita, por lo general.

    Cheers!
  • Ahora entiendo....

    (Puntos:1)
    por TeKNo dUKe (40175) el Viernes, 18 Junio de 2010, 13:59h (#1223628)
    ( http://teknoduke.wordpress.com/ )

    Ahora entiendo porque cuando pedia aumento mi jefe me decia "no se puede la empresa tiene muchas deudas".

    --
    I love tha way ya love me and the way ya misbehavin'
  • Demasiado Cara

    (Puntos:1)
    por pata_de_jaguar (46639) el Viernes, 18 Junio de 2010, 15:48h (#1223653)
    ( http://sipakal.blogspot.com/ )
    La deuda técnica es imposible llevarla a cero, porque no sabes que tanto crecerá en un futuro el sistema, ejemplo simple es cuando en la etapa de planeación no existe tanto movimiento y en dado momento esto se dispara, estresando al sistema haciendo caer, es imposible abarcar todos los escenarios. Pero por código mal escrito yo tengo una experiencia, no soy programador, mi profesión inicial era contador, empecé programando el VB6 y cuando decidí dar el paso al Soft Libre, inicé con código php mal escrito, no sabía que era una framework, clases avanzadas, si el proyecto iría a crecer demasiado, etc... ahora me toca refactorizar (llevo buen avance) y eso me ha impedido crear nueva funcionalidades o mejorar la experiencia del usuario. mejorar la velocidad en consulta, etc... y con un sistema de más de 100K líneas y un solo programador está bien feo.
    --
    El poder de los Datos...
  • Sí, pero...

    (Puntos:3, Inspirado)
    por NotFound (9262) el Viernes, 18 Junio de 2010, 18:18h (#1223684)
    ( http://barrapunto.com/ | Última bitácora: Viernes, 13 Noviembre de 2009, 15:33h )
    La explicación de la deuda técnica esta muy bien, es clara y comprensible, pero...

    El problema es que da igual si la explicación es clara u oscura, si usa lenguaje técnico o financiero... La respuesta siempre va a ser: "Es igual, hay que acabarlo YA" (o el "para ayer" que tanto gusta).
    --


    Salu2
  • Programando para psicopatas

    (Puntos:5, Divertido)
    Hoy habia una clase aqui en el curro sobre disenio en C++, y una frase me ha llamado mas la atencion que las demas: "Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live." Si todos tuvieramos esto presente al trabajar, el software en general tendria mucha mas calidad.
    --

    ::Appfluence:: [appfluence.com]

  • Otra opcion

    (Puntos:3, Divertido)
    por tomman (13087) el Viernes, 18 Junio de 2010, 23:17h (#1223720)
    ( http://mi.tsdx.net.ve/ | Última bitácora: Lunes, 07 Marzo de 2011, 22:52h )
    Que tienen de malo las Compensaciones de mal codigo [thedailywtf.com] (bad code offsets). Asi puedo seguir programando basura, mientras otros codificadores competentes se benefician al mismo tiempo!

    Ahora puedes sentirte como los que manejan un Prius :)
    --

    Tom Maneiro
    $ON¥ == EVIL!
    - http://t38.webhop.biz/ -
  • Puntualizaciones

    (Puntos:5, Interesante)
    por DanielSan (10124) el Sábado, 19 Junio de 2010, 08:48h (#1223737)
    ( http://guslibu.awardspace.com/ | Última bitácora: Viernes, 18 Marzo de 2011, 08:29h )

    Refactorizar código mal escrito es siempre más difícil que escribirlo bien desde el principio.
    Ya lo han apuntado en otro comentario, pero lo remarco: No estoy de acuerdo con esa afirmación.

    Es cierto que es difícil mantener código de otros, porque no sabes lo que tenía en mente el autor cuando lo programó, y también es difícil retomar un código escrito hace tiempo, porque puedes no recordar lo que pensaste al programarlo. Igualmente es cierto que un código complejo y desorganizado es más difícil de entender y modificar que uno simple y ordenado... Pero que sea siempre mejor reescribir cualquier código con defectos es algo muy discutible.

    Porque, ¿a qué se refiere el autor del artículo con un código mal escrito para hacer esa afirmación tan categórica? Los programas siempre tienen fallos y nunca hacen exactamente lo que se quiere que hagan ni lo hacen exactamente como se desea. ¿Eso es que están mal escritos? Si el programador no es capaz de entenderlo lo suficientemente rápido como para hacer modificaciones para las que el programa no estaba diseñado en un principio, ¿eso es que está mal escrito?

    Yo quitaría esa frase del artículo, porque hay muchos desarrolladores que piensan incluso justamente lo contrario [joelonsoftware.com] (aunque a veces tenga sentido [slashdot.org]), y porque esa afirmación parece una puerta abierta para justificar el ya demasiado habitual NIH [wikipedia.org] cuando al programador le parece muy difícil, y no cuando sea realmente justificable. Si sabes suficientemente bien lo que hace un código como para reescribirlo desde el principio es que lo entiendes lo suficientemente bien como para hacerlo modificando el original progresivamente. Si no lo sabes, entonces mejor no te arriesgues.

    Y aunque estoy de acuerdo con el resto del artículo, también me ha parecido muy oportuna la precisión [barrapunto.com] que ha hecho más arriba pata_de_jaguar:

    La deuda técnica es imposible llevarla a cero, porque no sabes que tanto crecerá en un futuro el sistema, (...), es imposible abarcar todos los escenarios
    Siento hacer críticas, pero son constructivas, lo que busco es añadir información para complementar el artículo, que me parece muy interesante. Muchísimas gracias.
  • Re:Venga ya

    (Puntos:1, FueraDeTema)
    por pedro_fortuny (29526) el Viernes, 18 Junio de 2010, 16:13h (#1223662)
    Lo justo es compartirlo, es lo que tendría que hacer. Parece que lo tiene en cantidad.
    [ Padre ]
  • 4 respuestas por debajo de tu umbral de lectura actual.