¿Peor es mejor?

mvsbEn 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?

Comments

  1. Se que la pregunta es semiretorica, pero no me puedo resistir a puntualizar algo: Creo que al mercado le da exactamente igual de donde seas tu, si de Berkeley o del MIT. Eres tu el que debe saber donde está tu mercado, si en Berkeley o en Massachusetts. Te posicionas ahi y a coopetir sea dicho.

    Lo digo porque, seguro que en un plano teorico, todos somos del MIT.

    Un detalle respecto a eso de posicionarse: creo que ademas de “lo que dicen los libros”, no estaria de mas (imprescindible?) informar internamente que estas ahi posionado (aqui de la teoria a la practica puede haber 3 años luz). La motivacion de esto es evitar frustraciones. Es muy típico que los tecnólogos nos enamoremos de nuestra tecnologia, olvidando por el camino que si esta no está en el mercado dentro de una estrategia corporativa coherente (DIA no vende Jamon de Jabugo, ni el supermercado de El Corte Ingles tartas caducadas a mitad de precio, no?) estamos haciendo el panfilo y antes o despues la organizacion sufrirá las consecuencias (tensiones en RRHH?). Para evitar esto, hay que saber donde esta uno y eso implica que los RRHH conozcan las circunstacias internas y externas de una organizacion.

    Sí, yo tambien querria ir al MIT, pero Berkeley me pilla mas cerca (aunque siempre que puedo me escapo ;))

    Sergio.

  2. http://Francisco%20Benet says

    Buen post sobre estrategia de diseño, pero al final lo que manda (como dejas entrever) es la estrategia comercial, aunque finalmente desde mi punto de vista siempre existe una restricción o coto de dicha estrategia basada en el mercado al que se destina el producto. El peso de ambas filosofías (siendo que la de MIT es casi imposible de conseguir, y más si hablamos de seguridad) puede venir dado por el tiempo de salida al mercado (ser los primeros siempre da ventaja), el porcentaje de aprobación del producto, el mercado al que va dedicado,…

    En cualquier caso, al final el pragmatismo funcional (vista deformada de ver el tiempo de desarrollo) se impone a la seguridad del producto, imponiéndose la visión de ‘que debe hacer’ al ‘cómo hacerlo’.

    Y es que nosotros mismos nos hemos educado para que las cosas no sean perfectas, ni funcionalmente ni operativamente… y ejemplos en la industria sobran.

  3. Que bien te ha salido el post, muy interesante el dilema. Calidad o Cantidad? He ahi la cuestion :P

    Yo aun albergo la esperanza de que llegara el dia en que el MIT saldra vencedor de este dilema.

    Felicidades, estupendo post, ameno e interesante.

  4. Aquí solo puedo proporcionar mi respuesta preferida, “Depende”, ¿en que mercado estamos compitiendo?, ¿para quien es nuestro proyecto?, ¿cuanto peso tiene la seguridad? Hay entornos donde no puedes asumir ciertos riesgos ;-)

    Si, me quedo con esta respuesta, depende.

  5. ¡Muy buen articulo Javi! Ya por fin llegue a casa y pude leerlo con calma. La verdad que te expresas de cine muchacho.

    Yo personalmente me quedo con una base MIT y con un final del proyecto al estilo BerKeley por que con una buena base siempre se puede mejorar el producto, en cambio con una base mala, todo lo que hagas por encima no sera más que un parche tras parche.

    Nos vemos mañana ;)

    JMG

Trackbacks

  1. […] (véase el enfoque de Berkeley frente al del MIT en la entrada de Javier Vela al respecto, ¿Peor es mejor?). La situación actual es algo distinta ya que la capacidad del entorno de encontrar y explotar […]