Wednesday, October 21, 2009

Duct tape programming: El codigo elegante no paga tu sueldo


Finalmente me di el tiempo de terminar este articulo sobre la conversacion de the Duct Tape programmer; antes de continuar con el articulo dedicare el resto de este parrafo para tratar de explicar el termino. La traduccion literal es programador de cinta gris; se usa esta expresion porque la cinta gris es un material muy resistente para uso multiple que se invento durante la segunda guerra mundial, donde se utilizo para reparar equipo militar rapidamente, cualquier cosa desde armas de fuego hasta aviones; hoy en dia se utiliza para reparar muchas cosas.

Este articulo ha provocado mucha polemica en las ultimas semanas en los medios sociales; gran parte de la comunidad bloguera y twittera tomo este articulo de Joel como un ataque a TDD, practicas agiles de desarrollo y desarrollo de software de calidad en general, algo que encaja perfectamente si lo analizas un poquito, estas personas viven de eso, es lo que venden, bloguean y twittean sobre esto todo el tiempo, asi que el post les toco unas fibras sensibles. Estos fanaticos de patrones y practicas han lanzado una campaña agresiva para convencer al mundo que a los programadores de cinta gris no les importa la calidad del software, que su codigo es inmantenible, que carece de todos esos atributos que esperamos del buen software. Estas personas son las mismas que minimizan el "contenido meramente tecnico", se les ve hablar y hablar (o escribir) sobre buenas practicas de desarrollo y quejarse de como todo el mundo siempre lo hace mal, pero nunca o raramente los ves hablar sobre implementaciones de algo remotamente relacionado con codigo, yo opino que la teoria esta bien, pero sin la practica no sirve de nada. Como siempre lo digo, el problema en todo caso, son los extremos.

Desafortunadamente para ellos el primer ejemplo de programacion con cinta gris que salta a la vista es StackOverflow, un sitio que ha sido desarrollado por programadores que abiertamente han aceptado sin problema alguno que usan tecnicas que no son precisamente agiles o dentro de los mas estrictos patrones de desarrollo, al mismo tiempo este sitio se ha mantenido funcionando al 100% y han agregado un sinnumero de caracteristicas desde su inicio hasta la fecha, lo cual me dice que tienen un codigo con cualidades que hace que esto sea posible; estoy seguro que el codigo no es algo que el programador promedio podria entender y seguramente los puristas encontrarian muchas cosas que les resultarian muy desagradables por aqui y por alla, pero es codigo que cumple su funcion, y lo hace excelentemente bien.


Cuando dije esto sobre SO en twitter, algunos no lo creyeron (mostrando incredulidad de que algo tan bueno pudiera estar hecho con cinta gris, pero hay podcasts donde hablan abiertamente sobre como conducen el desarrollo del sitio), alguien por ahi me respondio muy enojado tratando de minimizarlo alegando que era el unico ejemplo real de programacion exitosa usando cinta gris, desafortunadamente para ellos (una vez mas) si vemos el tremendo exito en los productos de Apple ultimamente, vemos programacion con cinta gris por todos lados, Apple es la Reina (o Rey?) de la programacion con cinta gris, especialmente el ecosistema de desarrollo para iPhone, los que han trabajado con el saben de sus grandes limitaciones y obstaculos que hay que sortear para escribir aplicaciones, pero al final, la gente esta feliz con el producto, y eso es lo realmente importante, a la gente no le importa si la arquitectura es una porqueria o si el codigo es horrible; lo dire una vez mas: no importa.

El problema mas grande de los puristas es que cuando te concentras solamente en hacer que cada linea de codigo este dentro de un patron de diseño, es muy facil cruzar las lineas de abuso de ingenieria y olvidarse de lo mas basico, que es el cumplir con tus clientes y terminar tus proyectos, si no lo terminas, no importa que tan bueno sea el codigo, desafortunadamente el codigo elegante no paga tu sueldo, terminar tus proyectos si lo hace.

Creo que el patron de desarrollo que uso mas frecuentemente es "lo que funcione mejor", no tengo miedo de usar programacion procedural, funcional, POO, dinamica, stored procedures o lo que se requiera, lo que me permita sacar adelante mi trabajo (bueno, a excepcion de XML, odio XML) de una forma que me permita siempre extender y/o modificar mis sistemas facilmente en un futuro, pero lo mas importante de todo es que estoy acostumbrado a entregar buenos resultados, siempre, sin excusas, con frecuencia predico una de mis frases favoritas: no es opcional, tiene que funcionar. Quiero aclarar un punto muy importante, soy muy estricto a la hora de escribir codigo, me gusta el codigo elegante, sigo principios SOLID, escribo pruebas unitarias cuando un codigo lo requiere, es solo que no me gusta forzar todo dentro de un patron, y no siempre escribo mis pruebas religiosamente antes que el codigo (ok, de hecho, nunca escribo las pruebas primero). Eso para mi, es el programador de cinta gris, el que sabe cuando abstenerse de la mera aplicacion de patrones y tiene siempre presente la mas importante caracteristica de tu software; el software que cumple y se entrega a tiempo es esa caracteristica, sin esta, no importa lo que hagas, aun si es una obra de arte, no vale un centavo.

Por otro lado, creo que si hay areas donde se puede ser purista y aplicar todos tus (des?)conocimientos, creo los que proyectos de codigo abierto o proyectos personales son ejemplos perfectos para aplicar todo esto, no hay fechas de entrega, no hay compromiso, no hay riesgos, estara listo cuando estara listo.

