El título de este artículo alude a una de las máximas de la ingeniería: no perder tiempo haciendo algo que ya está hecho. Pese a que este principio pueda parecer trivial, no suele aplicarse en la Ingeniería Software, pese a que casi todos los avances en programación se han desarrollado en torno a este adagio la realidad del software propietario no ha permitido aplicarlo ni en la milésima parte de las veces.
La primera aproximación se realizó por el mero hecho de ahorrar memoria, en aquellos viejos tiempos muy cara, se intentaba que las acciones que se realizaban varias veces durante una ejecución solo estuviesen una vez en memoria; pero esto realmente no es reusar el código, ya que el fin prioritario no era ahorrar trabajo, sino recursos.
Fue probablemente Niklaus Wirth el primer impulsor del reúso del código, con la programación funcional en Pascal y más tarde la modular de Modula-2. Era éste el primer intento serio de implementar ad hoc. una sintaxis que promocionara la estanqueidad de cada módulo dentro de un programa con el fin de poder reusarlos para otros proyectos, amén -por supuesto- de disminuir el número de errores y facilitar la revisión del código. Pese a que ninguno de estos lenguajes se usen intensivamente en la programación actual, se procura seguir siempre la misma filosofía en cualquier lenguaje (incluso C, que no tiene nada de modular en su sintaxis y ha habido que añadírselo con hábiles tretas) ya que ha demostrado claramente su acierto.
Actualmente se ha llegado al máximo extremo en este punto; con la programación orientada a objetos, no solo se tiende a reusar código, si no también las propias estructuras de datos, lo cual es lógico, ya que son las que menos cambian durante el desarrollo de un proyecto. Con lo cual se debería tardar en producir ahora un programa, independientemente de su complejidad, el tiempo que se tarde en encontrar los objetos adecuados, ya implementados, y unirlos con un fin particular ... en teoría.
Sí, en teoría, porque todos estos avances que hemos estado viendo realmente tienen una aplicación muy limitada (comparada con la que se podría hacer) debido esencialmente a dos características propias del software propietario: las licencias software y el síndrome "no hecho aquí".
Las licencias son normas que atañen a la distribución de software. Si se quieren utilizar librerías, o incluso un sistema operativo, de propiedad ajena hay que firmar un contrato para no incurrir en delito. Estos contratos imponen trabas en la distribución de las fuentes (generalmente se basan en la no distribución de las fuentes) y en unos pagos necesarios para su uso. Generalmente se exigen unos altos precios por unas librerías o información clasificada que limitan, y en muchos casos imposibilitan, el desarrollo de productos software en plazos adecuados y a precios contenidos. Además limitan el soporte técnico que los propios creadores pueden dar a sus clientes, un ejemplo sangrante de esta política puede ser la empresa que ahora mismo detenta el monopolio en el software personal, en España (y en mucho otros países) no se tiene acceso a las fuentes ni por sus propios técnicos, lo cual enlentece cualquier respuesta a algún problema serio. Y esto, creo, lo hemos padecido todos los profesionales del ramo.
El síndrome del "no hecho aquí" afecta sobre todo a las empresas de desarrollo, que, debido a no poder acceder a las fuentes de librerías que podrían usar, se ven obligados a rehacerlas completamente debido a la desconfianza en el código que otra empresa ha podido producir. Esta desconfianza se ve apoyada por el hecho de que, si existe algún problema en la librería, ellos no pueden hacer absolutamente nada para resolverlo en el tiempo que esperan los clientes.
Estos dos problemas combinados llevan a la concentración del desarrollo software debido al teorema del "pez grande se come al pez chico", ya que si se necesita un "pedazo" de software en un tiempo crítico, y este lo tiene hecho otra empresa más pequeña, sencillamente se compra y así todos los productos son internos. Esto lleva a un monopolio por su propia naturaleza y a todos los problemas que esto conlleva.
Sin embargo el software libre nos permite romper esas cadenas generando una masa de código altamente reutilizable que acelera el desarrollo de cualquier programa. Así el S.L. es claramente invencible en lo que a calidad, soporte y tiempo de respuesta se refiere frente al software propietario, que tendrá que defenderse intentando que todo, absolutamente todo, quede bajo una licencia, tanto protocolos como estándares de datos, ya que de este modo nadie, más que su dueño, podría hacer una mejora de dicho estándar. Y de hecho esto se está intentando hacer, como extensiones de la máquina Java, extensiones de FrontPage, extensiones HTML no estándares, etc.
Son de estos de los que nos debemos defender, no utilizándolos y criticándolos en todo lo posible, ya que es lo único que nos puede garantizar un mínimo de libertad.