¿Peor es mejor?

En mis primeros días de Erasmus en Londres, un profesor de una asignatura sobre sistemas distribuidos y seguridad nos dio a leer un curioso texto llamada “Worse is better” (Peor es mejor) donde se explicaba, a través de una curiosa discusión sobre sistemas operativos entre una persona del MIT y otra de la universidad de Berkeley, dos escuelas totalmente diferentes a la hora de llevar a termino un proyecto.

Mientras la escuela nacida del MIT defendía hacer las cosas “correctamente”, tomara el tiempo y el esfuerzo que tomara, y siguiendo los principios básicos de simplicidad, corrección, consistencia y completitud, la postura de la gente de Berkeley era más pragmática y hacia más hincapié en obtener un producto “suficientemente bueno” en un tiempo razonable, de forma que pudiera ser usado lo más pronto posible y a partir de ahí ir corrigiendo los fallos que pudieran quedar.

Estas dos filosofías se pueden aplicar a prácticamente cualquier ámbito de la informática, incluyendo, por supuesto, la seguridad. Ante el lanzamiento de un producto o servicio totalmente nuevo para la compañía, se puede optar por hacer análisis exhaustivos, empaparse de toda la documentación disponible perfilando al milímetro cada aspecto del proyecto y realizando complejas pruebas para asegurar que no existe ningún fallo de seguridad —llegando incluso a descartar el proyecto por no poder conseguir un producto realmente seguro tomando el tiempo que ello requiera— o por el contrario se puede hacer un análisis más ligero, ajustar los aspectos críticos e imprescindibles que realmente puedan poner en verdadero peligro al proyecto, y lanzar una versión suficientemente buena como para que los usuarios la adopten en un plazo aceptable, mientras sobre la marcha se van puliendo todos los aspectos que se quedaron en el tintero.

Las consecuencias de ambas filosofías están claras. Mientras que siguiendo los pasos dictados por el MIT el producto estará mejor diseñado, sera más robusto y los usuarios sentirán que están ante una compañía “seria y responsable”, los productos desarrollados bajo la influencia de la filosofía de Berkeley están expuestos a fallos de seguridad que pueden acabar con la confianza de los usuarios. Asimismo puede ser que la solución a los problemas de seguridad del producto requiera un rediseño total de la arquitectura, si ésta es inadecuada o excesivamente simple.

Esto haría pensar que la decisión correcta es seguir la escuela del MIT, si no fuera porque muchos proyectos no tienen una solución correcta y se tienen que asumir ciertas carencias para poder realizarse. Tampoco hay que perder de vista que el tiempo y recursos no son infinitos, por lo que no se puede dedicar todo el esfuerzo de un grupo de personas a un proyecto que tal vez nunca vea la luz. Por último, el hecho de estar en un mercado con libre competencia puede hacer que cuando nuestro sistema haya sido cuidadosamente planificado, diseñado, implementado y esté a punto para su comercialización, encontremos que es tecnológicamente obsoleto u otra empresa ya ha cubierto las necesidades del mercado con otro producto, aunque sea de peor calidad.

Aunque como decía Aristóteles, la virtud está en el término medio, nunca está de más analizar desde ambos puntos de vista qué filosofía sigue nuestra compañía y sus competidoras a la hora de llevar a cabo sus proyectos. Como indica el artículo que les reseñaba al principio, en el caso de Unix y C, el gran ganador fue la filosofía de Berkeley, pero viendo los productos que corren actualmente por el mercado esta claro que no han cambiado mucho las cosas y productos diseñados para ser “suficientemente buenos” son los que copan el mercado; no hay más que ver los flagrantes problemas de seguridad que Twitter está sufriendo últimamente para darse cuenta de ello.

Ustedes, ¿son más de Berkeley, o más del MIT?