Tuesday, August 26, 2008

Escolástica y Positivismo

A veces me sorprendo a mí mismo pensando que la evolución, tal como ha sido descripta por el genial Charles Darwin (y ampliada o explicada a la luz de la genética por el neodarwinismo), explica todo. Es decir, explica el funcionamiento de nuestro cerebro, explica la tendencia a la xenofobia, nuestra irracionalidad, y además nuestras cosas buenas, como el amor a nuestras crías.

Incluso más, como propone Stanislav Lem en 'Invencible', creo posible ámbitos de evolución no biológica: el capitalismo de mercado sobrevivió porque es el sistema mejor adaptado a la forma de ser de nosotros los humanos ( lo que no quiere decir que nos tengamos que quedar con su forma actual ), las ideas sobreviven por su adecuación a nuestra idiosincracia, y así unas cuantas cosas. Bueno, también lo propuso, creo que después, Richard Dawkins con sus memes

El mismo fenómeno de evolución se da con el software. El software que detestamos, ese que legamos y que queremos tirar, ha estado sobreviviendo al medio durante mucho tiempo. Eso no quiere decir que sea perfecto, la evolución no encuentra la mejor solución: encuentra una solución que permita que el organismo viva. Y eso ha hecho, ha sobrevivido. Con sus problemas, claro: no sabemos si un determinado código anda de casualidad o no, no nos animamos a tocarlo, es poco claro, si se hubiese pensado de una para el uso actual sería más claro, la tecnología es vieja, y unas cuantas cosas más. Pero aquí esta, y eso es una señal de que tiene algo de conocimiento valioso.

Por eso me irrito cuando se empieza un proyecto de reingeniería y todo el mundo está convencido que el nuevo software será mejor que el anterior, simplemente porque el anterior era una bosta. El anterior vivió muchos años, sobrevivió y se adaptó: el que no hicimos, todavía no demostró tanto mérito y no va ser fácil prepararlo para que lo haga, o, al menos, no lo haremos sin esfuerzo simplemente porque somos más vivos que los anteriores.

Por supuesto que parte de nuestros problemas para hacer algo bueno tiene que ver con las imperfecciones adaptativas del sistema anterior (que si no las tuviera, no lo estaríamos cambiando): no hay documentación, la tecnología es vieja y el código es poco claro, incluso subóptimo (a veces no es subóptimo, nos parece subóptimo porque lo evaluamos con poca información)

Y acá llegamos al punto donde quería llegar: la documentación. Estos sistemas legados no tienen documentación, o si la tienen, no podemos confiar en ella porque está desactualizada. Este es el estado general de las cosas, y creo que vale la pena preguntarse por qué con inexorable fatalidad la documentación falta o está desactualizada. Voy a hipotetizar algunos puntos:

  • La documentación se desactualiza porque no se percibe como útil. Y no se percibe como útil porque muchas veces no lo es: antes de documentar algo deberíamos preguntarnos si es más fácil leer la documentación que el código (he visto 'documentación' que ha sido el mismo programa hecho en pseudocódigo).
  • Aún cuando la documentación no esté desactualizada, siempre nos inunda la sospecha sobre su pertinencia al estado actual del sistema. Esto es, en parte, porque sabemos que la documentación tiende a desactualizarse, pero hay una causa subyacente ahí: cuando leemos documentación no tenemos más que el auxilio de la fe. Es decir, creemos que la documentación está actualizada porque alguien nos los aseguró, no porque podamos comprobarlo.

Diría que la misma presión del entorno que ha moldeado el sistema a su forma actual ha presionado para que la documentación se abandone. Bueno, y entonces qué? dejamos que el código se comente solo?. Yo creo que tenemos que adoptar una solución basada en criterios robados: es mejor almacenar experimentos que descripción de los resultados del experimento. Los físicos no lo pueden hacer: por ejemplo, el CERN no puede dejarnos jugar con su LHC un rato para ver lo que finalmente salga, pero nosotros tenemos una ventaja: podemos empaquetar el software junto con los experimentos que permitan ver si el mismo anda: test unitarios (como junit, nunit) y de regresión (como jmeter, selenium).

