En 1989 Richard P. Gabriel introdujo el concepto de Peor es Mejor (Worse is better), o el estilo New Jersey, que
corresponde a una filosofía de diseño del software en que la simplicidad de la interfaz, y sobretodo de la implementación
es más importante que cualquier otra propiedad (incluyendo la correción, consistencia y completitud).
Este concepto fue introducido como un capítulo de una presentación que Gabriel hizo aen una coferencia de Lisp, y pueden
leerlo en la siguiente dirección: The Rise of Worse is Better
En el ensayo Richard Gabriel plantea que existe un estilo de diseño de software que el denomina el estilo MIT/Stanford
(es decir, un estilo académico) que básicamente tiene las siguientes características:
- Simplicidad: el diseño debe ser simple, tanto en implementación como interfaz. Es más importante que la interfaz sea simple que la implementación.
- Correctitud: el diseño debe ser correcto en todos los aspectos observables. La incorrectitud simplemente no está permitida.
- Consistencia: el diseño no puede ser inconsistente. Se permite que un diseño sea ligeramente menos simple y menos completo para evitar incosistencia. La consistencia es tan importante como la correctitud.
- Completitud: el diseñ debe cubrir tantas situaciones importantes como sea práctico. Todos los casos razonablemente esperados deben estar cubiertos. A la simplicidad no se permite reducir excesivamente la completitud.
Como ven estas son características que se consideran buenas y positivas.
Por otro lado, la filosofía Worse Is Better, Peor es mejor, o estilo New Jersey, en referencia a los Bell Labs, la cuna de C y Unix es ligeramente diferente en los siguientes aspectos:
- Simplicidad: el diseño debe ser simple,tanto en implementación como interfaz. Es más importante que la implementación sea simplea que la interfaz. La simpliciddad es la consideración más importante en el diseño.
- Correctitud: el diseño debe ser correcto en todos los aspectos observables. Es ligeramente mejor ser simple que correcto.
- Consistencia: el diseño no debe ser demasiado incosistente. La consistencia puede ser sacrificada por la simplicidad en algunos casos, pero es mejor eliminar partes del diseño que tienen que ver con circunstancias menos comunes que introducir complejidad en la implementación o inconsistencias.
- Completitud: el diseño debe cubrir tantas situaciones importantes como sea práctico. Todos los casos razonablemente esperados deben estar cubierntos. La completitud puede ser sacrificad en favor de cualquier otra cualidad.
De hecho, la completitud puede ser sacrificada siempre que la simplicidad de implementación esté amenazada. La consistencia puede ser sacrificada para alcanzar completitud si se mantiene la simplicidad, especialmente la inconsistencia de la interfaz no tiene valor.
Según Gabriel el enfoque “peor es mejor” produce software más exitoso, porque permite una difusión viral.
Si uno desarrolla con este principio parte por una base que es básicamente buena, que quizás implementa entre un 50% a un 80% de las funcionalidades requeridas, no tiene que tener todo implementado. Lo importante es liberar el producto como si fuera n virus, de modo que cuando este “virus” se difunde se generan presiones para mejorar y llevar la funcionalidad al 90%,
pero por otro lado los usuarios han sido condicionados a aceptar algo que no cumple todo lo esperado (“lo correcto”).
Con el software peor-es-mejor ocurre que “primero gana aceptación, luego condiciona a los usuarios es esperar menos, y finalmente será mejorado al punto que es casí lo correcto“. Hay un beneficio adicional del estilo New Jersey, y es que al no ser piezas de software complejas y monolíticas, los sistemas más grandes deben ser diseñados de modo que reusen componentes, lo que genera una tradición de integración.
Ustedes pueden optar por no seguir el camino de “peor es mejor”, pero se van a encontrar con 2 escenarios desagradables y frustrantes, en que tienen que definir un “gran sistema complejo”, que requiere elaborados diseños, complejas implementaciones, y probablemente una infraestructura especial para poder operar, o un escenario en que el diseño es eterno, los avances de implementación son siempre pequeños pasos en yna serie infinita que no termina nunca, y donde es imposible implementar “lo correcto”.
La lección es que a menudo no es deseable ir por “lo correcto”. Es mejor tener primero la mitad de lo que se necesita de modo que se difunda como un virus. Una vez que la gente se ha enganchado, tomarse el tiempo para mejorar y llegar al 90% de “lo correcto”.
Yo lo he hecho, he implementado servicios en que hemos partido con la mitad del desarrollo completado (o menos), pero el servicio ha ganado aceptación, y ha crecido y evolucionado con el uso y la retroalimentación de los usuarios. Al principio todo parece caótico, pero finalmente, llega un día en que el sol brilla y sin darte cuenta estás dando un servicio mucho mejor
de lo que pensaste, completamente automatizado y funcionando al 90% de lo que se suponía, pero te has dado cuenta que era eso o que necesitabas.
También he ido por el camino contrario, en que nos hemos tomado todo el tiempo del mundo para construir algo perfecto, un producto ideal, pero sin lograr nada, ni siquiera una venta.
En mi experiencia esta aproximación es mejor, y funciona, aunque, como todo en la vida, debe usarse con moderación.
Voy a aportar un extracto de un post de Chuidiang:
http://blog.chuidiang.com/2010/02/04/simplente-las-cosas-no-funcionan/
¿Qué diría Dijkstra?
Había un video de Dijkstra en que hablaba de esto, lamentablemente ha sido retirado de youtube (es una lástima, la mitad de los videos que he publicado ya no están).
El problema no es ese, dejame darte la respuesta de Jamie Zawinski:
“At the end of the day, ship the fucking thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products.”
La verdad es que lo más importate es liberar el producto, cumplir el plazo, el problema es que todos quieren liberar el mejor producto en el plazo, y eso es imposible, por eso que hay que tener una estrategia de administración de la evolución del software. Pero recuerda: “shitp the fucking thing”.
Es muy cierto! Entregar algo y entregarlo en el plazo convenido!
Por cierto, en Netscape Jamie y sus colegas decidieron reescribir todo el código fuente del navegador, pero finalmente esa decisión les valdría perder una posición valiosa en la contienda de los browsers. (uff! me siento viejo por estar hablando estas cosas!)
Joel Spolsky relataba algunas de estas cosas. http://www.joelonsoftware.com/items/2009/09/23.html (Ahí mismo comenta que Zawinski se encargó de popularizar el concepto de Worse is Better)
Pero es cierto: Entregar algo… es un deber. Y pucha que a veces cuesta.
Y un dato geek: Zawinski aparece en los créditos de Firefox. (escribir about:credits en el browser para una búsqueda más rápida)
Code Rush se llama el documental donde sale Zawinski y se muestra un poco acerca del desarrollo de Netscape Navigator. Recomendado para los que les llama la atención el tema.
http://en.wikipedia.org/wiki/Code_Rush
[...] Peor es mejor, aunque nos cueste aceptarlo. [...]
[...] A esta visión Licklider la llamaba Machine-Aided-Cognition (MAC), y se materializó en un proyecto en el MIT, el Proyecto MAC, que incluía el desarrollo de un sistema operativo que implementara el concepto de multitarea (multitasking), sistemas de archivos (filesystems), políticas de respaldo regulares, tiempo compartido, ambientes multi usuarios. De hecho, C y Unix fue una reacción de llevar a cabo de forma más simple este programa de Licklider (¿recuerdan peor es mejor?). [...]
[...] Peor es mejor, lo entregado normalmente es menos del 100% pero es usable. [...]
[...] produce tristeza. Se va uno de nuestros próceres, uno de los grandes, que cambió y estableció una forma de hacer ingeniería de software que tiene gran influencia hasta nuestros días. Ritchie y Thompson trabajando en [...]