viernes, 26 de noviembre de 2010

Lo importante primero

Hace unos años, 40 para ser precisos, un hombre no siguió esta regla tan simple y aún hoy seguimos pagando las consecuencias.

El hombre se llamaba Winston Royce, era un "computer scientist" (por no decirle computador científico que suena feo) y un día publicó un paper sobre administración de proyectos de software (lo pueden leer acá), en ese documento describe un modelo de desarrollo y lo maravilloso que es.

Alguien en el departamento de defensa (DoD) de estados unidos leyó el paper, quedó convencido de las bondades del modelo y decidió implementarlo como estándar para todos los desarrollos del departamento. Imagínense lo grosso que debería ser lo que proponía Royce, tan grosso que aún hoy se sigue usando (casi nada, es cierto, pero lo siguen dando en la facultad!!!), es lo que se conoce como modelo en cascada.

Por si no notaron la ironía les cuento que ese modelo es nefasto, básicamente dice "al hacer un programa lo importante es la documentación, el código es una pelotudez que la puede hacer cualquiera", para hacer una analogía es como si te dijera que lo más importante de una casa es el plano, total los ladrillos los pone cualquiera. Así es como los programadores quedamos relegados a ser unos meros obreros de cuarta y durante muchos años sufrimos las consecuencias de eso.

El problema que originó todo esto es que en el paper del que venía hablando, el muchacho este, Royce, plantea ese modelo como grandioso ¡pero solo en las primeras páginas! después le dedica una decena de carillas a defenestrarlo y mostrar sus falencias para terminar proponiendo una versión mucho mejor. Claro está que el empleado del DoD jamás llegó a esa página, se quedó en el segundo diagrama y dejó de leer ahí.

Corregir ese "error" llevó casi 30 años. Si Royce hubiera estructurado su artículo de otra manera la historia del desarrollo de software sería muy distinta, creo.

Si les interesa el asunto pueden pasar por acá y leer lo que inspiró este post.

16 comentarios:

Gurisa dijo...

Hay grandes empresas de TIC's que todavía creen que es importante documentar. Les lleva preciados minutos de productividad, pero bueno, no es productividad y eficiencia lo que quiere el cliente, si no que las cosas estén hechas, no?
:P

True story...

Uninvited dijo...

Por eso si me preguntan, antes que programador soy sistemista... jejejeje

El Gaucho Santillán dijo...

Entonces a este, lo pongo en la lista con Menem. para fusilarlo.

Cavallo tambien està.

Con razòn sacaron el viejo y querido "Basic", que yo tan buen manejaba!!


Saludos indignados.

Epístola Gutierrez dijo...

Si bien no soy una entendida en la matria, me queda claro que este muchacho hizo malo las cosas y hubo quienes lo apoyaron en su error.
esto sucede en varias áreas y las consecuencias se sufren por mucho tiempo.
En cuanto a la desvalorización de los programadores, propongo que hagan huelga, a ver qué hacen sin ustedes, eh!
Un beso.

Andre dijo...

O soy muy pajera y no presté atención al leer, o realmente nunca voy a entender nada de estas cosas de software.
Igual quería pasar a saludar, a usted y a la barba.
Beso!

Nick dijo...

Guri, me consta, lamentáblemente me consta, esa fue una de las razones de mi partida del trabajo anterior.

Unin, vas mal, estamos logrando revertir la tendencia y logrando que arquitecto signifique ladri jajaj

Gaucho, si hablás del chabón del DoD, sí, mandalo a la lista, el único problema de Royce fue no aclarar en la primera página.

Epístola, no no, el tipo mostró el modelo como un mal ejemplo, el paper dice algo así como "no hagas todo esto" el error fue poner esa frase al final.

Más allá de eso, efectivamente, no reconocer o corregir un error de manera temprana lleva a situaciones desastrozas.

Ya nos vamos a organizar y van a ver...