En mi opinión, los scripts de test son la única documentación que podremos utilizar sin temor a que esté desactualizada: el test se puede someter a prueba, se puede ejecutar, sirve para experimentar, mientras que la documentación se queda horriblemente corta al respecto. Incluso, me siento cómodo aplicando esta idea al desarrollo de requerimientos cuando lo que tenemos es un software que reconstruir: más que producir modelos en papel, preferiría producir scripts de test.

Lo anterior no es ni más ni menos que otro triunfo de la experimentación y el positivismo sobre la visión escolástica.

Friday, August 22, 2008

La importancia de la historia

Amo la frase "Dejó de andar. Y nosotros no tocamos nada" porque ha hecho que casi todo el mundo acepte la necesidad de la práctica de gestión de la configuración, cuyos beneficios van más allá de dar respuesta a esta frase. Además, claro, es una de las áreas del nivel 2 de CMMI, así que la tenemos que cumplir. La tenemos que cumplir, no se discute: no importa para qué, acá no se discute, la duda es la jactancia de los intelectuales (*): si lo dice CMMI hay que hacerlo.

Perfecto, lo hacemos. Y vamos a la definición de CMMI, que como todos sabemos explica, en un lenguaje accesible el significado de algunos términos criollos . (van solo los objetivos específicos, las prácticas y subprácticas se encuentran muy fácil por ahí)
  • Se establecen las lineas bases (cuidado!!! no es el concepto de linea base de ITIL que es más o menos el que todos entendemos por linea base) de los productos identificados.
  • Los cambios a los productos bajo gestión de la configuración son seguidos y controlados
  • La integridad de las lineas base se establece y mantiene
Clarísimo, no?. Bueno, no para nosotros. Como siempre la pregunta ante esto es... "y que hacemos?". Después de un tiempo de discutir, van unos revolucionarios conceptos a los que llegamos:
  • Tener versionado de código no es hacer gestión de la configuración: además tenemos que identificar los hitos o releases usando el versionador de una forma coherente y homogenea. Por ejemplo, teníamos que poder decir "volvamos a la versión que entregamos el viernes pasado". Pan comido, un sencillo mecanismo de tags y branches y listo.
  • El código fuente en el versionador no es suficiente: he visto que hay una tendencia a no versionar los objetos de la base de datos. A veces, con suerte, llegamos a los stored procedures, pero no versionar ni tablas ni índices es lo habitual: después de todo no son código fuente, no?. Yo me atrevo a proponer una tesis subversiva: si no hay coherencia entre el código y los objetos de la base, existe cierta posibilidad de que la release sea fallida.
  • Tenemos que saber que incluía cada revisión: que bugs estaban resueltos, cuales no, que funcionalidad implementada, que errores conocidos que íbamos a resolver en cada revisión. Para esto, necesitábamos algo más que un versionador de código. Había que adoptar un issue tracker e integrarlo con el versionador. Primero a mano, incluso ingresando la relación con los branches y tags a mano en el campo de descripción, después si se puede, se automatizará. ( Esto da pie a hablar del mejor argumento para impedir cualquier mejora: Pedir la perfección. Si uno no quiere hacer nada, puede atacar cualquier cosa que le propongan por no ser perfecta. Será motivo para otro post)
  • Si algo había cambiado, teníamos que saber cuando había cambiado, ser capaces de elucidar las diferencias con la versión anterior y en lo posible, tener una noción de por qué había cambiado y el impacto. Esto estaba bien, no? Al fin y al cabo ya teníamos el versionador de código. Bueno, tampoco: esto incluye a los planes, descripciones técnicas y funcionales, algún que otro modelo (no soy un gran fan de modelizar todo y no me asusta la documentación de diseño desactualizada después de que el proyecto ha terminado, me inclino más por el modelado ágil, tema para otro post). Además de incorporar todo esto al versionador, usamos el issue tracker para conocer el momento, motivo e impacto de los cambios
  • Deberíamos ser capaces de sacar una foto completa de una release. Esto es, no solo lo necesario para desplegar cualquier release por la que hayamos pasado (esto es código, scripts, objetos de la base, dtd, etc, etc, etc) sino especificaciones, reportes de bugs, scripts de pruebas y demás. De nuevo, no era difícil si subíamos todo (no solo el código) a un gestor de versiones y nos apoyábamos en el issue tracker.
