Código limpio vs Proyectos de éxito

[José Manuel Beas]

He leido recientemente un artículo de Gojko Adzic donde critica lo sucio que está el código de Hudson/Jenkins. Como explica en uno de los últimos comentarios de una larga lista de reacciones que ha provocado el artículo, su intención era apuntar que la calidad de un código no es una medida del éxito de un proyecto. ¿Qué opináis vosotros?

http://gojko.net/2011/04/05/how-is-it-even-possible-code-to-be-this-bad/

Un saludo,
Jose Manuel Beas

http://jmbeas.es

http://agilismo.es

http://twitter.com/jmbeas

[Eduardo Ferrández]

En mi opinión la calidad y el éxito no están relacionados en ningún tipo de producción intelectual. Sólo tienes que mirar alrededor. ¿Qué tipo de música tiene más éxito? ¿y el cine? ¿y la literatura? 

La calidad está relacionada con la durabilidad más que con el éxito ¿te acuerdas de la canción del último verano? Yo no, pero seguimos interpretando música que se compuso hace 5 siglos (o más).

[Alfredo Casado]

Lo primero que habría que decir es que eso de que el código es sucio... pues supongo que depende con que lo compares, personalmente conozco gente que ha contribuido con código al proyecto y dice que algunas partes son un poco reguleras mientras que hay otras cosas que están muy bien, cualquier proyecto grande tiene puntos "negros". Pero por ejemplo podeis comprobar la gran cantidad de test que tienen con un buen nivel de cobertura. Vamos que este "código" sucio de jenkins esta IMHO bastante por encima en cuanto a calidad interna que la mayoría de los desarrollos a medida que se hacen en java (por comparar mismas tecnologías). 

Luego, la calidad interna no es un medida de éxito eso esta claro, eso seria confundir el fin con el medio. La calidad interna de un desarrollo no asegura no su éxito, sin embargo no contar con la calidad suficiente es un factor de riesgo muy peligroso, nuestra obligación como desarrolladores es disminuir todos los factores de riesgo técnicos al minimo para asegurarnos que el proyecto pueda ser un éxito si se cumplen otros factores importantes (que el producto sea el adecuado, que tenga mercado etc,etc). 

El 30 de abril de 2011 13:23, José Manuel Beas <jose....@gmail.com> escribió:

[Javier Gómez]

Alfredo, cuando hablas de riesgo, supongo que uno de ellos es la acumulación de deuda técnica ¿no?.

Hago esta referencia porque creo que en algún punto, fin y medio se cruzan o, al menos, pueden estar relacionados. Me refiero a que un producto que hoy es un éxito, puede acabar convirtiéndose en un fracaso, simplemente porque comience a ser poco fiable, porque el código, al ir creciendo, se vuelva inmantenible, aparezcan demasiados bugs, etc.. Quiero decir que el tiempo juega en nuestra contra ya que la pelota se va haciendo más grande.

Esta reflexión la extraigo de la que hace Uncle Bob en el capítulo 1 de Clean Code, concretamente en el segundo y tercer párrafo de la página 3.

"I know of one company that, in the late 80s,

wrote a killer app. It was very popular, and lots of

professionals bought and used it. But then the

release cycles began to stretch. Bugs were not

repaired from one release to the next. Load times

grew and crashes increased. I remember the day I

shut the product down in frustration and never

used it again. The company went out of business

a short time after that.

Two decades later I met one of the early employees of that company and asked him

what had happened. The answer confirmed my fears. They had rushed the product to

market and had made a huge mess in the code. As they added more and more features, the

code got worse and worse until they simply could not manage it any longer. It was the bad

code that brought the company down."

¿Que os parece?, ¿es posible llegar a un acuerdo sobre lo que se considera buen cóodigo y que además sea medible?.

Saludos