Respuestas a estudiantes de ingeniería de software

30 Abril 2010

Recordemos lo que nos dice Dijkstra sobre la 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 su estatuto “Cómo programar si usted no puede”.

(ver La disciplina condenada)


Pues bien, Dijstra ahonda un poco más mediante sus famosas respuestas a estudiantes de ingeniería, que fueron amablemente traducidas por Javier Smaldone, y que copio acá:



Respuestas a preguntas de estudiantes de Ingeniería de Software

[La reconstrucción aproximada de las preguntas se deja como ejercicio al lector.]

  • Los aparatos no son necesariamente una mejora. Véase la sucesión

    Pizarrón -> Proyector de transparencias -> Power Point

  • Y no necesito perder mi tiempo con una computadora sólo porque soy un científico de la computación. [A los investigadores en medicina no se les exige sufrir las enfermedades que investigan.]
  • No es el negocio de la ciencia de la computación el promover la “computerización”, digamos, desarrollando aplicaciones exigentes para crear un mercado para la próxima generación de hardware. [A los investigadores en medicina no se les pide desarrollar nuevas enfermedades para crear un mercado para nuevos productos farmacéuticos.]
  • No es la tarea de la Universidad el ofrecer lo que la sociedad pide, sino lo que la sociedad necesita.
    [Las cosas que la sociedad pide son por lo general comprendidas, y no se necesita una universidad para eso. La universidad debe ofrecer lo que nadie más puede proveer.]
  • Estamos delineados por las herramientas que utilizamos, en particular: los formalismos que usamos definen nuestros hábitos de razonamiento, para mejor o peor, y esto significa que debemos ser muy cuidadosos en la elección de qué aprendemos y enseñamos, ya que desaprender no es posible.
    [Hace varios años, si pudiera usar un nuevo asistente, un prerrequisito sería "Sin exposición previa a FORTRAN". En las escuelas de Siberia, la enseñanza del BASIC no estaba permitida.]
  • Un programador debe ser capaz de demostrar que su programa tiene las propiedades requeridas. Si esto se deja para más adelante, es seguro que no será capaz de cumplir con su obligación: sólo si permite que esta obligación influencie su diseño, existe la esperanza de que pueda cumplirla. Solamente verificar a posteriori le deniega esa sana influencia y por lo tanto es poner el carro delante del caballo, pero es exactamente lo que ocurre en las casas de software donde “programación” y “aseguramiento de la calidad” (“quality assurance”) son hechos por grupos distintos. [No hace falta decirlo, esas casas entregan productos sin garantía.]
  • Las técnicas requeridas para el razonamiento efectivo son bastante formales, pero mientras la programación sea hecha por gente que no las domina, la crisis del software permanecerá entre nosotros y será considerada una enfermedad incurable. Y ya sabe lo que provocan las enfermedades incurables: abren las puertas a curanderos y charlatanes, quienes en este caso toman la forma de gurús de la Ingeniería de Software.
  • Algunos de ustedes dudan que las ya mencionadas “técnicas del razonamiento efectivo”, agradables como lo son para programas pequeños, sean escalables -cito- “dado el desalentador tamaño y la escarpada complejidad de muchos programas”. Bien, serán inútiles si se usan para desenmarañar el lío horrendo producido por un grupo de programadores incompetentes y desorganizados. Su poder se manifiesta en la etapa de construcción, donde (i) tienden a producir textos mucho más cortos de los que se producirían de otra forma y (ii) la longitud de las derivaciones de programas tienden a crecer no mucho más que linealmente con la longitud de los programas derivados. Finalmente, los programas así producidos son infinitamente mejores que la basura usual.
  • No debemos olvidar que los programadores viven en un mundo de artefactos, un hecho que los distingue de la mayoría de los demás científicos. El programador no debe preguntar qué tan aplicables son las técnicas de buena programación, debe crear un mundo en el cual son aplicables; esta es la única manera de producir un diseño de alta calidad. A esto debo agregar una cita de EWD898 (1984):
    Las capacidades de las máquinas nos dan lugar en abundancia para hacer un lío. ¡Oportunidades ilimitadas para ensuciar las cosas! Desarrollar la disciplina intelectual austera de mantener las cosas lo suficientemente simple es, en este entorno, un desafío formidable, tanto técnica como educativamente.
  • En respuesta a las preguntas de por qué enseñamos cosas inútiles que la industria ignora, los refiero a EWD920 (1985). Permítanme citar un párrafo:

    Volviendo a la pregunta original: ¿puede la ciencia de la computación salvar a la industria de la computación? Mi respuesta es “Si la industria de la computación puede ser salvada, sólo la ciencia de la computación puede hacerlo”. Pero puede tomar mucho tiempo antes de que la industria de la computación -en particular, las compañías bien establecidas- compartan esta visión. Casi con seguridad tomará más que el periodo limitado por el cual planifican sus futuros. Mientras tanto, el mundo académico -que tradicionalmente planifica mirando mucho más adelante- no tiene elección. Tie
    ne que refinar y enseñar al máximo de sus habilidades cómo debe ser hecha la computación; si cediera a la presión de propagar las malas prácticas actuales, sería mejor que quebrara.

    Pero para destacar cuánta paciencia necesitamos, déjenme darles otra cita antigua (de 1988)

    Muy poca gente reconoce que la alta tecnología tan celebrada actualmente es esencialmente una tecnología matemática.

    (del reporte “2nd David”, llamado así en honor al director del comité, Dr. E. E. David Jr.)

  • No, me temo que la ciencia de la computación ha sufrido la popularidad de Internet. Ha atraído a una cantidad creciente -¡por no decir abrumadora!- de estudiantes con muy poca inclinación científica, y en la investigación sólo ha consolidado la prevaleciente (y algo vulgar) obsesión con la velocidad y la capacitdad.
  • Si, comparto su preocupación: cómo programar bien -aunque un tema enseñable apenas se enseña. La situación es similar en las matemáticas, donde el plan de estudios explícito está confinado a los resultados matemáticos; cómo hacer matemáticas es algo que el estudiante debe absorber por ósmosis, como el hablar. Una razón para preferir argumentos de cálculo mediante la manipulación de símbolos, es que su diseño puede enseñarse mucho mejor el diseño de argumentos verbales/pictóricos. La introducción a gran escala de cursos de tal metodología de cálculo, sin embargo, encontría problemas políticos insalvables.
  • En el negocio del software hay empresas para las cuales no está claro que la ciencia pueda ayudarlas. Que la ciencia debería intentarlo tampoco está claro.