La idea de tener aunque una descripción de los motivos del cambio levantó algunas discusiones sobre si era agil escribir el por qué de cada cambio importante (no, no hay una definición de importante. Aún no hemos encontrado un buen sustituto para la inteligencia, y espero que no aparezca). Mi postura fue que sí (o que si no era ágil, igual lo teníamos que hacer), basado en el siguiente argumento: si no está escrito no se puede revisar y aprender de ello (**), y necesitamos aprender de nuestra experiencia. Lo ágil, desde mi punto de vista, es no escribir más de lo necesario ( y cuanto es lo necesario? bueno, ver definición de importante más arriba).

Por supuesto que la frase "Dejó de andar. Y nosotros no tocamos nada" es cierta a veces (los tablespaces se llenan, los campos númericos se muestran cortos de un día para otro, bugs latentes salen a flote cuando se pasa determinada cantidad de información). También, como decía antes, la gestión de la configuración no solo da respuesta a esta frase. Incluso, el orden temporal no es necesariamente indicio de causalidad: que dos cosas hayan pasado en secuencia es prueba insuficiente de que la primera hay causado la segunda (o sea, la falacia post hoc ergo propter hoc. Motivo para otro post: falacias argumentativas)

No me propongo argumentar que la gestión de la configuración haya sido una respuesta a la costumbre de reportar errores usando esta frase, pero sí decir que donde han sufrido estas cosas es más fácil hacer ver la importancia de la gestión de la configuración.

Lo que me queda claro es que se agradece que haya gestión de la configuración cuando "dejó de andar. Y nosotros no tocamos nada". Primero, porque como diría el gran Dr. House, "todos mienten" (a propósito o sin querer, todos mienten). Y después, porque si estamos en alguno de los extraños casos donde efectivamente, ellos no tocaron nada, sirve corroborar tan sospechosa frase en los registros de gestión de configuración y comenzar a buscar campos que quedan chicos, problemas de memoria latentes que surgieron cuando se incrementó el volumen de transacciones, funcionalidad que hasta ese momento no había sido usada, un diseño deficiente de sincronización de transacciones que por obra y gracia del espíruto santo no había llegado a verse envuelto en la condición que lo hizo dispararse.


Ahá, muy interesante, pero con todo esto que nos explicaste vamos a cumplir con CMMI?. Sí?. Bueno, entonces hacelo y comprá el software que necesites, pero buscá el más barato.


Me encanta sentir que he cautivado a mi audiencia.


(*) Frase que ha pronunciado el filósofo Aldo Rico durante una rebelión carapintada. Algunos aseguran que fue Ortega y Gasset ( tan filósofo éste como el antes mentado) el autor original del a frase.
(**) No me imagino a un científico diciendo "Lo que ocurre es que yo no escribo papers porque hago ciencia ágil. Mejor que se siente el revisor al lado mío y le voy contando las ideas" (sí, como dije, considero la ciencia como paradigma de éxito en cuestiones intelectuales)

Tuesday, August 19, 2008

Estimo que...

Como parte de nuestro programa de mejora continua en el proceso de estimación, y dado que aún tenemos la hermosa sensación de desafío que produce el saber que existe una magnífica oportunidad de mejora en este tema (esta forma de decir 'quilombo a resolver' la aprendí en un curso de coaching), estuvimos pensando en que, si el proceso de estimación está tan verde, tal vez mereciera la pena invertir un par de horas en revisar los resultados.

Tuvimos que asumir que era (y es) nuestro punto más débil. Listo, agarramos la definición del proceso y le agregamos un paso más. Y salvado el hombre, hermanos!. Bueno, nada es tan simple: como hacíamos para que las revisiones tuvieran un mínimo de sentido crítico? (no es el sentido crítico una de las cosas que nos salgan naturalmente a los humanos, de hecho, la tendencia a buscar acuerdos es un sesgo cognitivo bien descripto. Motivo para otro post, o simplemenet podría recomendar un libro).

Entonces comenzamos a hacer un checklist de cuestiones a repasar cuando revisamos una estimación. El desafío y la oportunidad de mejora siguen ahí, de modo que la lista sigue abierta (como un recordatorio, esto lo aplicamos al método de estimación por descomposición). En estos momentos,la guía para el revisor se basa en un par de aspectos generales, que explico en los puntos siguientes.


Coherencia con los objetivos y requerimientos

La estimación debe mantener coherencia con los requerimientos no funcionales y los objetivos de rendimiento (*). Por incoherencia entendemos el incluir un objetivo o requerimiento y que las tareas para alcanzarlo o cumplirlo no tengan el foco (esto es, esfuerzo) necesario o directamente brillen por su ausencia.

Las formas más comunes de estas incoherencias son:
  • Mencionar en los objetivos de rendimiento que vamos a construir un producto (o un framework) a partir del proyecto, y las tareas de diseño no tienen mayor peso que de costumbre, o las tareas de documentación brillan por su ausencia.
  • Hablar de objetivos de performance del producto y no incluir tiempos para tareas de pruebas de carga, ni especialistas en el asunto.
  • Incluir cuestiones tecnicamente complicadas ( como por ejemplo, alta disponibilidad) y no estimar el esfuerzo adicional de diseño, y, fundamentalmente, prueba.
Por otra parte, el ciclo de vida seleccionado tiene incidencia en las estimaciones. El riesgo aquí es no estimar el esfuerzo de ciertos roles o actividades que el ciclo de vida que adoptamos incluye.


Identificación y estimación de tamaño de las tareas

Dijimos que adoptábamos un método de descomposición y no uno paramétrico como nuestro método principal porque no teníamos la suficiente madurez para un método paramétrico. Ahora, eso no implica que no podamos identificar algunos patrones de errores comunes en la identificación de tareas:
  • Las tareas o componentes identificados son lo suficientemente pequeños como para que su estimación sea posible?. Como regla general, establecimos que cualquier tarea o componente que insuma más de 150 horas es sospechoso de estar pobremente especificado y comprendido (otra regla general: no hay cosas que estén mal por definición, hay luces amarillas)
  • Se han identificado las oportunidades de reutilización?
  • Se distingue entre lo que se debe modificar, lo que se integra y se prueba en integración y lo que se construye desde cero?

Coherencia histórica

No tenemos una historia especialmente explotable, en un sistema de datamining que nos permita descubrir patrones de esfuerzo en proyectos pasados. Bueno, pero que no tengamos el non plus ultra de los repositorios no implica que no podamos ver como nos fue en el pasado ( en algún caso, junto con algún otro galeote hemos mirado un reporte en excel decidiendo por una descripción a que componente imputar las horas de un proyecto pasado... un trabajo apasionante cuando hay cientos de componentes y miles de entradas de cargas de horas ).

Y aquí la pregunta que terminamos haciendo: si para hacer un ABM tardaste miles de horas, por qué ahora suponés que lo vamos a hacer en veinte?. Resumiendo, este paso implica buscar componentes o tareas parecidos (al menos parecidos en una primera aproximación) en proyecto anteriores y justificar la diferencia si la hubiera. No es que siempre tengamos que tardar lo mismo, pero la diferencia debe tener una buena justificación.



Evaluación de la incidencia del entorno

Este paso, al igual que todos los otros, tiende a buscar incoherencias entre lo que ha escrito y especificado sobre proyecto y su circunstancia y lo que se supone que se hará en virtud de eso. Mencionar una característica del entorno, como por ejemplo un riesgo, y que no haya ninguna característica de la estimación o del plan de proyecto que responda a ésta es wishfull thinking, es creer en la utilidad de un conjuro. Por eso, lo que hacemos aquí es recorrer cada riesgo, cada característica del entorno (capacidad del equipo, motivación, estabilidad de los requerimientos), y preguntar y esto como influyó en la estimación? como hubieses estimado si esta hubiese sido diferente?


Pasos de la estimación

Por último, el aspecto formal, aunque debería haber sido el primero. Si el único repositorio de la estimación y sus motivos está en las conexiones neuronales de un iluminado, dificilmente podrá ser sometido a revisión. Entiendo que los genios tengan esa reticencia a la revisión, pero, queridos genios, entiendan que, nada personal, nosotros los mediocres, nos vemos forzados a actuar como si la regla fuera la mediocridad y no la genialidad, como si ustedes los genios fueran raras avis. No es que dudemos de vuestra genialidad. Y así hemos logrado estructurar al mundo: aún los premios nobeles escriben sus ideas para que los demás las puedan evaluar, juzgar, corregir, ampliar y si las encuentran útiles, usarlas de base para otras ideas. Incluso, para permitir que si los demás las encuentran terriblemente revolucionarias, les den el premio nobel.

Así que acá vamos con los pasos en cuestión:

  • Se han establecido, a grandes rasgos, los límites del alcance y los objetivos de rendimiento?
  • Se han indentificado los riesgos?
  • Se han identificado las tareas y componentes siguiendo la taxonomía que se usa habitualmente o si se la ha ampliado hubo una buena razón?

Resumiendo

Cuando uno tiene un proceso cuyos resultados no han destacado por su fiabilidad en el pasado (esos papers que hablan de cuanto se van de presupuesto y calendario tantos proyectos de software no nos hablan en tercera persona, deberíamos asumirlo ...), y no sabe muy bien como mejorarlo, lo mejor es aumentar las actividades de revisión y rezar porque la coherencia interna de un producto tenga alguna relación con su pertinencia y ajuste a la realidad.

Gran parte de lo que hicimos lo tomamos de un checklist del SEI para revisar estimaciones, como cabe esperar, bastante más formal y estructurado que el nuestro.




(*) Objetivos de rendimiento le llamamos en este barco de esclavos a aquello que se espera que nos aporte el proyecto además, claro, de su rentabilidad (la base para algún producto, conocimiento, entrar en una cuenta)

Monday, August 11, 2008

El punto singular

Recientemente el IEEE ha publicado un informe sobre la singularidad. Un tema interesante, sin dudas,y donde se juntan temas interesantes no centrales al trabajo diario de un galeote informático.

La singularidad tecnológica es el hipotético momento donde las computadoras se harán inteligentes y conscientes de sí mismas. Es un punto singular, un cambio cualitativo, donde, además, las máquinas inteligentes serán capaces de mejorar su propia inteligencia. Este, que es un concepto que ha estado dando vueltas en la cultura popular desde hace mucho tiempo, fue formalizado por Vernon Vinge, profesor de matemáticas, ciencias de la computación y escritor de ciencia ficción.

Se me ocurre divagar sobre la historia de la singularidad: tal vez se remonte a las primeras máquinas, que hacían algunas cosas que nosotros los humanos hacíamos, pero mucho más rápido y con asombrosa precisión. Como esas cosas que las máquinas hacían bien y rápido en algún momento se asociaron, o tal vez se asocian aún, a la inteligencia (hacer cuentas rapidamente, por ejemplo), temimos que en algún momento nos saquen la misma ventaja en otro montón de cosas asociadas a la inteligencia que todavía no hacían (y todavía no hacen o no hacen bien), y los humanos sí.

