La programación apesta (Programming Sucks)
AbrahamProgramming Sucks ("La programación apesta") es el título de un divertido, pero realista, post en el blog StillDrinking.org. Este post hace divertidas pero interesante reflexiones sobre el funcionamiento del mundo de la programación y hace una analogía con el mundo de la construcción, comparando cómo se hacen programas con el modo de construir puentes. Os dejo aquí un párrafo del texto, pero recomiendo la lectura del post original; es terriblemente entretenido.
Imagine joining an engineering team ... You start by meeting Mary, project leader for a bridge in a major metropolitan area. Mary introduces you to Fred, after you get through the fifteen security checks installed by Dave because Dave had his sweater stolen off his desk once and Never Again. Fred only works with wood, so you ask why he's involved because this bridge is supposed to allow rush-hour traffic full of cars full of mortal humans to cross a 200-foot drop over rapids. Don't worry, says Mary, Fred's going to handle the walkways. What walkways? Well Fred made a good case for walkways and they're going to add to the bridge's appeal. Of course, they'll have to be built without railings, because there's a strict no railings rule enforced by Phil, who's not an engineer. Nobody's sure what Phil does, but it's definitely full of synergy and has to do with upper management, whom none of the engineers want to deal with so they just let Phil do what he wants. Sara, meanwhile, has found several hemorrhaging-edge paving techniques, and worked them all into the bridge design, so you'll have to build around each one as the bridge progresses, since each one means different underlying support and safety concerns. Tom and Harry have been working together for years, but have an ongoing feud over whether to use metric or imperial measurements, and it's become a case of "whoever got to that part of the design first."
Reader Comments (5)
No se puede comparar la construcción al desarrollo de software, porque en la construcción las técnicas están establecidas y los objetivos son claros, en el desarrollo de software rara vez ocurre eso. Y eso no es malo, simplemente forma parte de su naturaleza.
El comentario se queja de las aportaciones de los individuos del equipo, como si eso fuera algo malo, sera algo malo en construcción. Pero en otras cosas, por ejemplo en el cine, la aportación personal de cada individuo es lo que hace que una película sea buena.
Ahí le has dado. El desarrollo de software no es algo que venga sujeto a unas reglas y requisitos estrictos preestablecidos. Es una materia muy muy joven. Aún cuando se ha avanzado muchísimo en procedimientos, metodologías, patrones, frameworks, etc al final sigue siendo algo caótico, un trabajo artesanal, un arte (como el cine) donde las estrellas son importantes para el éxito, un milagro cuando los proyectos salen bien!.
Esto es lo que lo hace interesante y divertido. El día en el que desarrollar sea como poner ladrillos y seguir unos planos, unos materiales y unas técnicas precisas y definidas desde un principio... entonces si que podremos decir con razón "programming sucks".
Un saludo
Así nos luce el pelo, el problema no es que el día que el desarrollo sea como la construcción ... el problema es que si la construcción fuera como el desarrollo de software no habría una casa en pie (siendo muy generalista).
Comparar el desarrollo de software con el trabajo artesanal me parece muy desafortunado.
Existen muchísimas reglas, patrones y metodologías a seguir, no seguir ninguna no te hace una estrella, te hace un estúpido.
Yo no he dicho que no haya que no haya que seguir patrones reglas y metodologías ni que un buen desarrollador no deba seguirlas, sino todo lo contrario. Lo que afirmo por mi experiencia es que, incluso a pesar de utilizarlas, al final un proyecto de software no es 1+1=2, sino algo mucho más complejo con infinitas variables y condicionantes tanto técnicos como humanos.
Precisamente cuando más nos luce el pelo es cuando no tenemos suficiente entendimiento o interpretamos las especificaciones en diagonal, tal y como tu has leído mi mensaje.
Un saludo
Ni tanto ni tan calvo. Hay reglas y metodologías que conviene seguir, pero el problema es que no son suficientes si las comparamos con otras ingenierías.
Comparar la programación con la construcción, es una analogía bastante desafortunada. Hace tiempo, Bruce Eckel escribió un artículo en el que decía que la analogía más correcta es con la escritura (en el sentido artístico). Y estoy de acuerdo.
Al igual que con la programación, a la hora de escribir un guión o una novela, existen reglas y metodologías, pero hay un componente muy importante de creatividad. Aunque hacer las cosas sin orden ni concierto suele terminar en desastre, seguir las reglas a rajatabla no garantiza un buen producto. No hay una receta mágica para que funcione. Sólo un conjunto de buenas prácticas que conviene seguir.