Las optimizaciones prematuras
Como dijo Tony Hoare (citado por Knuth en uno de sus biblias):
El 97% del tiempo debemos olvidarnos de las pequeñas eficiencias: la optimización prematura es la raíz de todos los males.
Pues eso, una frase que siempre recuerdo y la tengo grabada (lo pueden testificar mis alumnos… los que me escuchan 
). Me la recordó el apunte en O’Reilly Radar sobre AJAX y Java, que además asegura que también se aplica al diseño:
Es imposible tener una idea precisa de lo que le gustará hacer a la gente hasta que empiezan a hacerlo, así a veces es mejor alimentar al mercado con un hack que permita empezar a usarlo, y luego completarlo a medida que observas qué hace la gente con él.
También dice más o menos lo mismo Paul Graham en Las 10 lecciones más duras que debe aprender una startup.
Más allá de ese lenguaje tan desagradable (para mí) donde se habla demasiado de “mercado” y “consumidores”, estoy totalmente de acuerdo. Por eso me ponen nervioso esos grandes “diseños” y “desarrollos” que tardan meses en hacer algo mínimamente funcional y estable, y luego pueden llevarse chascos, como que a la gente no le interesa para nada. Se ha visto mucho de eso en el “1.0″, especialmente en agencias de viajes, bancos, iberias y administraciones –grandes organizaciones en general–. Parece que cuesta mucho hacerse a la idea de “desarrollo ligeros”, “escuchar a los usuarios”, y release often. La “ingeniería” ya no es lo que era.
Joder, que serio me ha quedado el párrafo anterior. Pero es parte de mi preparación para empezar mi nueva carrera de consultor y conferenciante de “Web 2.0″, ya tengo un traje BBB 
Nota: Siguiendo con mi “costumbre” de críticas crípticas como dicen algunos (y yo que pensaba que era demasiado directo y explícito), no puedo evitar una más como apostilla-propina (hay que salvar electrones).
Si algunos bloggers leyeran y pensaran lo que ponen en su blog además de hacer el copy&paste del texto PAUSE se darían cuenta que se están disparando a los pies ellos mismos STOP Pero pensar y ser coherentes es demasiado pedir STOP Iba a parafrasear a Sabina PAUSE pero como soy un poco más educado diré sólo que la evidencia demuestra que para tener un blog con muchas visitas no hace falta mucho seso STOP La existencia de este blog es una evidencia más FULL STOP
Vaja, això de no optimitzar ens ho hauriem de dir des del primer dia de carrega. En realitat encara no ho he sentit per cap dels professors.
També s’ha de recordar que un dels punts forts del model de desenvolupament actual de programari lliure passa per ací: són directament els usuaris els que demanen què voldrien i que no. I com que moltes vegades els mateixos desenvolupadors són els usuaris, doncs qui millor?
Comment by paurullan — Wednesday 24/5/2006 @ 6:40
¿Haces referencia a Joaquín Sabina? ¿Que dijo?
Comment by TrickyDicky — Wednesday 24/5/2006 @ 6:46
>Por eso me ponen nervioso esos grandes “diseños” y “desarrollos” que tardan meses en hacer algo mínimamente funcional y estable,
Bueno, no siempre las cosas son tan sencillitas como el Meneame.
Existen proyectos para los que son apropiadas las metodologías ágiles, y otros para los que no. Soy de la opinión que cada vez se irán viendo más desarrollos ágiles por que me parece que se están ganando un hueco.
Pero, también es verdad que me parece que centran más el desarrollo en algo menos ingenieril, y más social. ¿es esto bueno o malo? NPI.
Comment by Joserra — Wednesday 24/5/2006 @ 7:47
Hola:
Yo cada vez soy más partidario de las metodologías ágiles. Las otras metodologías más pesadas veo que son bastante engorrosas y que al final no dan demasiados buenos resultados.
Las metodologías ágiles en principio parecen adecuadas para proyectos no muy grandes, pero supongo que se puede aplicar la máxima de “divide y vencerás”. Si el proyecto es muy grande y tiene mucha gente, seguramente se puede dividir en pequeños subproyectos, módulos o como quiera llamarse y aplicar metodologías ágiles a cada uno de ellos.
Sed buenos.
Comment by chuidiang — Wednesday 24/5/2006 @ 8:15
> Bueno, no siempre las cosas son tan sencillitas como el Meneame.
No lo afirmé en ningún momento, pero ¿quién te ha dicho que el menéame es “sencillito”? Con más de 15.000 líneas de código desarrollado en php, JS, algunas otras en perl, base de datos con tablas de más de un millón de filas y más de 250.000 script ejecutados por día, todo eso en meses. ¿Todavía te parece “sencillito”? No creo que encuentres muchos con estos números y evolución en el entorno.
Pero no se trata de que las “especificaciones” sean sencillas o complejas, sino en el “bloating” que se suele meter en el desarrollo de web, sobre todo de grandes organizaciones. Hacen todos unos estudios y análisis, se pasan meses o años desarrollándolos y luego la gente no usa ni le interesa la inmensa mayoría de lo que hay. O lo que le interesa lo cambiaría.
¿Conoces algún web que no pueda ser lanzado por fases más sencillas y adaptable el propio uso? No creo que puedas encontrarlo.
Comment by gallir — Wednesday 24/5/2006 @ 9:19
El otro día asistí a una conferencia de RoR (Ruby on Rails) en la UB y me di cuenta de por qué el libro más leído sobre el tema se llama “Agile Development with Rails”, puedes tener un programita web pequeño pero funcional en una horita y puedes ir cambiando el diseño del modelo “on the fly” y ver los cambios sin reiniciar nada, y lleva muchas golosinas
A ver si ese veranito le pego un mordisco porque aún no he programado ni una línea de código en Ruby.
Comment by Tribe — Wednesday 24/5/2006 @ 9:40
Bueno, Ricardo, no te molestes, no quería menospreciar Meneame…
>No creo que encuentres muchos con estos números y evolución en el entorno.
¿entorno te refieres a la movida web2.0? Ah, claro que no. Pero si hablamos de aplicaciones web para bancos, empresas de servicios, intranets de empresas…
Una cosa es que la aplicación que deciden construir luego no interese a los usuarios, y otra cosa es que lo que se decide construir sea complejo, grande, sencillo o simple.
>¿Conoces algún web que no pueda ser lanzado por fases más sencillas y adaptable el propio uso? No creo que puedas encontrarlo.
Claro que cualquier aplicación puede irse desarrollando en fases, obviamente. Y esto es especialmente útil a las que dependen de las reacciones de los usuarios. Se sacan versiones petas (sic) y se toma el pulso de los usuarios.
Otras aplicaciones no tiene tanto sentido. Los que desarrollan un sistema de un banco o de información jurídica, ya saben qué funcionalidades deben dar desde el principio. Sí, claro, las desarrollarán por módulos, pero no siendo tan importante el usuario para la captura de requisitos a lo mejor no tiene sentido una metodología agil. (Y hablo de proyectos que requieren de un año de trabajo de unas cuantas personas, y no por que tengan problemas, si no por la complejidad, por eso te decía que meneame, pues bueno,… tampoco es un sistema complejo)
En fin, no sé ni que estoy discutiendo.
Una opinión si me interesaría tuya ;). ¿crees que los métodos ágiles son más “ingenieriles” que los tradicionales (p.ej. metodología metrica2) o por el contrario se pierde esa aura de ingeniería que se le quiere dar al desarrollo informático?
Comment by Joserra — Wednesday 24/5/2006 @ 9:43
> Bueno, Ricardo, no te molestes, no quería menospreciar Meneame…
Para nada, sólo que hay muchos tipos de “complejidades”, el tema es complejo
> Los que desarrollan un sistema de un banco o de información jurídica, ya saben qué funcionalidades deben dar desde el principio.
Es lo que estoy convencido que no. No es así. Los diseñadores de un sistema _nunca_ pueden saber bien qué es lo que va a usar la gente, y cómo lo va a usar. Por ejemplo los dos bancos que uso vía internet, tienen tantas cosas y sólo uso dos opciones, y de esas dos le encuentro muchas mejoras posibles.
> ¿crees que los métodos ágiles son más “ingenieriles” que los tradicionales (p.ej. metodología metrica2)
Diría que al menos son “equivalentes”, y además que las tradicionales pesadas, especialmente las métricas, no se adaptan para nada a cómo deben ser las aplicaciones web. Se sigue con la idea de desarrollar monstruos estáticos muy difíciles de adaptar y mejorar.
> o por el contrario se pierde esa aura de ingeniería que se le quiere dar al desarrollo informático?
Más que perder el aura veo que se pierde el contacto con lo que el usuario realmente desea y necesita. Es como una especie de paja mental: mostremos todo lo que somos capaz de pensar e implementar y así alucinar a los demás.
Comment by gallir — Wednesday 24/5/2006 @ 9:53
Yo he pensado en ser la primera persona que aplique el “desarrollo ligero” a la construccion de submarinos.
Cuando lleve una semana trabajando, pongo el cacharro en el agua, y si se hunde es que vamos por buen camino
Comment by Pacopepe — Wednesday 24/5/2006 @ 12:20
software (y web) != elementos físicos
así como
ingeniería software != ingeniería tradicional
porque
complejidad software != complejidad construcciones físicas
entre otras cosas porque no se está sujeto a leyes físicas estrictas y restrictivas, ni se tiene la misma cantidad de años de experiencia.
Comment by gallir — Wednesday 24/5/2006 @ 12:24
Discusión interesante! Ahí va mi granito de arena.
Actualmente cualquier organización cambia sus procesos muy a menudo. Si embargo los proyectos hechos a la “antigua” usanza, tras meses de análisis, mas meses de desarrollo, etc., acaban entregando aplicaciones (web o no) que ya no responden a los procesos de la organización.
Las metodologías ágiles, los frameworks de desarrollo rápido (ruby on rails es un ejemplo, pero los hay también en java) permiten hacer desarrollos cortos, rápidos e iterativos, para irse adaptando a los cambios organizativos y descubrir que y como utilizan los usuarios. Aunque esto es casi una utopía. Conozco poquísimas empresas que hagan así grandes proyectos.
Comment by Mor — Wednesday 24/5/2006 @ 22:05
Y una matización anterior a comenzar el desarrollo, qué sucede cuando tienes que desarrollar una herramienta para la que hay en el mercado mil mejores (y a un precio muy económico) o incluso otras mil con licencia GPL y que puedes personalizar a tu gusto; y no, el comité ha decidido que hay que programarla desde cero, y dentro de dos años cuando terminemos se habrá quedado antigua.
Y luego cuando necesitamos algo específico van y lo compran en lugar de programarlo a medida.
Y no entro en las grandes consultoras que todo lo hacen con Excel y Word, abres un documento de un proyecto y aquello parece… lleno de modificaciones, cambios… y dentro de dos años cuando terminen el mamotreto se ha quedado viejo.
Comment by tendero_digital — Thursday 25/5/2006 @ 7:27
Yo creo que las metodologías ágiles son para lo que son y que dependen del contexto donde se apliquen. Si mi banco utilizara exclusivamente metodologías ágiles para construir la extranet de usuario, empezaría a preocuparme. Claro que no es así, pero en cierto modo mucha de la carga pesada de la aplicación la tienen implementada, así que veo como una mejora que implementen otros módulos -interesantes, necesarios, etc..- como clientes de la aplicación principal que no precisen de meses de reuniones.
Como comentaban por ahí, también pienso que las metodologías ágiles no implican por ningún lado simplicidad. Suelo recordar este artículo cada vez que oigo un comentario parecido:
http://www.joelonsoftware.com/articles/NothingIsSimple.html
Comment by Pau Iglesias — Thursday 25/5/2006 @ 23:40