Inicio > ciencia, desarrollo, programación > Los problemas derivados del abuso de las analogías

Los problemas derivados del abuso de las analogías

diciembre 8, 2008

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 :-)

  1. diciembre 8, 2008 en 10:29 pm

    Al final, se trata de ver qué cosas funcionan. Observar proyectos de éxito (el kernel de linux, como tu comentabas el otro día) y preguntar qué metodología se ha utilizado.

    La analogía de arquitecto y albañiles puede no ser del todo incorrecta. Siempre se necesita gente que coordine o indique el camino a seguir, establezca prioridades, etc. Estos serían “los arquitectos del código”.

  2. diciembre 9, 2008 en 3:20 am

    Ricardo, si yo tengo una idea, ¿no puedo decir que es “mi idea”? ¿no es eso una forma de propiedad?

  3. diciembre 9, 2008 en 11:29 am

    @eduardo diaz

    Como dijo alguien, las ideas dejan de ser tuyas en cuando se las has contado a alguien. Además las ideas no son totalmente originales, es muy difícil que alguien tenga una idea completamente original, esos son los genios, y aún así no decimos que la gravedad o la relatividad sean propiedad de Newton o Einsten :-)

  4. Juanjo Marin
    diciembre 9, 2008 en 1:37 pm

    @Jaume Barceló

    El problema de la anaogía de “los arquitectos del código” es que supone que su papel está muy definido y se deduce qye existen otros que son “los obreros del código”.

    Si consideramos que el código es “documento final del diseño”, y nos empeñamos en seguir usando la analogía de la construcción, al menos “el obrero del código” pasa al compilador :-)

  5. plant
    diciembre 9, 2008 en 3:46 pm

    >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”.

    Vamos a ver, una cosa es que el código sea el “documento final del diseño” y otra distinta es que no se haga diseño previo al código o incluso mientras.
    Creo que estás malinterpretando al igual que hacen muchos a Reeves.

    Él mismo responde a esto en http://www.developerdotstar.com/mag/articles/reeves_13yearslater.html (al final del comentario os pego la parte)

    Vereis que esto no entra en ninguna contradicción con lo que se considera actualmente en la Ingeniería del Software actual, en UP por ejemplo. Sí que es una crítica acertada vista en su contexto temporal al igual que la de Dijkstra porque efectivamente hace no mucho sí que había quienes no sólo se empecinaban en desarrollos completamente lineales sino que no paraban de repetir aquello de “la codificación debe ser la parte menos importante del proyecto ya que no es más que la traducción de especificaciones”, por ello se tendía a perder tiempo con especificaciones farragosas con la convicción de que así el programador puede ser poco más que un lingüista. El tiempo ha demostrado sin embargo que este tipo de visión sólo puede funcionar a lo sumo en proyectos para sistemas de información más que trillados donde la complejidad no está en el software en sí sino en capturar correctamente los requisitos y eventos. Para el resto de proyectos, a poco que sean mínimamente novedosos, las metodologías y documentación son ayudas y camino, más que soluciones en sí mismas. La solución siempre es el código.

    =====================================================
    Nevertheless, people keep insisting that my contention of “the source code is the design” means “don’t do design, just code.” I never said anything of the sort. What I did say was:

    “In software engineering, we desperately need good design at all levels. In particular, we need good top level design. The better the early design, the easier detailed design will be. Designers should use anything that helps. Structure charts, Booch diagrams, state tables, PDL, etc.—if it helps, then use it.”

    Today, I would phrase it differently. I would say we need good architectures (top level design), good abstractions (class design), and good implementations (low level design). I would also say something about using UML diagrams or CRC cards to explore alternatives. Nevertheless, I will not back away from the following statement:

    “We must keep in mind, however, that these tools and notations are not a software design. Eventually, we have to create the real software design, and it will be in some programming language. Therefore, we should not be afraid to code our designs as we derive them.”

    This is fundamental. I am not arguing that we should not “do design.” However you want to approach the process, I simply insist that you have not completed the process until you have written and tested the code.

  6. diciembre 9, 2008 en 6:19 pm

    > Vamos a ver, una cosa es que el código sea el “documento final del diseño” y otra distinta es que no se haga diseño previo al código o incluso mientras.
    Creo que estás malinterpretando al igual que hacen muchos a Reeves.

    ¿Cuándo dije yo tal cosa? Sacáis unas conclusiones que acojonan y luego respondéis a esas conclusiones, como un diálogo de sordos.

    Lo que mantengo siempre es que la programación es parte del diseño, que no hay diseño sin programación y que no se puede separar “diseñador-programador” recurriendo a la errónea analogía “arquitecto-albañil”.

    > Para el resto de proyectos, a poco que sean mínimamente novedosos, las metodologías y documentación son ayudas y camino, más que soluciones en sí mismas. La solución siempre es el código.

    Pues creo que estamos totalmente de acuerdo, y si lees mis discusiones sobre el tema, esa es la línea que mantengo hace muchos años :-)

  7. alenarterevista
    diciembre 9, 2008 en 7:02 pm

    Ricardo, yo soy bastante sencilla en mis planteamientos, no entiendo nada de leyes ni palabras técnicas. Lo que tengo claro es que si yo pongo un escrito mío en mi blog y alguien lo copia literalmente en el suyo y no dice de dónde procede el articulo, ese individuo es un plagiador.
    Tengo claro que si yo escribo un libro y lo pongo en soporte pdf, con un copyrigth de derechos de autor, cualquiera que copie sin pedirme permiso o sin citar la fuente de donde lo toma es un plagiador.
    Otra cosa es el tema de la SGAE, y las batallitas, y que efectivamente quieran sacar tajada, eso no te lo discuto, pero con la defensa del tomar libremente cualquier imagen o texto de la red se está (sin querer probablemente) haciendo un gran servicio a la gente que opina que “todo vale”. Y somos muchísimos los que pensamos que no, que no todo vale.
    Un cordial saludo.

  8. diciembre 9, 2008 en 7:07 pm

    @alenarterevista

    Antes de continuar deberías aprender la diferencia entre copiar y plagiar, que lo estás usando incorrectamente. Así nos va, no se puede debatir sin tener que explicar cada día y por enésima vez conceptos básicos.

  9. diciembre 11, 2008 en 3:25 pm

    Lo cual demuestra la situación de “tormenta perfecta” que estamos viviendo. En pocos años, tal vez 10, hemos pasado de una sociedad donde sólo una pequeña élite de compositores, escritores, editores, inventores, etc. eran los encargados de crear, a otra donde hasta el peón más bajo puede ser creador, reprógrafo y distribuidor, todo con un solo click.

    La mayor parte de la población nunca se había planteado los procesos de la información, dado que nunca tenían el control sobre información de ningún tipo. Ahora todavía tenemos grandes sectores de la población en esa situación, mientras otros grandes sectores ya han dado el salto, y siguen avanzando. Los conflictos son inevitables mientras siga habiendo gente anclada en el viejo lenguaje, que seguirá habiéndola para rato.

  1. diciembre 8, 2008 en 11:03 pm
Los comentarios están cerrados.
Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 475 seguidores

A %d blogueros les gusta esto: