Cada uno de estos periodos de tiempo, en los que aumentamos la funcionalidad del sistema, recibe el nombre de sprint, y las reuniones periódicas reciben el nombre de sprint review meetings, aunque nosotros las llamamos demos.

Detrás de cada demo, los miembros del equipo y el Scrum Master (o sea, el que suscribe) llevamos a cabo otra reunión en la que analizamos qué fue lo que hicimos bien (y alegrarnos), qué fue lo que no se hizo tan bien (observad el sutil efecto impersonal) y qué medidas vamos a tomar para corregirlas. A estas reuniones se les llama sprint retrospective meeting.

¿Bueno, pues hoy hemos tenido nuestro segundo retrospective. Y hemos salido muy contentos. Por lo pronto, es toda una novedad que echemos la vista atrás para poder analizar qué se hace mal y poner remedio cada tres semanas, que es nuestra longitud de sprint. Pero hacerlo dos veces, es un milagro . Respecto al anterior retrospective, he notado que somos mucho más equipo, que nos conocemos mejor. Nos enriquecemos mutuamente con el intercambio de ideas, de sugerencias, de puntos de vista y de reflexiones. Para decidir qué medidas correctoras íbamos a aplicar durante nuestro tercer sprint, hemos escrito en PostIts de los grandes cada uno de los aspectos negativos. En una sesión de brainstorming, hemos ido apuntando en cada PostIt las posibles soluciones, mientras que íbamos agrupando las que estaban relacionadas (pruebas, estimación, método…). Luego, cada uno ha dado sus nominaciones: tres votos a repartir entre un máximo de tres aspectos negativos a resolver.

Pero ha sido la agrupación de los PostIts y la lista de los nominados lo que me ha hecho pensar. Le hemos dado muchísima más importancia a los temas relacionados con las pruebas que con la estimación. Por lo visto, preferimos asegurar la calidad del código frente a la calidad de la estimación. También es verdad que en la primera retrospective ya se acometió una mejora sustancial: las estimaciones ahora se hacen mucho más precisas, descomponiendo inicialmente las historias del usuario (las características que le aportan valor) en tareas más pequeñas antes de empezar el sprint, y no después. Y lo que ya me ha dejado descolocado es que una de los aspectos negativos que hemos detectado es que no hemos cumplido bien las normas del scrum. Y ahí soy yo el principal responsable, porque esa es una de mis responsabilidades… Sin embargo, estoy satisfecho. Está claro que el equipo cree en este método, si no fuera así, no le importaría que las normas hubieran sido vulneradas.

Ahora falta que la Dirección también acabe igual de convencida como nosotros. Creo que vamos por buen camino.

Imagen cortesía de Mountain Goat Software.

I enjoy Mythbusters immensely. Yes, it is truly geeky fun. And they get to blow real things up, not just simulated explosions in mathematical models and 3D renderings. But what is a true joy to watch is how thoroughly methodical they are in solving problems. They research, design, and prototype. They fanatically analyze their results and make adjustments based on the data. Few programs have been bold enough to expose the analytical and development process so transparently. In fact, the boldest thing Adam and Jamie do is solve a problem in front of millions of people, knowing that they will receive hundreds of comments on the work they do. Think about it. Would you work on a problem in front of millions?

Mi "traducción libre":

Disfruto un montón con Cazadores de mitos. Sí, es realmente diversión geeky. Se las apañan para hacer saltar las cosas por los aires, no con explosiones simuladas en modelos matemáticos ni renderings en 3D. Pero lo que de verdad es alucinante es ver lo minuciosamente metódicos que son al solucionar problemas. Investigan, diseñan, y construyen prototipos. Analizan hasta el fanatismo sus resultados y hacen ajustes basados en esos datos. Pocos programas han sido tan audaces como para exponer de una forma tan transparente el proceso de análisis y desarrollo. De hecho, lo más audaz que [los presentadores/cazadores] Adam y Jamie hacen es solucionar el problema frente a millones de personas, sabiendo que recibirán cientos de comentarios sobre el trabajo que realizan. Piensa sobre ello. ¿Trabajarías en un problema frente a millones de personas?

