No hace demasiado hacía referencia al libro de 37signals getting real y cada día que pasa creo que estoy más de acuerdo don ellos. Estaba buscando en el índice del libro un capítulo que ilustrase lo que quiero decir, pero es que creo que todo el libro ilustra lo que quiero decir. Quizás el que mejor lo tiene es "Get something real up and running quickly", esto es, haz algo que funcione.
Cada día que pasa estoy más convencido que el software _necesita_ un proceso de maduración. Mi abuelo hace vino y se tira todo el santo año cuidando el majuelo, poda las parras, las alumbra (1), las injerta (2), ara el majuelo con un arado especial (menos ancho de lo normal), va a menudo a ver que tal va, pone sistemas para que los pájaros con se coman las uvas (por ejemplo los típicos CD's), se pelea con el vecino para que no ponga panales de abejas, lo protege de los paseantes que quieren comerse las uvas cuando esté madura... luego lo vendimia, lo lleva al lagar (3) o la prensa, primero pisa la uva (de ahí sale el mosto más dulce), luego la prensa y mete en los cubetos. Tras varios meses en el que el mosto fermenta y se convierte en vino mi abuelo está pendiente de que nadie entre en la bodega ya que se puede afixiar (el proceso de creación del alcohol es así) ¡¡el vino ya se puede tomar!!
Sin embargo, a pesar de haber trabajado mucho, mi abuelo no queda conforme con su vino, sabe que debe meterlo en botellas de cristal, ponerle unos buenos corchos, etiquetarlas convenientemente (hasta mi abuelo lleva trazabilidad) y esperar laaargos años hasta poder tener un buen vino, el vino por el que todos te felicitan y recuerdan. A veces el corcho no está bien y se pica el vino o resulta que la cosecha no tuvo suficienta azúcar y el vino salió un poco flojo.
Exactamente pasa igual con un producto software, primero se crea y luego se madura. La diferencia es que la madurez del producto se adquiere una vez lo vas dando a probar. Por eso cuanto antes lo des a probar, mejor, y además cuanto menos des a probar, mejor que mejor.
De nada sirve estar un año creando un software con muchos matices si luego, a la hora de la verdad, no funciona muy bien la parte principal. Hace no demasiado presentaban google chrome, todo el mundo ha comentado lo bien que funciona y a pesar de que muchos han echado en falta la posibilidad de incluir pluggins, entre otros, hay buen sabor de boca, incluso se ha destacado su minimalismo.
Como desarrollador tiene también sus ventajas, sientes que has hecho algo redondo, que funciona y que es completamente usable. No hay peor sensación que la de estar frente a un sistema mastodóntico, que no sabes muy bien como funciona y que "a veces" (cuando pasa esto siempre se asocia a un fallo de sincronización de hilos) no "tira" como debería. Poner a funcionar un sistema simple es ya de por sí difícil, así que no me quiero imaginar si además el propio sistema te pone la zancadilla.
Lo mejor es que todo esto lo puedes aplicar a cada clase/fichero/subsistema :).
(1) alumbrar es hacer un hueco debajo de la planta para que el agua se acumule allí.
(2) hacer una especie de lego con las plantas, se deja la raiz de una y se acuña otro tipo de planta sobre ella, es realmente curioso, algo así como un frankestein.
(3) lugar donde se pisa la uva
1 comentario:
Post oportuno, más de una vez me ha comido el tamaño del desarrollo de un programa, y hay que tener en mente mucho de lo que aquí dices.
Publicar un comentario