Austin, 28 de noviembre de 2000

prof. dr. Edsger W. Dijkstra
Departamento de Ciencias de Computación
Universidad de Texas
Austin, TX 78712 – 1188
USA


Artículos relacionados

Tags: , , ,

4 Responses to Respuestas a estudiantes de ingeniería de software

  1. jrovegno on 1 Mayo 2010 at 15:59

    Agrego otra consulta: Así como en la matemática da herramientas a la ingeniería, ¿por qué la informática se ha centrado en crear las herramientas y usarlas ellos mismos para resolver problemas de ingeniería?, en vez de entregarle esas herramientas a la ingeniería, como lo hacen las matemáticas.
    ¿Que es mejor? Programas de ingeniería son creados por informáticos que poco saben del problema de ingeniería o por ingenieros que saben poco de informática. ¿Como hacer que el trabajo interdiciplinario sea efectivo?
    Saludos
    PD: Ups mi comentario anterior era también para este hilo, eso me pasa por tener tantas ventanas abiertas.

  2. Eduardo Diaz on 1 Mayo 2010 at 16:39

    La respuesta en este caso se relaciona con lo mismo, al ser la computación una ciencia básica, todos podemos hacer computación. Entender la computación como una rama de la ingenería es lo erroneo, la computación es un fundamento, es más horizontal, como las matemáticas, la física, ahí mismo, debajo de esas dos ciencias está la computación.
    Entonces todos deben saber computación, se debe enseñar a programar de la misma forma que se enseña a dividir, es fundamental (de hecho yo propongo que se enseñe primero a programar y después las matemáticas, es más fácil de ese modo).(http://www.lnds.net/blog/2009/02/un-programa-para-ensenar-matematicas.html)

  3. jrovegno on 7 Mayo 2010 at 01:43

    Pero si dejamos a “la academia” enseñar computación como lo han hecho tradicionalmente con las matemática, sería saturar aún más al alicaído sistema educativo.
    No sería una buena oportunidad formar profesores de computación armados con metodologías más ágiles, que contagien al resto de las ciencias.
    Es a caso ya demasiado tarde y la computación se redujo a que los profesores tradicionales enseñen a usar el “power toin”.
    Saludos

  4. Eduardo Diaz on 8 Mayo 2010 at 12:57

    Creo que efectivamente la academia le ha hecho mucho daño a la computación, pero afortunadamente hay muchos hackers que la mantienen viva.
    En el caso chileno creo que, como se ha demostrado hace poco, la enseñanza de las matemáticas ha sido un desastre, y de ahí se explica lo malo que somos en ciencias básicas, con mayor razón en computación.
    Hay que enseñar de una forma nueva, reformar la academia, quemar la universidad de Lagado, derribar Laputa y empezar a retomar en el espíritu de Andrés Bello, de eso algo tiene que decirnos mi amigo Pepe Flores, es bueno retomar el ideario de Bello.

Agregar un comentario

Su dirección de correo no se hará público. Los campos requeridos están marcados *

*

Notifícame de nuevos comentarios a mi email. Puedes también subscribirte sin comentar.

Si quieres ingresar código colócalo entre [code] y [/code].