Más sobre la influencia de Colombo, Monk y Maravillas modernas (Modern mavels) en Television for software engineers.

PS: Ya, ya… Es verdad, no traduje geeky, ni rendering. ¿Sugerencias?

En nuestro equipo de desarrollo habíamos seguido en mayor o menor medida, aunque a veces sin mucha conciencia de ello, ciertos comportamientos ágiles, cogidos con pinzas de aquí y de allá. A pesar de todo ello, no éramos un equipo (oficialmente) ágil.

Ahora, con el apoyo de la dirección, podemos decir que oficialmente nos hemos decantado por Scrum. Lo hemos visto fácil de explicar, sencillo y muy claro. Sin embargo, somos conscientes de que, igual que en cualquier faceta técnica, llevar la teoría aunque sea poca a la práctica implicará muchas decisiones y dificultades.

Scrum probablemente no sea el método definitivo, como no lo es ninguno, pero sí que es una base sobre la que elaborar el nuestro propio. No somos racistas, así que aceptaremos de buena gana cualquier idea que sea compatible con los principios ágiles, sin embargo, en mi opinión deberán aceptarse poco a poco (los cambios bruscos, todos lo sabemos, no son buenos). Tenemos ahora lo que necesitábamos: un marco, un esqueleto sobre el que construir el método que nos vaya bien.

Probaremos el método utilizando como plataforma de pruebas un nuevo proyecto que está ahora mismo en las fases iniciales de definición. Todavía nos queda preparar unas charlas para informar al equipo de lo que pretendemos, profundizar un poco más en los principios ágiles que sustentan el método

Decía antes método, y no metodología, porque metodología es otra cosa. De la Wikipedia:

Método es el procedimiento para alcanzar los objetivos y la metodología es el estudio del método.

Voy a utilizar el blog como medio de reflexión, de registro y con vuestra colaboración, espero que también de debate. No recuerdo quién decía que la inteligencia no es patrimonio de la mente, sino de la combinación de muchas, que las buenas ideas emergen de una red pensante, no de una cabeza preclara.

Y como la situación lo merece, amig@s, nueva categoría: ágil

Si tienes prisa o no mucho tiempo para estudiar los inconvenientes de este patrón, yo empezaría por una página de Google relacionada con un "Detector Google de Singletons", que parece casi uno de los chismes del Coyote en sus correrías tras el Correcaminos. Es un resumen muy claro sobre los problemas ocasionados por los singletons. Además, da acceso a otros dos muy buenos.

El primero de ellos es la discusión en el conocido wiki de Ward Cunningham sobre este patrón (además de ser un tremendo repositorio de charlas entre algunas de las mejores mentes del diseño software, en este wiki encontrarás el Repositorio Portland de Patrones). La información no está tan ordenada como en la página de Google, pero seguir la discusión es un buena forma de captar cómo ha ido evolucionando este tema (hace muchos años que se discutió, pero estoy convencido de que sigue de rabiosa actualidad que no de popularidad).

El segundo es el artículo publicado en IBM developerWorks por J. B. Rainsberger, un tipo muy bueno en metodologías ágiles que sigo más por sus artículos en el IEEE Software. Como suele ser habitual en él, presenta el problema de forma muy clara, concisa y amena y ofrece algunas alternativas para evitar los problemas ocasionados por los Singleton. Es de los pocos artículos en los que se comentan las bondades del patrón (como si estuviera diciendo: un Singleton no es ni bueno ni malo, sino que lo usas bien o lo usas mal; ¡me encantan estos argumentos!)

Sin duda es el wiki de Cunningham el que ofrece un tratamiento más amplio del tema. En particular, puedes encontrar la discusión acerca de uno de sus efectos indeseados: la de inyectar estado global a tu aplicación; en otras páginas puedes aprender por qué son buenos para unos y malos para otros, o averiguar formas de reemplazarlos o refactorizarlos. Dado que son clases muy difíciles de probar, encontrarás algún consejo para hacerlo. Ya como curiosidad, tienes a tu disposición implementaciones de este patrón en Visual Basic, Ruby, Python, PHP, Perl, Java y C++.