Vinge, en su paper de 1993, sostenía que la singularidad se daría entre 2005 y 2030. Y que esta, tomaría alguna de las siguientes formas:
  • Computadoras que alcancen la conciencia y sean mucho más inteligentes que los seres humanos. Es decir, que su creciente capacidad de cálculo alcance la del cerebro humano, y a partir de ahí, pueda entenderse a sí misma y mejorarse.
  • Redes de computadoras que alcancen la conciencia (sep, la Skynet deTerminator). Lo mismo que antes, pero en lugar de una sola computadora con muchos procesadores, algo así como un MPP.
  • Interfaces humanas que integren humanos y máquinas: un 'coprocesador' para el cerebro humano. Algo que, de alguna manera se enchufe a tu cerebro y sea particularmente bueno para cosas que tu cerebro es lento: por ejemplo, para hacer cálculos rápidos. En realidad, algo se ha avanzado en este campo, como por ejemplo los implantes cocleares que ayudan a recuperar la capacidad auditiva. De todas maneras, estos implantes no han alcanzado aún ni por lejos una capacidad comparable a la del oido, en parte porque no sabemos muy bien como conectarlos.
  • Algún mecanismo que, por medio de la manipulación biológica, pueda incrementar la inteligencia.. Esta es mi preferida, por lejos: asume que de alguna manera que no conocemos mejoraremos algo que no entendemos del todo. Para aplaudir.

Los argumentos que Vinge da para apoyar la singularidad se basan, basicamente, en la creciente automatización, en la velocidad de propagación de las ideas y en la ley de Moore: en algún momento, conjetura, la capacidad de proceso de una computadora superará a la capacidad del proceso del cerebro humano.

Mantengo cierto escepticismo sobre las aseveraciones de Vinge. Para comenzar, no sabemos, y no define él, que cosa es la inteligencia y la concienca. Más aún, se ha argumentado por ahí, de una forma no facilmente refutable, que nuestro razonamiento va más allá de lo computable: no es que haya algo inmaterial, sino que nuestros sistemas formales no son lo suficientemente abarcativos para describir el funcionamiento de nuestro cerebro. Como decía, no es una invocación a lo religioso o espiritual, sino una propuesta de que existen mecanismos que nuestros sistemas formalizados no pueden describir.

Otro punto débil es la fe algo exagerada en la ley de Moore: nada dice que vaya a seguir indefinidamente, y es interesante ver que no hay especialistas en el cerebro entusiasmadísimos con la singularidad, la mayoría son matemáticos o gente de ciencias de la computación. Es probable que se deba a que los especialistas en el cerebro tengan una idea del tamaño de nuestra ignorancia en el asunto y no vean demasiadas razones para creer que estamos cerca de entender como funciona el cerebro.

De acuerdo a lo que sostienen los singularistas, las neuronas son como transistores, que absorben, procesan y reemiten pulsos eléctricos. Un detalle no menor es que un transistor se conecta a otros dos transistores y cada neurona se conecta a otras diez mil. Estos pulsos eléctricos, según los singularistas, servirían como la unidad de información tanto del cerebro, como de las computadoras. Como es que esos mecanismos se transforman en recuerdos, gustos, emociones, razonamientos nadie lo sabe, y no hay mayores elementos para suponer que se parezca a un algoritmo.

Es claro que el cerebro es una máquina, lo que es menos claro es que clase de máquina es.

Más aún, la codificación del cerebro, es decir, qué lleva de esos pulsos a nuestra conciencia es un campo de estudio abierto. En algún momento se descubrió que el cerebro usa un código de cantidad (se interpreta un concepto en virtud de cuantas neuronas estén activadas en un determinado momento). Luego se descubrió un código de temporalidad: no solo depende la cantidad, sino el órden de activación (el código de cantidad asigna a 101 y a 110 el mismo significado, pero el temporal no), y se sospecha que puede depender también del ritmo de activación: el tiempo que media entre la activación de las neuronas.

Se nota en Spectrum menciona que el código temporal nos acercaría al límite teórico de Shannon.

Esta mayor cantidad de posibilidades de representación hacen que las unidades de información que puede manejar el cerebro sean órdenes de magnitudes superiores a las que puede manejar una computadora, aún con cientos de microprocesadores. Aún cuando no sea cierto el argumento cualitativo (el que sostenía Penrose, que la conciencia no es algorítmica), el argumento cuantitativo es claro: no estamos cerca aún de siquiera saber cuantas unidades de información maneja nuestro cerebro.

