¿»Ingeniería» del software? Ahora vienen los mea culpa

Etiquetas

ingeniería del software, métrica

Los que leen habitualmente mi blog conocen mi opinión sobre la «ingeniería del software tradicional», muchas veces hablé de ello y del «mal» que hacen en general a la profesión, y hasta como limitan la innovación.

Nunca me gustó que se llame «ingeniería» a un proceso que tiene poco que ver con los de las ingenierías tradicionales, entre ellas que las tradicionales poseen una serie de herramientas analíticas y cuantitativas para evaluar y estimar riesgos y tolerancias. En el desarrollo de software no tenemos esas herramientas, quizás nunca las tengamos: no es lo mismo trabajar en la construcción de elementos físicos, limitados por leyes fundamentales de la física, con pocas combinaciones posibles, con la construcción de programas informáticos que no tienen esas limitaciones físicas, ni en las combinaciones posibles.

Este tipo de visión propuesta desde el mismo nombre «ingeniería» nos lleva a errores muy importantes, por ejemplo el de suponer que las construcciones físicas y las matemáticas [los programas] son equivalentes. No sólo hace «daño» a los proyectos que nunca pueden cumplir plazos y presupuestos, sino también a la propia «ciencia» y profesión informática. Es un engaño, fundamentalmente a los propios profesionales. Así se cometen errores derivados como reclamar colegios, regulaciones y normas y procedimientos similares a otras ingenierías: las soluciones equivocadas son más perjudiciales que los problemas abiertos. Además es ponernos una venda en los ojos para no observar el verdadero potencial de la informática, ni para darnos cuenta de dónde está la innovación (que no es precisamente seguir haciendo el mismo software de siempre).

Escribí bastante sobre estos temas, fundamentalmente en apuntes críticos con la creación de los colegios oficiales informáticos. El núcleo de la argumentación es la que comentaba antes, incluso de crear una «pseudociencia» (p.e. en Recursividad, punteros, estadísticas y pseudociencia del software, Diseño, ingeniería, ágiles… y frameworks, Redescubriendo al Dijkstra provocador 18 años después), además enseñado en la universidad como si de leyes científicas se tratasen –quizás lo que más daño hace–.

También critiqué al establishment de la «ingenieria del software», dominado por tecnológos pocos «científicos» –en su mayoría empleados de grandes corporaciones de desarrollo de software para empresa de Fortune 500– que en ninguna de sus publicaciones científicas presentan los datos para que puedan ser contrastados (algo inherente del software privativo) y sometidos al peer review (que no es aceptable en ninguna otra rama científica). Este mismo establishment ha ignorado durante muchos años al software libre con sus métodos de diseño y desarrollo completamente contradictorios con los propuestos por la «ingeniería tradicional» (muy bien expuesto en al «Catedral y el Bazar» de Eric Raymond).

Muchas de las respuestas que tuve –incluso entre supuestos reputados profesionales– es que «hago daño a la profesión» [sic].

Pero ahora está surgiendo el mea culpa de los gurús incondicionales de la «ingeniería del software». El reconocido gurú Tom DeMarco (gracias Paco) que escribió el artículo de opinión Software Engineering: An Idea Whose Time Has Come and Gone? (algo así como «Ingeniería del software: ¿una idea de tiempos pasados?») que es en gran parte una autocrítica a sus ideas y libro de referencia Controlling Software Projects: Management, Measurement, and Estimation.

Resumo sus ideas fundamentales con algunas de sus frases traducidas literalmente:

• Hoy en día todos comprendemos que las métricas de software cuestan dinero y tiempo, y que deben ser usadas con moderación.
• El desarrollo de software es inherentemente diferente de las ciencias naturales tales como las física, por lo que sus métricas son muchas menos precisas para capturar lo que deben describir.
• La frase más citada del libre es «No puedes controlar lo que no puedes medir». Esta frase contiene una verdad real, pero cada vez me sentía más incómodo con el uso que hice de ella. Está implícita en la frase (y en título del libro) que el control es un aspecto importante, quizás el más importante, de cualquier proyecto de software. Pero no lo es.
• Muchos proyectos se han realizado sin demasiado control pero han generado productos maravillosos tales como Google Earth o la Wikipedia.
• Esto nos lleva a la desagradable conclusión que el control estricto es algo que importa mucho en proyectos relativamente inútiles y mucho menos en proyectos útiles. Sugiere que mientras más te enfoques en el control aumenta la probabilidad de que estás trabajando en un proyecto que se esfuerza por generar algo de valor relativamente menor.
• ¿Estoy diciendo que está bien ejecutar proyecto sin control o con un control relativamente menor? Casi. Estoy sugiriendo que deberíamos seleccionar primero a los proyectos cuyo control preciso no importe demasiado.
• Estoy llegando gradualmente a la conclusión que el momento de la ingeniería del software vino y se marchó.
• En los últimos 40 años nos hemos torturado por nuestra ineptitud en acabar proyectos a tiempo y con el presupuesto previsto. Pero como sugerí antes, no debería haber sido el objetivo supremo.
• El objetivo más importante es la transformación, crear software que cambie el mundo, o que transforme una empresa, o la forma en que hace negocios.
• El desarrollo de software es y será siempre algo experimental. Lo construcción real de software no es necesariamente experimental, pero sí lo es su concepción. Allí deberíamos enfocar nuestros esfuerzos. Allí es donde deberíamos haberlo hecho siempre.