(No pierdas el tiempo leyendo esta página, tiene que ver con una discusión acerca de la manera en la que habría que organizar el contenido de esta otra página que argumenta por qué los singletons son malignos, que sí es útil).

Termino ya esta recopilación con dos artículos que me han llamado especialmente la atención. En Patterns I Hate #1: Singleton, Alex Miller explica por qué es el patrón que más odia, las alternativas para evitarlos, insinúa cómo refactorizarlos, y da algún consejo si a pesar de todo quieres seguir usándolos. A lo largo de mi viaje por estos territorios, he comprobado que somos muy viscerales con este tipo de cosas, porque en pocas ocasiones leerás que el patrón es apropiado o inapropiado, o bien que es adecuado usarlo en tal circunstancia guiado por cierta solución de compromiso, sino que más bien leerás que alguien lo odia o que es maligno. Mu pofesional .

Steve Yegge es famoso, aparte de por haber trabajado en Amazon, trabajar en Google y por haber migrado Rails a JavaScript, decía que es famoso por publicar entradas tremendamente largas, pero se las apaña para mantener tu atención, a la vez que hace la lectura amena y divertida (aunque más complicada de leer en inglés, precisamente por eso). Cómo no, también ha escrito sobre singletons, pero más que odiarlos o quererlos, piensa de ellos que son… estúpidos En Singleton considered stupid también los estudia, pero esta vez desde un punto más "psicológico", más "social", más… no sé, mira: échale un looking, diviértete, y luego me cuentas.

Y vosotr@s, ¿qué opináis de Singleton? ¿Es un ángel caído o en nuevo santo que canonizar? ¿Comentarios? ¿Experiencias? ¿Críticas? ¿Algún billete suelto de 50 €? ¡Di algo! Si no, creeré que siempre tengo razón

Ir a la introducción de esta serie.
Ir a post anterior.

4. Utiliza sólo una introducción punto por línea

Usa sólo un punto por línea. Este paso evita que tu código alcance profundamente a otros objetos para llegar a sus métodos o propiedades, y por tanto romper conceptualmente la encapsulación.

En definitiva, que te tienes que OlvidarDe.Llamar().AUnMetodo().TrasOtro() en la misma línea y UtilizarSolo.UnaLlamada()

De cara al interface público (es más, publicado) proporcionado al usuario de tus clases, no sé dónde se rompe la encapsulación. Encapsular es asignar cierta responsabilidad a un módulo (en el sentido de Parnas), y hacer que los secretos relacionados con dicha responsabilidad, por ejemplo algoritmos o estructuras de datos, queden efectivamente escondidos en ese módulo. Si quiero saber cuántos alumnos de Derecho reciben clase de un determinado profesor, ¿qué problema habría en escribir el siguiente código?

Universidad.EquipoDocente(idProfe).Docencia(Titulaciones.Derecho).Alumnos.Cuenta()

Por poner un ejemplo. ¿Dónde rompo la encapsulación? Es verdad que aumento la dependencia del usuario de un montón de objetos, y a lo mejor sería bueno crear una fachada, del estilo:

ServiciosDocentes.NumeroAlumnos(idProfe, Titulaciones.Derecho)

Pero al final, ¿no llevaría esto a tener una serie de clases con multitud de métodos, uno por cada ruta seguida a través de los puntos? Empiezo a pensar que esto va un poco de coña…

5. No abrevies los nombres

Esta restricción evita la "verbosidad" procedimental que se crea por ciertas formas de redundancia—si tienes que escribir el nombre completo de un método o variable, casi seguro que te llevará más tiempo pensar en su nombre. Y evitarás tener objetos llamados Pedido con métodos llamados enviarPedido(). En vez de eso, tu código tendrá más métodos del estilo Pedido.Enviar()

La traducción creo que no es muy buena (¿alguien sabe cómo se traduce "verbosity"?), así que lo pongo en el original.

This constraint avoids the procedural verbosity that is created by certain forms of redundancy—if you have to type the full name of a method or variable, you’re likely to spend more time thinking about its name. And you’ll avoid having objects called Order with methods entitled shipOrder(). Instead, your code will have more calls such as Order.ship().

Pues… totalmente de acuerdo. Es más ¿hay alguien que no lo haga así?

