Actualidad informática

Hay profesores, lecturas y autores que te influyen desde joven y forjan las ideas y posturas que te perfilan como profesional. Los que me siguen en este blog, o los que han leído mis argumentos –o los de la ACM– respecto a regulaciones (sobre el que no pretendo volver en este apunto, es sólo una autoreferencia) conocen mi postura bastante escéptica sobre el “estado de la ingeniería del software” y el rechazo fanático a las buzzwords y promesas de panaceas.

Varias veces he comentado y citado que casi toda la bibliografía de ingeniería de software de las últimas décadas es sólo una recopilación de anécdotas y estadísticas, casi una pseudociencia, a la que solemos adorar como si la última metodología fuese la bala de plata, la que dará el fundamento a la ingeniería. Pero hace mucho que ya no creo en esto, sobre todo cuando observas que cada cinco años aparece una nueva mutación de metodología que promete ser La Herramienta de la ingeniería del software.

No recordaba cuál bien el camino recorrido, o cuál fue el punto de partida o desvío tomado, para que haya asumido esta postura muy escéptica y bastante minoritaria entre mis colegas y compañeros. Recuerdo que cuando acabé mi último examen y fui con una beca a hacer mi PFC –enero de 1990– me creía el rey del mambo. Estaba seguro que mi formación y presunto dominio del diseño funcional, la visión “sistémica-holística” (sí, vaya, pero eso fueron también los inicios de Scrum basado en trabajos de Hirotaka Takeuchi en 1986) y el dominio de la metodología de moda en aquél momento –Gane-Sarson, luego “mutó” en la de Yourdon– me convertiría en un sólido profesional informático resolvedor de problemas complejos y que encontraría soluciones espectaculares a los grandes problemas de la informática.

Pero cuando quince meses después acabé mi PFC tenía una visión completamente diferente. Cada vez que alguien me explicaba las fantásticas bondades de una metodología nueva, o que casi al principio de una conversación soltaba la frase “un ingeniero no tiene por qué ser un programador” se me ponían los pelos de punta y sólo atinaba a pensar que ojalá no me tocase trabajar con esa persona.

Con el tiempo me convertí en un escéptico casi radical sobre el “[no] cientificismo” y la falta de rigurosidad de metodologías. En el mejor y la mayoría de los casos sólo lo veía como intentos de estandarizar una guía de buenas prácticas y estándares de documentación. Y por otro lado cogí el gusto por aprender a programar y admirar y disfrutar con el trabajo de los que se definían como “programadores” antes que “ingenieros” (o “doctores” o “científicos”)-

Hoy rvr en Barrapunto me hizo un bonito y entrañable regalo, me hizo redescubrir cuál fue una de las lecturas de aquellos años que tanto me influyó. Creo que fue el punto crítico. Se trata de unos de los ensayos más provocadores de Dijkstra –escrito en 1988, que blogger espectacular hubiese sido–: On the Cruelty of Really Teaching Computer Science (en castellano).

Aunque en aquellos años casi no conocía a Dijkstra, creo que fue el director de mi proyecto o alguno de los que trabajaban en el laboratorio el que me lo pasó (teníamos Internet y estábamos todo el día enganchados bajando ficheros por FTP anónimo y leyendo listas de correos y las news).

Rescato una de las frases que más me impactaron como “ingeniero”, por aquellas épocas yo tenía una perspectiva radicalmente opuesta:

[…] Lo haré explicando una serie de fenómenos que de otra manera serían extraños por la frustrante –pero, como ahora sabemos, condenada– ocultación o negación de su aterradora extrañeza.

Cierta cantidad de estos fenómenos han sido agrupados bajo el nombre de “Ingeniería de Software”. Así como la economía es conocida como “La Ciencia Miserable”, la ingeniería de software debería ser conocida como “La Disciplina Condenada”, condenada porque ni siquiera puede acercarse a su meta, dado que la misma es en sí misma contradictoria. La ingeniería de software, por supuesto, se presenta a sí misma como otra causa valiosa, pero es un colirio: si lee cuidadosamente su literatura y analiza lo que realmente hacen quienes se avocan a ella, descubrirá que la ingeniería de software ha adoptado como suestatuto “Cómo programar si usted no puede”.

[…] La práctica está impregnada de la confortable ilusión de que los programas son simplemente dispositivos como cualquier otro, la única diferencia que se admite es que su fabricación pueden requerir un nuevo tipo de expertos, a saber: programadores.

[…] Han pasado ya dos décadas desde que se señaló que el testing de programas puede convincentemente demostrar la presencia de errores, pero nunca puede demostrar su ausencia. Después de citar devotamente este comentario bien publicitado, el ingeniero de software vuelve al orden del día y continúa refinando sus estrategias de testing, tal como el alquimista de antaño, quien continuaba refinando sus purificaciones crisocósmicas.

[…] En el mismo sentido debo llamar la atención sobre la sorprendente facilidad con que se ha aceptado la sugerencia de que los males de la producción de software de deben, en gran medida, a la falta de “herramientas de programación” apropiadas.

Hay que leer todo el ensayo para entenderlo mejor y entender la justificación. No es tan difícil, tampoco fácil. Es un ensayo de esos de gran calado (y por los pocos comentarios que leí en Barrapunto, la mayoría no lo debe haber leído, o no lo entendió).

Ojalá lo disfrutéis tanto como yo la primera vez que lo leí y nuevamente ahora, casi dieciocho años después.

PS: Creo que ahora comprendí a Dijkstra mucho mejor que la primera vez.

Fuente: Ricardo Galli, de software libre

campañas de email
diseño paginas web
echar cartas webcam
marketing on line
paginas web
posicionamiento web inmobiliarias
posicionar en google
Signos zodiacales
Videncia

<< Volver