Cuando los puristas se encuentran acorralados ante las muestras de buenos resultados de la programacion con cinta gris, la salida facil -esto me recuerda como los mismos Agilistas dicen que cuando un proyecto Agil falla es porque no se aplico correctamente- es decir que se requiere gente muy talentosa para sacar adelante algo asi, y claro, nadie dijo que fuera facil, se requiere talento, se requiere leer y entender esos blogs de contenido meramente tecnico, experimentar, jugar, hackear; al final, el desarrollo de software es un problema humano. Yo creo que las metodologias son para compensar la falta de talento, pero ese es tema para otro post.

No hay reglas fijas y estrictas en el desarrollo de software, si fuera asi, este seria demasiado facil.
si no les gusta el termino "programador de cinta gris" pueden pasar a reclamarle a Mario Cornejo :)

8 comments:

beyondnet said...

Muy buena entrada doctor, no soy amigo de los extremos, por eso no comparto cuando algunas personas creen que la unica forma de hacer las cosas bien, es como ellos piensan y lo hacen.

Mario Alberto Chavez said...

Eber;

Como comente en mi post "Lo importante es que funcione" http://mario-chavez.blogspot.com/2009/03/lo-importante-es-que-funcione.html, ir a los extremos no deja nada nuevo, pero escribir programas solo para que funcionen olvidando que en alun momento te puede tocar darles mantenimiento esta muy mal, porque cuando tengas que acomodar nueva funcionalidad o cambios y eso te fuerce a reescribir medio programa es un dolor de cabeza.

Y aunque la gente SO diga que solo tiro lineas de codigo y salio SO, creo que no es cierto del todo, ya que simplemente escribir una aplicacion para ASP.NET MVC se obliga a usar patrones y recetas de codigo - MVC es un patron, recuerdas? - ademas de que no creo que escriban codigo sin pensar que mas adelante le van a tener que dar mantenimiento o extender.

Por otro lado mencionas sobre que el desarrollo en el iPhone o lo que es lo mismo Cocoa no tiene pies ni cabeza, no se si hayas desarrollado para Cocoa anteriormente, pero por si nolo notaste Apple te OBLIGA a seguir patrones como el MVC y el Observable para escribir cualquier tipo de aplicacion, ya sea de escritorio o para iPhone, ademas te dice que prefieras Agregacion en lugar de herecia en la POO de Cocoa, y asi como ese ejemplo hay muchos mas. Asi que si no comprendes esos patrones y conceptos de POO, la vas a pasar muy mal desarrollando para Cocoa.

beyondnet said...

Mario, Eber:
Estoy de acuerdo, los extremos son malos. Para mi ir a un extremo es hacer todo a mano, porque no te guste la filosofía de P&P, si tienes SCSF,PRIMS V2,etc. ¿Porqué la necesidad de hacer todo a mano?, acaso no se pierde enfoque en la productividad por demostrar que tambien uno lo puede hacer.
Entre los post de Jeremmy Miller,Ayende veo como rechazan por idelogías absurdas FWK buenos,prefieren hacer uno a mano y por el único hecho de mostrar que son sabios, que afan (creo que de eso viven)....

Mario H. Cornejo said...

Coincido en que todos los excesos son malos. La desventaja de usar "cinta gris" en el desarrollo es que (como ya lo mencionaste antes) puede provocar que se acumule deuda técnica rápidamente.

Snahider said...

Yo creo que empezar a desechar y quitar valor a cualquier nueva idea o práctica que lo que busca es mejorar la forma actual en cómo se hacen las cosas en el software, es mediocre e incluso no profesional.

Por supuesto que el hacer sistemas que "simplemente funcionen" o que en todos los casos se quiera utilizar al 100% TDD, BDD, DDD y tantas cosas raras está mal. Todo tiene un "pero" y diferentes contextos y circunstancias para analizar.

Saludos a Todos.

BlackTigerX said...

creo que al final estamos de acuerdo con que la clave aqui es el equilibrio, por supuesto que no se trata de que algo "solo funcione", pero para mi tampoco se trata de que tengo que hacer que el codigo siempre este apropiadamente dentro de un patron de diseño, eso tambien es un extremo, y ahi es donde hay que usar un poquito de cinta gris y listo, se sacan los proyectos

BlackTigerX said...

Mario por supuesto que hay mucho buen codigo y buenas practicas tambien en el codigo de SO, pero cuando escuchas las historias de cosas que hacen ahi tambien, te quedas como WTF??, pero al final son cosas que han dado resultado muy bien

Willy Mejia said...

Con todo respeto a los detractores ¿Ya leyeron bien el artículo? Contrario a la campaña de desprestigio emprendida por algunos "gurús" y seguida por sus fans. La definición de duct tape programming original no se refiere a olvidarse o despreciar las metodologías, patrones y buenas practicas, sino a no sobrevalorarlas y verlas como lo que son: un medio y no un fin. Así pues si lo piensan bien no es tan descabellado. No hay que forzar los proyectos a usar las herramientas, hay que usar las herramientas para favorecer su buen desarrollo, pero sobre todo para obtener resultados.
Recalco que no estoy a favor de hacer una lado las buenas practicas (como la definición original de duct-tape tampoco lo está) solo que estoy de acuerdo que el purismo muchas veces cuesta demasiado, y queo incluso en ocasiones es contrario a ser pragmático. Los extremos siempre son malos, y el duct-tape original no lo es un extremo, el redefinido si, y es el que hay que evitar.