Hay software realmente muy bueno en todos los sentidos. Piensa en el Mars Rovers, Google, y el Proyecto Genoma Humano. Eso es software de calidad! Hace quince años, la mayoría de la gente, y sobre todo la mayoría de los expertos, habría dicho que cada uno de estos ejemplos era imposible.
Por otro lado, si nos fijamos en el «promedio» del código podemos llorar. Su estructura es terrible, y los programadores no piensan en su corrección, algoritmos, estructuras de datos, o en el mantenimiento.
¿Cómo podemos arreglar el caos en que estamos?
En teoría, la respuesta es simple: educar mejor a nuestros desarrolladores software, un uso más apropiado de los métodos de diseño, y diseñar pensando en la flexibilidad y el largo plazo. Recompensar lo correcto, lo solido y lo seguro. Sancionar la dejadez.
(Entrevista a Bjarne Stroustrup en Technology Review)
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Y que los que eduquen al desarrollador hayan desarrollado.
Lo digo por que alguna vez me ha tocado un profe .. «teórico» de la muerte.
Saludos
El problema es que la mayor parte de los desarrollos son para ayer, con fases de diseño inexistentes o a posteriori, y con el objetivo de que funcione como sea.
He visto codigos en C con instrucciones goto.
En las ‘carnicas’ suele haber ademas un problema con la plantilla: no tiene la formación adecuada (no hace falta ser ingeniero informático), no tiene la vocación (trabaja en esto dado que en su especialización es parcticamente imposible, programadores licenciados en Historia, Filologia o Filosofia), no tienen la motivación (se cobra una miseria y la perspectiva de futuro es nula)
Pingback: Bitacoras.com
Es un problema también de concepción de producto y exigencia del jefe de desarrollo. Un caso emblemático que conozco es una empresa que desarrolla «software as a service» con un único producto estrella (y hasta aquí puedo leer 🙂 ).Esta empresa busca solamente programadores sin ninguna aspiración de ingenieros (y sin ninguno en el equipo que actue como tal, y estoy hablando de ingenieros en general, y no de ingenieros en informática). El metodo de desarrollo es «programo algo y si funciona más o menos bien lo pongo, y sino lo quito». El resultado tiende a inmantenible a pasos agigantados.
Yo no creo que la mayoría del software sea malo, creo qu ela mayoría del software es mucho mejor que otros productos no-software que hay por ahí.
En «Software SuperHeroes» (un libro muy recomendable para pasar el rato) definen el software como la actividad más compleja a la que la humanidad se ha enfrentado hasta la fecha. Sí, nos infravaloramos todos los días, pero para hacer software se necesitan profesionales más cualificados que para muchas otras cosas.
En cuanto a «diseñar pensando en la flexibilidad y el largo plazo» creo que es uno de los enormes errores que se inculca a los estudiantes. Aquí me gustó siempre la aproximación que leí de Linus Torvalds en el Kernel de Linux: design for today, not for tomorrow. Siempre que diseñas algo para «que sea modificado mañana» te equivocas, siempre. Haz que el código sea fácilmente legible y modificable, y resuelve el problema que tienes hoy, que el de mañana ya lo resolverás y seguro que con más datos.
Todo el «overdesign» que hace los programas ridículos e inmantenibles se debe a «que sea modificable mañana».