Está muy bien que por fin los gurús de la «ingeniería [tradicional] de software» comiencen a reconocer errores y dejar de ignorar a los métodos y filosofías tan habituales del software libre y de proyectos que han sido realmente innovadores desde el punto de vista de gestión de proyectos de software. Todavía se queda corto y esta opinión me deja la misma sensación de dejè vu que me produjo hace unos diez años la moda de lo métodos ágiles y la programación extrema: era algo que ya se veía hace tiempo en el software libre y de hecho era mucho más radical que las «radicales» nuevas metodologías y métricas. Por ejemplo.

Tom DeMarco cita a dos proyectos que le parecen notables para mostrar la contradicción con las ideas tradicionales: Wikipedia y Google Earth. Pero resulta que ambos tienen muy poco que ver y no han sido «seminales» en sus aŕeas.

El software de la Wikipedia [un wiki colaborativo] es muy sencillo y no fue el primero en hacer un programa de este estilo. el éxito e importancia social de al Wikipedia es el proyecto global, y cómo ha conseguido formar una enorme comunidad de gente que comparte valores de fomentar la divulgación libre del conocimiento. Poco tiene nada que ver con «desarrollo de software», sino con valores y conceptos mucho más amplios.

Google Earth es un programa mucho más complejo pero que ya eran comunes desde principios de la década de los ’90, con el auge de las estaciones 3D (el líder indiscutible era Silicon Graphics, SGI) y la realidad virtual. De hecho Google Earth surge de la compra de una empresa (Keyhole) que a su vez se basó en otras ideas e implementaciones previas de 1994. El logro fundamental de Google Earth poder acceder a esa cantidad de datos y dejarlos a disposición de todo el mundo, algo que antes sólo podían hacer muy pocas empresas. (En todo caso yo hubiese mencionada a Google Maps, porque mostrar esa información usando sólo HTML y Javascript sí fue una innovación importante, junto con Gmail mostraron el camino del desarrollo de aplicaciones Web/Ajax complejas).

Si yo tuviese que elegir proyectos de software realmente indicativo de las contradicciones con las «métricas tradiconales», por ejemplo:

• Núcleo Linux: Es muy complejo desarrollaro un núcleo de sistema operativo, la variedad de hardware es enorme, los bugs tienen consecuencias graves, se necesitan mucho conocimientos, tiene una enorme cantidad de elementos independientes, las combinaciones de caminos de ejecución de casi infinitas. Aún así se desarrolló uno que funciona desde los superordenadores más grandes del mundo a los teléfonos móviles, con el aporte de miles de programadores sin ningún tipo de reuniones, coordinación, diseño previo o siquiera documentación básica (ahora ya hay bastantes libros y documentos).
• KDE/Gnome: Dos proyectos complejos, independientes pero competidores e incluso «con esfuerzos inaceptablemente duplicados», pero que cada uno aportó innovaciones en distintas áreas y se integran o usan en entornos diversos como escritorios completos a dispositivos móviles o multimedias (por ejemplo el Sfari/Webkit que se ejcuta en Mac, iPhones, Androids y Nokias es derivado directo del KHTML de KDE).
• Sistema GNU/Linux o BSD (+ X.org, +GNOME/KDE, +multitud de software): Ejemplo radical de cómo se pueden construir sistemas complejos muy completos basados sólo en una coordinación o consenso mínimó para las interfaces entre ellos. Estas interfaces además son muy simples y no han dejado de evolucionar sin necesidad de «cambios drásticos».

Cualquiera de los tres proyectos es –en código fuente– órdenes de magnitud más grande que la Wikipedia o Google Earth, además ninguno de ellos dependió de una empresa o fundación, y tienen una complejidad y diversad de uso mucho mayor.

Por eso, está muy bien que empiecen a descubrir todo un mundo allí fuera, que creció y se desarrolló sin seguir las métricas y métodos «tradicionales». Es aún una mejor noticia que los gurús de la ingeniería del software empiecen la autocrítica de las ideas erróneas que han fomentado durante 40 años.

Estaría ahora muy bien que los fanboys de esa «ingeniería» empiecen a aceptarlo. Pero sería mucho mejor que los responsables de planes de estudio y asignaturas de «ingeniería del software» en las carreras informáticas sean conscientes del problema, al menos ya tienen a uno de sus gurús poniendo en dudas los cimientos de su [pseudo] ciencia. Quizás así dejaremos de leer y escuchar falacias tales como «para ser buen director de proyecto no hace falta saber programar», «un proyecto es malo si no tiene un diseño previo bien especificado y documentado», o el mantra:

[…] podemos y/o debemos gestionar un proyecto de software de la misma forma que un proyecto de arquitectura.

