Esta semana leía un post en HackerNews que forma parte de la categoría de preguntas cíclicas en ingeniería de software: en todo foro aparecen cada X tiempo. Se trataba de esta pregunta:
Ask HN: How bad should the code be in a startup? | Hacker News
A mi esta vez además me ha tocado la fibra sensible, me ha pillado lidiando con las (bastante negativas) consecuencias de tener un miembro de equipo que cree que esta pregunta tiene sentido.
Tenemos prisa. OK, si tardamos mucho en crear un producto, nos pueden mojar la oreja y podemos llegar tarde.
Surprisingly, many users would rather use software with some rough edgestoday than wait a year for the shiny, bells-and-whistles version (and in fact what they will need a year from now may be completely different anyway).
The Pragmatic Programmer, 20th Anniversary Edition
Es más, ni siquiera sabemos exactamente qué necesitan ni cómo lo necesitan los usuarios. La manera más eficiente de descubrirlo es salir al mercado e iterar, en lugar de dejárselo a la imaginación: buscar el mítico product-market fit.
Con esto en mente, tenemos que preocuparnos por el ahora, evitar la optimización prematura. Donald Knuth, uno de los padres de la programación, allá por 1974 (ha cambiado poco la película en este caso), la definía como "the root of all evil":
Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered.
El problema es oir campanas y no saber de dónde vienen, quedarse en la idea superficial de que "si no duele [verlo], es que has salido [a producción] tarde", y no profundizar en qué es lo que hay que sacrificar. El software que creamos puede no tener todas las features que nos gustaría, puede tener "rough edges"... pero tiene que ser "good enough":
The phrase “good enough’’ does not imply sloppy or poorly produced code.
De nuevo, The Pragmatic Programmer.
El supuesto trade-off entre calidad del código y duración de un proyecto es un tema vie-jí-si-mo sobre el que se ha escrito EXTENSIVAMENTE. Por citar unos cuantos recursos clásicos más donde se habla de esto:
Peopleware (1987). "Quality —- if time permits"
Rapid Development (1996). "Development speed tradeoffs".
Clean code (2008). Introducción
El tl;dr de todos ellos está clarísimo: con código pobre no hay trade-off que valga. No hay trade-off entre calidad y corta duración de un proyecto, sino que van de la mano:
Rapid Development
Aparte, si tenemos prisa, si necesitamos probar cosas distintas, necesitamos que el software también haya sido diseñado con esto en mente. Código escrito de cualquier manera no nos va a poner esto nada fácil, y entonces los tiempos de entrega empiezan a dilatarse.
Good design is easier to change than bad design.
The Essence of Good Design, The Pragmatic Programmer.
Por lo tanto, creo que quien se pregunta "How bad should the code be", o peor, ni se lo pregunta sino que asume que ha de ser malo y montar una churrería, está confundiendo un compromiso en producto (cuántas features saco, cómo de pulidas han de estar) con otro que no existe a nivel técnico (cómo de mantenible ha de ser mi código).
¿Por qué esta confusión, si entre todos los expertos de nuestra industria hay una voz unánime? ¿Es porque el average developer no lee? ¿Porque solo aprende haciendo coding?
The statistics about reading are particularly discouraging: The average software developer, for example, doesn't own a single book on the subject of his or her work, and hasn't ever read one. That fact is horrifying for anyone concerned about the quality of work in the field; for folks like us who write books, it is positively tragic.
We haven't got time to think about this job, only to do it. Peopleware.
Esto ya es otro tema... Parece que en otras disciplinas tienen últimamente una lucha similar. A Javier Cañada en diseño le costó un disgusto tuitero:
A diseñar no se aprende diseñando - terremoto.net
En cualquier caso, mi consejo, fellow developer, es que si en tu equipo tienes un compi así, vayas preparando las servilletas para recoger el aceite de los churros.