Estoy de acuerdo “la imagen del software como algo que se construye” es errada, pero la ingeniería civil no es muy distinta de la ingeniería de software.

La ingeniería civil desarrolla documentos y planos que serán interpretados por personas para resolver problemas.
La ingeniería de software desarrolla codigo fuente que será interpretado por computadores y personas para resolver problemas.

El problema es confundir la etapa de diseño (desarrollo) con la etapa de construcción, es equivalente a confundir la etapa de desarrollo con la etapa de computación de las instrucciones.

El equivalente de una carta gantt de una obra es la gestión de procesos y memoria en un computador, hace poco estoy trabajando en diseño de obras y creáme las cartas gantt también existe la confusión y los problemas asociadas al utilizarlas en la etapa de diseño.

Saludos

Creo empezamos a buscar metáforas cuando tratamos de explicar una concepto que es difícil de estructurar, pero que su naturaleza no nos es desconocida. Nos hace click, pues enganchamos la teoría (simplificada elegantemente) con la realidad.

En los últimos años de la u, me llamó mucho la atención la Ingeniería de Software Experimental como aproximación formal para relacionar objetivamente las propuestas teóricas con resultados prácticos, pero nuevamente me encontré sumergido en un mundo sobre-estructurado, donde la mayor preocupación se desvía de ver las nuevas propuestas en la práctica, para centrarse en evitar, mediante intrincados diseños experimentales, las amenazas a la validez de un experimento, en busca de tratar de generalizar conclusiones que por naturaleza no pueden ser generalizadas. De la ESE rescato los Estudios de Casos y Encuestas, que permiten apreciar factores más humanos, y me apresuro en darle el pésame a los Experimentos (o cuasi-experimentos). Lo afirmo desde mi condición de picado porque me demoré 3 años en mi tesis de ESE + XP

Me gustaría dar con una forma de decir “esto sirve! acá está la evidencia!”, más parecida a contar los asistentes a un recital de rock que a los resultados de un test de hipótesis.

Saludos, y gracias por el espacio!

Sin duda como dices la evolución del software debe tener una “naturaleza de ser cambiante”, es decir los proyectos en desarrollo deben cambiar (algo así como el concepto de mejora continua), tal como cambia el ambiente (llámese clientes, IT o RR.HH que lo realizan). Eso hacen que sean MUY complejos de presupuestar o estimar, no ? Y entiendo que no todos pueden darle “el lujo” de hundir capital e inversión por el solo placer de hacer lo que nos gusta como en mi caso muchas veces.

Yo creo que los que nos dedicamos a esto de manera “artesanal” como en Mismatica, debemos dedicarle el 50% de las utilidades a reinventar el software constantemente, y el 25% a vivir de ello y el restante 25% ahorrarlo (para hundirlo en otra locura mas tarde, jajaja).

A mi me resulta especialmente eficaz diría (todavía no se si eficiente), hacer la construcción del producto en base a un PMV (producto mínimo viable), y así como esta entregarlo al cliente como he hecho, y a partir de la enriquecedora experiencia del uso en producción ir depurandolo y mejorandolo, porque al fin y al cabo lo hacemos para vender y no para que nos guste a Vos o a Mi, no ?

En fin, es mi forma de parecer al respecto, gracias nuevamente por compartir tus experiencias con nosotros !.
Mantengo mi promesa en pie de ir los 4 a comer a Pizza Napoli en mi próxima visita a Santiago

Este post tiene una estructura bien rígida que me autoimpuse después de que tenía clara la respuesta al artículo de Alejandro.
La estructura es tal que cada segmento corresponde exactamente a un tema de Roll The Bones, y sigue esa secuencia, por lo tanto cada epígrafe es parte de la letra de cada canción, la excepción, que es el break, hace referencia al único tema instrumental del álbum, por lo tanto tomo la letra de Ghost Rider, que es la canción que Neil Peart escribió cuando volvió de su viaje en motocicleta. La idea era contar una historia, y transmitir conceptos de ingeniería de software. Hay más derivadas, pero están para que las descubran los lectores. Funciona a varios niveles, y realmente me siento orgulloso de haber logrado eso en un post. También este post funciona como un programa.

Me gusta tu propuesta, el arte de hacer catedrales se aprendía en la catedral. Hay un ensayo notable de Paul Graham, Hackers and Painters, que habla un poco de eso. Creo que hay que conectar más el arte, la artesanía, la biología, la cocina, con la ingeniería de software, por eso que si quiero hablar de Map Reduce, hablo de ensaladas, y si quiero hablar de gestión de proyectos hablo de rock. Abrir la mente, experimentar el mundo, la academia se ha quedado estancada, y hay que remecerla un poquito, porque lo necesitamos. Necesitamos más desarrolladores de software, y lo que hacemos es asustarlos, debemos atraerlos, captar su atención. Y para eso es esencial soñar, sigue soñando, transmite tus sueños a tus alumnos, tu experiencia, y haz que interactúen más con otras profesiones, que busquen problemas reales en su comunidad que se puedan solucionar. ¡Hay tantas pymes, o instituciones que se beneficiarían con un poquito de tecnología, es cosa de salir de las torres de marfil!

Gracias por tu comentario, sigamos dialogando.

El tema de la evolución es vital entenderlo bien, porque es un concepto bastante complejo que es enseñado mal en nuestras clases de biología del colegio, evolución no es competencia, no es que el más fuerte gana. No es sobrevivencia del más fuerte, es sobrevivencia del más apto. Evolución es adaptación, adaptación al cambio. No hay progreso en la evolución, como dice Stephen Jay Gould. Por eso el software que sobrevive no es el más bonito, ni es más barato, ni el que sea mejor (“más bueno” ).

El precio está dado por el valor que aporta el software, es mejor el software usable que el más bonito (hay una correlación entre bonito y usable, en todo caso).

La especie que sobrevive es la que se adapta mejor al cambio en el ecosistema, mira los dinosaurios, se convirtieron en aves para sobrevivir…