Por último, es interesante ver que opinan luminarias sobre la singularidad.

A mí me parece que la singularidad no es una gran idea por sí misma, pero tiene la virtud de hacernos pensar en temas muy interesantes.

Tuesday, August 5, 2008

Computer Disease

Well, Mr. Frankel, who started this program, began to suffer from the computer disease that anybody who works with computers now knows about. It's a very serious disease and it interferes completely with the work. The trouble with computers is you play with them. They are so wonderful. You have these switches - if it's an even number you do this, if it's an odd number you do that - and pretty soon you can do more and more elaborate things if you are clever enough, on one machine.

And so after a while the whole system broke down. Frankel wasn't paying any attention; he wasn't supervising anybody. The system was going very, very slowly - while he was sitting in a room figuring out how to make one tabulator automatically print arctangent X, and then it would start and it would print columns and then bitsi, bitsi, bitsi, and calculate the arc-tangent automatically by integrating as it went along and make a whole table in one operation."

Los Alamos from Below. Reminiscenes 1943-1945. Richard Feynman



El fragmento que abre este post está tomado de los recuerdos de Richard Feynman de su paso por el
Proyecto Manhattan. Mr Frankel, Stanley Frankel, era un físico que integró el equipo del proyecto, al igual que Feynman (como señala la página de wikipedia, tuvo problemas con la caza de brujas de los 50, que también le generó problemas a Oppenheimer: curiosa forma de tratar a los héroes de guerra). El buen Stanley introdujo en el Proyecto Manhattan el uso de las computadoras para calcular, entre otras cosas, los resultados de la explosión de la bomba, que eran muy difíciles de calcular con las máquinas mecánicas Marchant.

Frankel, como cuenta Feynman, sucumbió a la misma enfermedad que nosotros, los que nos dedicamos a esto: el encanto del jugueteo, la atracción lúdica de la computadora. El placer de enfrentarnos a retos difíciles, inútiles, y agradabilísimos. Sigue Feynman:


Absolutely useless. We had tables of arc-tangents. But if you've ever worked with computers, you understand the disease -- the delight in being able to see how much you can do. But he got the disease for the first time, the poor fellow who invented the thing.


Yo tiendo a asociar esta la 'enfermedad de la computadora' con nuestra insoslayable tendencia a lo que Brooks llama 'gold plating' (la tendencia a perderse en los detalles, a agregar más de lo necesario, a sacarle punta al lapiz a niveles atómicos). El gold plating puede ser, o mejor, seguramente es, uno de los ingredientes para la catástrofe en los proyectos. Pero para controlarlo, pienso, debemos entender de donde viene: es la expresión de la enfermedad que inauguró Frankel.



Monday, August 4, 2008

Estimaciones y futurología

Either estimate from a spec of provide data on prior work and let the customer judge the range. If the customers then wanted detailed estimates, they would have to pay for the specification and design work required to make them. Unfortunately, it will take the software community some time to build the skills and credibility to work in this way. Until we do, however, we will continue to have estimating and planning problems

Watts Humphrey, Estimating with objetcs.


Con los otros galeotes estuvimos discutiendo el tema de las estimaciones estos últimos días. El post anterior es un poco deudor de esas discusiones. Como toda discusión estuvo motivada por un problema, y un problema grave, o como se diría ahora, en una enorme oportunidad de mejora: la oportunidad de mejorar las estimaciones de nuestros trabajos y mejorar, a niveles aceptables, acota la desagradable voz que escucho y de la que ya hablé, la planificación de nuestros proyectos.

Fatigando la ignorancia, creo haber llegado a la conclusión de que todos los métodos de estimación se basan en los siguientes pasos:
1. Una descripción del objetivo (en términos propios y de su contexto, que el sistema es él y su circunstancia)
2. Una descripción de como implementar o llegar al objetivo
3. Una descripción de tamaño de los componentes o pasos para llegar al objetivo
4. Una relación entre el tamaño y esfuerzo

