- Tags:: ✍️OwnPosts, My management principles, values, and practices, Coding best practices
- Date:: 2020-06-21
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. From 📖 The Pragmatic Programmer, 20th Anniversary Edition:
Link to originalSurprisingly, many users would rather use software with some rough edges today 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)
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”. De nuevo 📖 The Pragmatic Programmer, 20th Anniversary Edition:
Link to originalThe phrase “good enough’’ does not imply sloppy or poorly produced code.
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. De 📖 Rapid Development:
Link to original
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. De 📖 The Pragmatic Programmer, 20th Anniversary Edition:
Link to originalGood design is easier to change than bad design
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? De 📖 Peopleware 3rd Edition:
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.
Link to original
Pero esto ya es otro tema… (update: lo fue. ✍️ Refusing to stand on the shoulders of giants). Parece que en otras disciplinas tienen últimamente una lucha similar. Por ejemplo a Javier Cañada en diseño le costó un disgusto tuitero:
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.