- Tags:: #✍️OwnPosts, [[My management principles values and practices|My Management Principles Values And Practices]], [[Coding best practices|Coding best practices]] - Date:: [[2020-06-21]] ![[Pasted image 20220912065613.png|400]] 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](https://news.ycombinator.com/item?id=23446627) 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. [[Liquid life|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|The Pragmatic Programmer 20th Anniversary Edition]]: ![[The pragmatic programmer 20th anniversary edition#^001488]] 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](https://a16z.com/2017/02/18/12-things-about-product-market-fit/). Con esto en mente, tenemos que preocuparnos por el ahora, evitar la optimización prematura. [[donald-knuth|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|The Pragmatic Programmer 20th Anniversary Edition]]: ![[The pragmatic programmer 20th anniversary edition#^8c86ee]] 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|Rapid Development]]: ![[Rapid development#^7c1857]] 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|The Pragmatic Programmer 20th Anniversary Edition]]: ![[The pragmatic programmer 20th anniversary edition#^8e6d53]] 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|Peopleware 3rd Edition]]: ![[Peopleware 3rd edition#^b3cebe]] Pero esto ya es otro tema... (update: lo fue. [[Refusing to stand on the shoulders of giants|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__: - [A diseñar no se aprende diseñando - terremoto.net](http://www.terremoto.net/blog-es/a-disenar-no-se-aprende-disenando) 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.