Andre, no sé, yo no hablé de programación en (casi) ningún momento. Igual me parece muy bien que no entiendas de esas cosas, si las entendés terminás mal :)

Saludos recibidos! Beso

Epístola Gutierrez dijo...

Bueno, entonces hizo mal las cosas. Sea cual fuere el error.
Como si yo le diera la receta poniendo los huevos enteros en el microondas y en la última frase le digo que eso no se hace porque van a reventar. Es eso?
Será que no entiendo nada si los ejemplos no me son cotidianos?
Gracias por la paciencia.
Un beso.

Nick dijo...

mmm más o menos, en realidad es como si la receta dijera (o dijese) "podés hacer esto poniendo los huevos enteros en el microondas pero no lo recomiendo porque se pueden reventar" el tipo del DoD solo leyó hasta la parte del microondas y salió corriendo a la cocina.

Estoy de acuerdo en que estuvo mal planteado el paper, lo hubiera escrito "al derecho" y todos seríamos más felices, pero el que lo leyó por la mitad también tiene una parte de culpa.

Beso.

P.S.: paciencia sobra.

no importa quien soy dijo...

Aguante los programadores!!!!!

Genios!!!!!

Que sería de nosotros sin Ustedes!

Abrazo.

Pd: Royce, se donde vivis, te voy a ir a buscar... y de paso me quedo allaaaaaaaaaaaaaaaaaaaaaaaa

Nick dijo...

Ojo NIQS porque Royce vive con el barba, el barba posta, no yo que apenas soy un barbado.

Abrazo

Halle dijo...

Lamento estar en contra tuyo, pero si yo puedo codear, el código lo hace cualquiera che. :P

(Mentira, tengo promedio 8 y algo en las materias de programación de la facu, shhh)

Nick dijo...

Ojo Halle que eso no quiere decir que no haya ladrones dando vueltas, mirame a mi sino, el tema es no desvalorizar por culpa de esos ladrones.

Abrazo

zort dijo...

Gurisa, Nick, tampoco hay que ir al extremo de decir que documentar no sirve para nada!
Nunca les toco agarrar un pedazo de código que alguien hizo hace un par de anios y tener que perder un montón tiempo intentando comprender que es lo que hizo y porque? Un "Pablito estuvo aqui" puede llegar a resultar muy util, aunque sea para ir a buscar a Pablito.

Nick dijo...

Por supuesto que documentar es importante, pero todo en su medida, me resulta mucho más útil un buen comentario que un diagrama de clases. Estoy totalmente de acuerdo con los escraches :)

Layla dijo...

Nick,
En un esfuerzo sideral por tratar de entender de que se trata todo esto recorrí cada link para frustrarme un poquito más, pese a mis limitaciones me animé a postear revelando esta incapacidad de comprender ciertos temas. A mí, el efecto cascada me lo enseñaron en la facultad en una clase de economía, con un dibujito de copas que se van llenando desde la cúspide, de esa manera se trataba de explicar y/o justificar que aquello que les sobre a los de arriba indefectiblemente iba a parar a los de abajo y de allí el mensaje siniestro (de la cascada o del profesor) que mejor que a los de arriba les sobre y se llenen porque sino a los de abajo no le iba a caer ni gota...
By the Way,
Para mí que este Royce lleyó (o en su defecto vió la película) de Sherlock Holmes y aplicó el arte de razonar a la inversa...
By the Way II,
Y en esa "inversitud" lo que debería haber salido bien, le salió como el traste...
By the Way III,
Dejaré de criticar a una amiga que agarra los libros en Yenny y les lee el final...

Nick dijo...

Uhhh la ley del derrame, grandes valores de la economía argentina...

En este caso es parecido, esta cascada dice "No hagas nada hasta que no termine el de arriba".

BTW I y II, es una posibilidad, me parece que para la peli no llegó pero los libros seguro los agarró.

BTW III, mmm no sé, no sé, yo prefiero la intriga y en todo caso releer.