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 :)
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 :)
Posts