PROBE, COCOMO II, Puntos de Función, historias del usuario, todos, de una manera u otra siguen estos mismos pasos.

Primero, nos hacemos una idea del problema a solucionar, y una descripción somera de las capacidades del software que debemos construir. El desarrollo de requerimientos no es mi tema, por lo que hablaré del asunto aquí.

Luego, hacemos un diseño conceptual. Decidimos que objetos o componentes integrarán las solución, cuales reutilizaremos (con o sin modificaciones), y que construiremos desde cero. De acá sacamos una lista de componentes, objetos, tablas, archivos, interfaces, y demás que debemos construir.

Luego hacemos una una estimación del tamaño. Es difícil argumentar que el tamaño de un software se mide en el tiempo que se tarda en desarrollarlo, casi tanto como es difícil argumentar que la distancia entre dos ciudadades se mide por el tiempo que yo tardo en llegar desde una a la otra: el tamaño es una medida objetiva relacionada, sí, con el esfuerzo de desarrollo, pero en definitiva distinta. Si la analogía entre distancia y tiempo de viaje no resulta adecuada, se puede pensar en otra: masa y peso. La masa es la cantidad de materia (el tamaño en nuestro software), independiente de la gravedad (la performance del equipo), mientras que el peso es una medida que tiene en cuenta la masa y la gravedad (el tiempo que tardamos en hacerlo)

Una buena medida, según mucha gente son las líneas de código estandarizadas. El problema está resuelto: estimamos la cantidad de lineas de código que tendrá el software que implementará unos requerimientos poco claros con un diseño aún no decidido y listo, no?. Bueno, no. Entre otras cosas por lo ridículo que sería sostener que para calcular el tiempo que tardaremos en desarrollar algo, primero debemos saber cuantas líneas de código tiene ese algo, Humphrey propone objetos como 'apoderados' o 'representantes' de las líneas de código (proxies, los llama).

Una disgresión con respecto a las lineas de código: es probable que haya una correlación entre las líneas de código escritas y el esfuerzo insumido, y tal vez sea posible defender su utilidad como métrica post-mortem de los proyectos,para comparar la performance de proyectos entre sí, si mantenemos igual las demás variables (lenguajes, entornos operativos, frameworks, y alguna más que ahora se me escapa). Sospecho, de todas maneras, que esta métrica post-mortem era más certera antes de los lenguajes con introspección.

Es claro como la estimación de tamaño ocurre si usamos puntos de función o puntos de caso de uso, pero diría que aún las historias del usuario tienen una etapa de estimación de tamaño: Kent Beck propone en Planning Extreme Programming, basar la estimación de historias de usuario en historias de usuario que hayamos implementado en el pasado, que sería algo así como lo que hicimos con mis compañeros galeotes, pero intuitivamente: pensar el tamaño de un componente, o de una historia de usuario, en términos de historias ya realizados. Esto es, decir, por ejemplo que una historia X que acabamos de recibir tiene un tamaño que cumple cierta relación con el tamaño de una historia anterior. Si bien se mira, las medidas no son más que eso: la relación entre una magnitud actual y una magnitud elegida por algún tipo de convención (cuando decimos que algo mide un metro treinta centímetros, decimos que se trata de una distancia igual a la distancia recorrida por la luz en el vacío durante algo así como 4,33nano segundos )

En el último paso, relacionamos el tamaño con el esfuerzo necesario, con una medida que podemos llamar de varias maneras, pero que en definitiva no es sino una expresión de nuestra performance de desarrollo. Acá, como en el resto, la estadística es fundamental y depende de cuan bien hayamos medido nuestra experiencia.

En definitiva, la clave para mejorar está en capitalizar nuestra experiencia, de una manera sistemática que nos sirva para formar juicios en el futuro, como en cualquier práctica que tenga que ver con la tecnología y la ingeniería.