Futurología: en unos pocos años veremos que el hot topic en las publicaciones de ingeniería del software serán estudios de caso de grandes proyectos de software libre. Nos hablarán de la radicalidad de los métodos ágiles usados, la coordinación debil, el software evolutivo, la complejidad de las relaciones sociales entre programadores y usuarios, la influencia del uso real de los usuarios para el diseño del software, la importancia del release often, del peer review, los casos reales de uso no previstos por los programadores… y volveré a sentir una sensación de dejà vu.

Los problemas derivados del abuso de las analogías

Etiquetas

ingeniería del software, propiedad intelectual, razonamiento por analogía

El razonamiento por analogía es formalmente muy usado en los sistemas legales/judiciales. En general lo usamos para intentar comprender o explicar algo que nos es nuevo o desconocemos. Es una forma de explicar el futuro en el lenguaje del pasado, usar nuestra historia común para interpretar lo desconocido. Este era el fondo del ensayo de Dijkstra que comenté en mi apunte anterior Redescubriendo al Dijkstra provocador 18 años después. Cuando no sabemos enfrentarnos a algo radicalmente nuevo solemos abusar del razonamiento por analogía, lo que a la larga es muy perjudicial ya que no nos permite descubrir la profundiad del cambio.

En general este tipo de razonamiento funciona bien siempre y cuando los cambios sean graduales. Cuando ocurre lo contrario suele provocar desastres intelectuales importantes… incluso legales y judiciales.

Uno de esos desastres legales por abuso de las analogías lo estamos sufriendo en todo el mundo. Se llama «leyes de propiedad intelectual» (que involucran y mezclan cosas distintas como copyright o derechos de autor, patentes, marcas registradas y habitualmente también secretos industriales).

Las primeras normas de copyright surgieron en UK como regulación de empresas [editoras]. Luego el copyright se fue extendiendo cada vez más hasta llegar a igualarse al concepto tradicional de «posesión y disfrute exclusivo de objetos físicos» (la «propiedad»). Cuando todas las manifestaciones de las obras intelectuales debían plasmarse y distribuirse en soportes físicos las leyes funcionaron más o menos bien. Pero cuando ocurrió el cambio radical, ya no era necesario para la creación –ordenadores– ni para la distribución –Internet–, no se abandonó la ya inservible analogía, sino que se la profundizó aún más a costa de elaborar leyes cada vez más ridículas. Así ahora estamos en un sistema que por sí mismo dice favorecer a la cultura, pero sus acciones son todas las contrarias: penalizar y criminalizar su divulgación.

Pero es lógico que ocurra esto. Aunque el discurso que no se cansan de repetirnos esta analogía erróna (usando las palabras como «robo», «propiedad», «piratas»), tiene tan poco que ver una «obra intelectual» con «objetos físicos» y «propiedad» que las leyes basadas en esas analogías sólo pueden ir de mal en peor: códigos penales más estrictos, criminalización de la mayoría de la sociedad, campañas carísimas ridículas y que nadie es capaz de comprender, impuestos disfrazados de tasas y llamados «cánon», etc.

Llega a tanto el absurdo que los gobiernos intentar aumentar las conexiones de banda ancha y el uso de Internet, al mismo tiempo que otro ministerio gasta dinerales en campañas para advertir de los riesgos y crímenes que se cometen copiando música o pelis de Internet… para  luego preocupase por qué se está estancando el crecimiento de Internet en España.

Todo este paroxismo sin explicación lógica sólo acabará el día que nuestros políticos, legisladores, jueces y abogados se den cuenta que la analogía no se sostiene porque no hay casi similitudes. En una palabra, sólo cambiará cuando se den cuenta del abuso que han hecho de la analogía.

Por eso es que hay que ir con mucho cuidado con la analogías, es fácil excederse. Volviendo a Dijsktra, esa y la falta de visión para reconocer el «cambio radical» era su crítica de fondo.

Una de sus críticas era la ingeniería de software. De tanto forzar la analogía con las ingenierías tradicionales no somos capaces de descrubir los problemas… ni la potencia de lo que tenemos entre manos. En 1992 Jack Reeves se quejaba de lo mismo, pero en otros términos, sobre la estrechez de mira de la «ingeniería del sofware». No voy a hacer largo mi apunte, recomiendo la lectura de Code as Design: Three Essays by Jack W. Reeves (gracias por el enlace Juanjo Marin). Así se podrá entender la lógica y quizás mejor analogía de considerar al programa final en código fuente como el «documento final del diseño».

Quizás en poco tiempo hayamos olvidado las  erróneas analogías del diseño y desarrollo de software con proyectos tradicionales de arquitectura, o las más ridículas de profundizar en el error con las típicas comparaciones «arquitecto-albañil», «médico-farmacéutico». Pero para entenderlo toca releer los ensayos de Dijkstra y el de Reeves. Yo no podría explicar mejor qué tenemos que cambiar –en la ciencia, la docencia y la práctica– para llamarnos realmente ingenieros, o por lo menos para no parecernos a algunos reyes de pollos fritos lloriqueando por seguir anclado en obsoletas analogías 🙂

Redescubriendo al Dijkstra provocador 18 años después

Etiquetas

dijkstra, ingeniería del software

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 su estatuto «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.