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