¡Espero vuestros comentarios!

Y a mi me sonaba que ya había escuchado esa palabra antes, mucho antes, allá por mis principios en el mundo universitario… Procras, procas, porcras… A la vista de la definición, estaba claro que no coincidía con lo que yo recordaba de la palabra: su historia. La palabra provenía del nombre de un individuo que tenía la desafortunada costumbre de hacer dormir a los altos en camas pequeñas y cortarles las piernas, y a los bajos en camas grandes y estirarlos hasta desmembrarlos. Claramente nada que ver con la procrastinación. Estaba claro que la palabra era otra, pero no conseguía recordarla.

El caso es que gracias a Santa Internet y por intermediación de San Google, con la plegaria "mitología griega cama altos bajos" por fin encontré la palabra. Procusto (del griego Προκρούστης, estirador) era el bandido y posadero que poseía esa extraña costumbre.

En la Wikipedia he encontrado que la palabra también se aplica a la informática. Se dice que una cadena es procusteana si es de longitud fija y, al almacenar texto en ella, se rellena con espacios al final si el texto es de menor longitud, y se truncan los caracteres sobrantes si es de mayor longitud. Esto da explicación a muchos fenómenos "extrañ" en ciertas "aplicaci".

Y aprovechando la charla, se me ha ocurrido pensar que los informáticos somos muy partidarios del procustismo porque, ¿cuántas veces no hemos intentado adaptar una solución a un problema, sin darnos cuenta de que lo estiramos y estiramos hasta desmemblarlo, haciendo que la solución deje de ser válida para el problema? ¿Y tantas otras veces que intentamos "recortar" aquí y allá una solución a todas luces inapropiada al problema que tenemos entre manos? Claro está que es de buen ingeniero aprovechar una solución de forma razonable para resolver un problema, pero todo tiene un límite: el de la Cama de Procusto (en términos de patrones: contexto, fuerzas, aplicabilidad, consecuencias…).

En aquel momento comprendí cómo razonaba mi maestro, y me pareció que su método tenía poco que ver con el del filósofo que razonaba partiendo de primeros principios, y los modos de cuyo intelecto coinciden casi con los del intelecto divino. Comprendí que, cuando no tenía una respuesta, Guillermo imaginaba una multiplicidad de respuestas posibles, muy distintas unas de otras. Me quedé perplejo.

—Pero entonces —me atreví a comentar—, aún estáis lejos de la solución…

—Estoy muy cerca, pero no sé de cuál.

—¿O sea que no tenéis una única respuesta para vuestras preguntas?

—Si la tuviera, Adso, enseñaría teología en París.

—¿En París siempre tienen la respuesta verdadera?

—Nunca, pero están muy seguros de sus errores.

—¿Y vos? —dije con infantil impertinencia—. ¿Nunca cometéis errores?

—A menudo —respondió—. Pero en lugar de concebir uno solo, imagino muchos, para no convertirme en el esclavo de ninguno.

Me pareció que Guillermo no tenía el menor interés en la verdad, que no es otra cosa que la adecuación entre la cosa y el intelecto. Él, en cambio, se divertía imaginando la mayor cantidad posible de posibles.

El Nombre de la Rosa
(Cuarto día, vísperas, hacia el final)
Umberto Eco

Y ahora, amig@s informátic@s (y los que no lo sean también), ¿seguiremos tirándonos de cabeza a la primera solución que encontremos para un problema? ¿Creeremos que tenemos LA solución, o mejor UNA solución? ¿Será mejor elaborar un conjunto admisibles de posibles soluciones, de posibles posibles?

"Thinking please, thinking…"

Para él hubiera sido imposible, como semiólogo que es, no haber hecho girar todo el misterio de su novela detectivesca (llevada al cine con bastante acierto), alrededor de la confusión entre significante y significado, entre símbolo y esencia, entre la realidad de las cosas existentes ¿reales? y de las cosas pensadas ¿imaginadas?.

Atención, spoiler. Si no te has leído el libro o no has visto la película, no continúes. El siguiente texto contiene pistas que te podrían destripar la película (de mala manera).

Dicho lo cual, continuamos:

SECRETUM FINIS AFRICAE
MANUS SUPRA IDOLUM
AGE PRIMUM ET SEPTIMUM
DE QUATUOR

"La mano sobre el ídolo opera sobre el primero y el séptimo de los cuatro".

¡El primero y el séptimo de la palabra QUATUOR, no de su significado!. No entendían porque confundieron el significante con el significado. Y así nuestra "realidad" no es más que un jardín de símbolos en un cerebro que, con suerte, los manipula con habilidad.

Y "la verdad está ahí fuera" significa que lo existente es un jardín de ontologías sobre los que hemos creado un conjunto de símbolos, y sobre los que estamos de acuerdo. Sucede también que, bien manejados, la combinación de esos símbolos y una serie de reglas de la razón nos permite "predecir" el futuro, si hablamos de ciertos símbolos "causa" y ciertos símbolos "efecto". La base de nuestro conocimiento es el acuerdo tácito y dirigido por reglas "razonables" (¿derivadas de aquellos símbolos quizá?) acerca de los conceptos representados por símbolos, junto con una asociación causa-efecto (que Hume cuestionó, por cierto).

Pero no todo es tan fácil. Se debe ser muy preciso en qué símbolo se le quiere dar a qué significado, o arruinaremos el entendimiento. En una conversación informal, se puede permitir cierta ambigüedad y en ciertos casos es incluso necesario (por ejemplo, al contar un chiste), porque la información imprecisa se puede obtener más o menos fácilmente del contexto del receptor. Pero en una conversación más formal, la imprecisión no tiene lugar.

Vale, quillo, ya… lo he pillado ¿y qué?

Pues que si a esta reflexión acerca de la representación por medio de símbolos de conceptos pre-existentes "ahí fuera", junto con la precisión de los símbolos utilizados en la comunicación, le unes ciertos juegos lógicos dispersos por el libro, y lo yuxtapones a ciertas referencias a la criptografía, lo que tienes es que "El Nombre de la Rosa" es un libro geek, friki total, informático 100%.

Ya bueno, lo único que además habla de herejías y religión y… ¿y eso?

Exacto. Pues te sorprendería saber la fe que le tienen algunos a ciertos IDE, la devoción rayana en el fanatismo a una tecnología, las experiencias místicas de otros contemplando la luz de un patrón de diseño, las apostasías de los seguidores de Windows reconvertidos en Linux por obra y gracia del código abierto, y las veces que algunos heresíacos del demonio mencionan equivocadamente el santo nombre de Parnas en vano, y ahogan sus enseñanzas bajo toneladas de código innecesariamente complejo… ¡A la hoguera!

Creo que es mi deber sugerirte que te replantees lo que te propuse hace unas entradas de ir al psicólogo… Conozco uno muy bueno que…

Nop.

Imagen poco usual de una de las toberas del Shuttle.
Más aquí.

Ahí van las primeras dosis:

La primera, por alusión directa al tema de este blog…

La segunda por que me gusta y yastá y sacabó y unanomássantotomás y lodijoblaspuntoredondo y punto (enboca):-)

Ahora vuestro turno ¿qué cosas por ahí os funcionan de combustible?

For some scientists, software development is a branch of mathematics; for some engineers, it is a branch of applied technology. In reality, it is both. The software developer must reconcile the abstract concepts with their concrete implementations, the mathematics of correct computation with the time and space constraints deriving from physical laws and from limitations of current hardware technology. This need to please the angels as well as the beasts may be the central challenge of software engineering.

Meyer, B. Object-Oriented Software Construction, 2nd edition, pag. 8. Prencite Hall, NJ.

Traducción libre del que suscribe: "Para algunos científicos, el desarrollo de software es una rama de las matemáticas; para algunos ingenieros, es una rama de tecnología aplicada. En realidad, es ambas cosas. El desarrollador de software debe reconciliar los conceptos abstractos con sus implementaciones concretas, las matemáticas de la computación correcta con las restricciones de espacio y tiempo derivadas de las leyes físicas y de las limitaciones de la tecnología actual del hardware. Esta necesidad de complacer a los ángeles, así como a las bestias bien puede ser el reto central de la ingeniería del sofware.