El retrospective del segundo sprint

En el proyecto en el que estamos trabajando, una herramienta de planificación y evaluación de rendimiento de una serie de profesionales, no hacemos el programa de una vez y lo entregamos al cliente cuando todo ha terminado. En vez de eso, construimos el sistema poco a poco, de forma incremental, y se lo vamos mostrando al usuario de forma periódica. De esa forma conseguimos del usuario una valiosa información que nos permite valorar la adecuación del producto que se va construyendo, aparte de hacer visibles muy temprano en el proyecto fallos de concepto, de funcionalidad, de usabilidad, etc. y poder corregirlos a tiempo. Al fin y al cabo, los que mejor conocen el dominio del problema y los que en definitiva van a usar el programa son esos mismos usuarios.

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.

Cazadores de mitos

Dan Pritchett (de Adding simplicity) escucha la televisión mientras hace otras cosas. Y escuchando la televisión se ha dado cuenta de que muchos programas tienen graves lecciones que los ingenieros del software podemos aplicarnos. Esta es la lección que podemos obtener de Cazadores de mitos.

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?

Formalmente ágiles

Por fin somos oficialmente ágiles.

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 ;-)

Destilado de Singletons

He querido recopilar información sobre uno de los patrones más conocidos y a la vez de los peor usados: el Singleton. Recogido en el ubicuo libro de la Pandilla de los Cuatro (no los de la cadena de televisión, los otros), se ha dicho de ellos que favorecen el acoplamiento, la creación de dependencias invisibles, que hace difícil las pruebas unitarias (precisamente por esas dependencias) y otras lindezas. Otros sin embargo defienden que (bien usado) puede ser un magnífico aliado.

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 ;-)

Ejercicios calisténicos para objetos (IV)

En estas entradas, el término "calisténico" no hace referencia a ejercicios musculares (puedes encontrar información sobre eso aquí por ejemplo, o seguir buscando en google).

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!

De la adaptación de una solución a un problema

Hoy todo el mundo habla de procrastinación, ya sabéis, el ir retrasando en el tiempo aquello que debe hacerse en favor de otras tareas menos útiles, pero más apetecibles.

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...).

Posibles posibles

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..."

Libro geek: El Nombre de la Rosa

Y ya que estamos con Umberto Eco y su "El Nombre de la Rosa"...

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.

Capítulo II

A pesar de la crisis, hoy necesito combustible para arrancar un nuevo motor.

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?

El reto principal de la Ingeniería del Software

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.

Ejercicios calisténicos para objetos (III)

La introducción a esta entrada puedes verla aquí. El segundo capítulo, aquí.

2. No utilices la palabra clave else

No utilices la palabra clave else. Si la condición no se cumple, debes salir del método. Esto evitará el famoso código sinusoidal al no permitirse cadenas de elses.

No... no acabo de captar el sentido de este ejercicio. Vamos a ver. "No utilices else". Hmmmm. "Si la condición no se cumple, debes salir del método"... "Salir del método..." ¿Y si no quiero salir? ¿Qué pasa si con el else tengo asociado cierto comportamiento no trivial? Creo que el tema del else tiene que ver más con la implementación de guardias (al estilo del DIseño por Contrato á lá Bertrand Meyer) Aquí sí que creo que se han columpiado. ¿No será mejor decir que tienes que evitar aumentar irresponsablemente la complejidad de tu código? ¿Que con cada if (¡de hecho con cada punto de decisión!) haces más difícil entender tu código?

3. Esconde las cadenas y los tipos primitivos en clases.

Esconde las cadenas y los tipos primitivos en clases. Esto se conoce como "obsesión por las primitivas". Si quieres usar un entero, antes debes crear una clase (incluso una clase interna) para identificar su auténtico papel. Con ello conseguirás código mucho más claro y verificable.

¡Abstrae, maj@, abstrae! Crea un nuevo lenguaje, por encima de C++, C#, Visual Basic.NET, Eiffel, Haskel, Caml, o ensamblador (especialmente en ensamblador ;-). Deja de hablar de cadenas, de listas doblemente enlazadas, de árboles equilibrados. Las cadenas de conexión a la base de datos ya no existe, la base de datos ya no existe. La web no existe, ni un servicio web, ni la memoria RAM. El lenguaje en el que debes expresarte y el que antes debes construir, que eso es programar, ¡es el del dominio de tu problema! Si tu problema es financiero (¿y el de quién no, en estos tiempos de crisis?), tu lenguaje permite crear una Accion, invocar el método Accion.Comprar(cuantas). Si tu problema es de logística, tendrás clases como Ruta (.Calcular(), .Llegada(), .Salida()...), Camion, Mercancia...

Más aún, ¿de qué tipo declararías una variable que va a guardar un código postal? ¿un número entero? ¿una cadena de caracteres? Nopes, la solución es crear un tipo CodigoPostal para poder hablar en términos del dominio (por ejemplo, CodigoPostal.Provincia(), y así evitarás tener que invocar mil veces en tu código el método Substring(1, 2) sobre la cadena codigoPostal...). Otra cosa es que internamente sea una cadena, o un número. Eso es decisión tuya y secreto que debe guardar el nuevo tipo.

Dos observaciones. Primero, la obsesión por abstraer puede llevarte a modelizar todo el MundoReal™, (y rediseñar Matrix), y a tu jefe puede que no le mole demasiado. Segundo, abstraer no significa necesariamente ser ambiguo. De hecho, una buena abstracción es extraordinariamente precisa.

Seguiremos informando.

Última adquisición: "OO Software Construction" de Meyer

Por fin llegó. Directamente desde Chicago, y con ciertas muestras de manipulación (imagino que los aduaneros estadounidenses no se fiaban demasiado de que algo que pesara tanto fuera un libro, y abrieron caja y embalaje), ya está en mi mesa.

Me estoy imaginando algunas de las preguntas que os pueden estar rondando la cabeza:

¿Eres del pasado o qué?, ¡Ese libro es la segunda edición de un libro del año 88!

En realidad soy del pasado, todos lo somos, sólo que en Informática y en particular en Programación, cualquier libro que tenga más de dos años nos parece anticuado. Pero si te fijas en el título del libro, no es "Object-Oriented Software Construction with C++", o "... with C#", o "... with C#++ v1.2.1023", ni cualquiera de esos de "Aprenda <EsteLenguaje> en <Random()> Días". Su contenido es aplicable a cualquier sistema orientado a objetos, del año 88 (primera edición), del 97 (segunda edición), o de febrero del 2007 (última impresión, la decimoquinta).

El conocimiento guardado en estas páginas, y las páginas de tantos otros libros "antiguos" es eterno, amigos. Las experiencias de Fred Brooks no se pueden trasladar punto por punto desde su época a la nuestra, desde el desarrollo del OS/360 a los modernos sistemas "web-enabled distributed social-aware scalable user-centered", pero la esencia de esa experiencia sí que lo extrapolable a lo que ahora construimos. Devaluar un artículo como "On the criteria to be used in decomposing systems into modules", de David L. Parnas porque fue publicado en 1972, o desechar el conocimiento proporcionado por el mismo Fred Brooks en "The Mythical Man-Month" porque dirigió el proyecto OS/360 a finales de los años 60 no tiene demasiado sentido (o si lo tiene, el siguiente en caer debería ser Aristóteles, por viejuno).

¿Acaso no sabes ya cómo se construyen sistemas orientados a objetos, que tienes que comprarte ese libro?

Hombre, a ver, algo sé, pero (1) hay que cosas que no sé, así que leer nunca viene mal, (2) hay cosas que sé, pero con el paso del tiempo, se van degradando, se van difuminando, y no está de más pegarles un refresco, (3) en el caso extremo, tras la degradación, viene el olvido, y entonces sí que viene bien re-leer, y (4) hay cosas que leí hace 10 años que ahora "suenan" distinto. Un libro siempre debe tener una penúltima oportunidad de ser leído.

Sólo a ti se te ocurre leer un tocho así, y encima en inglés, ¿has pensado en ingresar en algún centro psiquiátrico?

No, francamente no. El loco deja de estarlo cuando asume su locura como su forma de vida. Además, la locura, como el pecado, siempre está en el ojo del que mira.

Perdón, ¿la calle Guzmán el Bueno?

Dos manzanas más abajo, a la derecha...

Refactorización

Degraciadamente, en según qué ambientes, el concepto de refactorización está condenado al fracaso desde su misma base, su propia definición:

In brief, refactoring is the gradual improvement of a code base by making small changes that don’t modify a program’s behavior, usually with the help of some kind of automated tool.

("Brevemente, la refactorización es la mejora gradual del código fuente por medio de pequeños cambios que no modificar el comportamiento del programa, normalmente con la ayuda de algún tipo de herramienta automatizada")

Desde el punto de vista técnico, la idea es estupenda. Mejorar el código sin modificar el comportamiento del programa ¡Eureka! Desde el punto de vista de gestión, la idea es indefendible. Mejorar el código sin modificar el comportamiento del programa ¡Herejía!

— ¿Quiere eso decir que el usuario no va a obtener ningún valor añadido por la inversión en tiempo que vas a realizar?— dijo el jefe. [N. del T.: "Eso suena a que estás perdiendo el tiempo."]

— Sí, bueno, o sea, no, quiero decir que el usuario no va a obtener nada nuevo, sólo que cuando en el futuro pida algo nuevo, nos resultará más fácil adaptar el sistema.— contestó el ingeniero, mientras pensaba: "Mejor no te digo nada de aumento de la entropía del sistema, o pensarás que estoy más loco de lo que estoy de verdad".

— Ya... Esto... Verás, creo que es más importante que te dediques a tareas que incrementan el valor que el usuario obtiene de tu trabajo. Luego, cuando haya tiempo, te dedicas a "mejorar"— argumentó el jefe. [N. del T.: "Deja de mamonearme y ponte a currar de una vez"]

— Es que si no mejoramos ahora, cada vez será más difícil hacerlo después. Aunque el usuario no lo vea, las modificaciones mejoran nuestro tiempo de respuesta en el futuro, y con ello su satisfacción.— el ingeniero intentaba contraatacar, usandotérminos sencillo que pudiera entender.

— Mira, es mejor que te dediques a proporcionar valor al usuario.— sentenció el jefe [N. del T.: "Que te calles, chitón, shhh, www.shhh.com..."]

— Lo que digas. [N. del T.: "Haré lo que considere necesario para facilitar mi trabajo y evitar que el sistema llegue a un estado de parálisis funcional"]

¿Y tú? ¿Refactorizas?

¿Y lo sabe tu jefe?

Ejercicios calisténicos para objetos

Acabo de leer un post de Andrew Binstock al que he llegado saltando de aquí para allá mientras procrastinaba un poco. Andrew leyó en "The ThoughtWorks Anthology", uno de los últimos libros de la serie "Pragmatic Programmers" un capítulo dedicado a la "calistenia para objetos" (Object Calisthenics) escrito por Jeff Bay.

La palabra es un poco rara así que he investigado un poco sobre ella.

Calistenia f. La calistenia es el ejercicio físico destinado a desarrollar las fuerzas musculares.

Es una palabra que ha entrado en el castellano de la palabra inglesa callisthenics, y estos del griego καλλος (kallos = hermoso), y σθενος (sthenos = fuerza).

En realidad creo yo que el autor no se refiere a la calistenia de los objetos, sino la del programador. De hecho, las normas no son para los objetos, sino para los que los escriben. Los ejercicios  son nueve, y los resumo a continuación.

1. Usa sólo un nivel de indentación por método. Si al escribir un método necesitas un nivel más, significa que tienes que crear un nuevo método al que llamarás desde aquél.

2. No utilices la palabra clave else. Si la condición no se cumple, debes salir del método. Esto evitará el famoso código sinusoidal al no permitirse cadenas de elses.

3. Esconde las cadenas y los tipos primitivos en clases. Esto se llama "obsesión por las primitivas" y no tiene nada que ver con las féminas de Atapuerca. Significa que si representas un código postal como una cadena de 5 dígitos, debes crear una clase CodigoPostal que esconda la cadena.

4. Utiliza sólo una instrucción punto por línea. Eso significa que te tienes que OlvidarDe.Llamar().AUnMetodo().TrasOtro() en la misma línea y UtilizarSolo.UnaLlamada()

5. No abrevies los nombres. Este punto no lo he entendido, pero parece ser que favorece este tipo de llamadas => Alumno.Matricular(), frente a este otro => Alumno.MatricularAlumno(). Como no lo he entendido muy bien lo cito y pido vuestra opinión:

Don't abbreviate names. 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().

6. Haz que las clases y los paquetes (á la Java) sean pequeños. Por lo visto la heurística es no más de 50 líneas por clase y no más de 10 clases por paquete, lo que favorece mantener la cohesión y el acoplamiento controlados. De gratis, las clases te cabrán en la ventana del IDE.

7. No utilices ninguna clase con más de dos variables de instancia. Opina Andrew que esta es quizá la más dura de seguir, Según Bay, si tienes más de dos variables hay motivos para pensar en agruparlas en otra clase (de dos en dos, claro está). Como bien apunta un anónimo, lo tenemos crudo para programar la clase PuntoEnElEspacio, que necesita claramente tres variables.

8. Utiliza colecciones de primera clase. Lo que significa que tu clase Alumnos debe tener una única variable de instancia: una tabla hash, un array, o lo que sea. Pero sólo una variable.

9. No utilices setters, getters o propiedades (¿alguien tiene alguna sugerencia para traducir getter y setter?). Propiedades caca. Por lo visto esta regla favorece la encapsulación, obliga a la implementación de inyección de dependencia, según el principio de "ordena, no preguntes" (tell, don't ask).

Como yo tengo la misma duda que Patrick Dubroy sobre si esto va de coña o no, me he propuesto analizar cada uno de ellos. Como el artículo puede ser muy largo, voy a dejar cada reflexión en un post distinto, y así también descanso un poquito :-).

Seguiremos informando.

La Regla de Thumper

Magnífica regla, en la línea de la Regla lo lo Simple (¿o es lo perfecto?).

La Regla de Thumper dice lo siguiente:

Si no puedes decir nada agradable, entonces no digas nada de nada.

¡Ay!, ¡estas frases que son destilados de sabiduría!

Modelos en arcilla

Me ha gustado mucho la comparativa que ha hecho Doods entre la industria del automóvil y la producción de software. Producir software no es como esas líneas de dedicados robots y humanos especializados, en las que es fácil determinar cuántos coches (idénticos, bien definidos...) salen por hora de la factoría. En realidad, es más parecido al tipo que se encarga de hacer el modelo en arcilla:

"Have you seen a car ad that shows a design studio with a clay mock-up? That’s like software development. The guy on the factory floor can easily know how long it takes to assemble an automobile. It’s much more difficult for the guy sculpting clay to predict how much work and how many revisions it will take to get to the final design".

Esto confirma la idea acerca de la auténtica esencia del software: la información y el conocimiento. De hecho:

"Software development is an exploration. It’s learning about the problem domain, the customer’s needs, and how a solution can be realized with the available resources. Learning requires space and time for experimentation and failure".

¡Es algo fundamental! ¡Nadie aprende por acertar! Si ahora aciertas, es porque antes has fallado de muchas maneras distintas. ¿Por qué no aprendemos a fallar? Creo que tiene que ver con que nos han educado para esperar un castigo si hacemos algo "mal"... No hay que castigar si uno se equivoca... Hay que castigar cuando uno se equivoca reiteradamente. Y ni siquiera en esos casos. Defiendo en esos casos una buena herramienta: enseñar.
Y ya para terminar, categórica, la auténtica definición de "manufactura del software":

"Software manufacturing, at its least adorned, is a file copy operation".

Ahí queda eso [las negritas son mías].

Sencillez (aparente)

No sé dónde lei que cuanto más sencilla es una aplicación para el usuario, más complicado es para los desarrolladores construirla. Y también es cierto que cuando un stakeholder te presenta sus necesidades, el primer modelo mental que se construye es francamente sencillo (o sea, poco detallado).

Cuando por fin vas pasando de un análisis del problema al diseño de una solución, el número de detalles aumenta naturalmente. Este tipo de detalles tiene muchas veces que ver directamente con el problema y siempre con los requisitos del usuario, tanto funcionales como no funcionales. Así, lo que antes era sólo introducir información se transforma en un conjunto de decisiones relativas a la validez de esos datos, a su tipo, a la estructura entre ellos, a qué hacer cuando los datos son parcialmente incorrectos. Sin decir nada sobre los mecanismos de seguridad, que determinan quién puede introducir qué datos y cuando. ¿Habrá un proceso de introducción por una clase de usuarios y otro de validación por parte de otra clase distinta? ¿Se querrá registrar quién introdujo la información? ¿Sólo la última modificación, o un histórico de ellas?

Para los que diseñamos y construimos sistemas de gestión, un síntoma de este Big Bang que transforma un problema primordial en un universo de soluciones galácticas (y el energético proceso que pasa de una a otra) aparece cuando tenemos que agregar "un campo más". Un campo más, es revisar desde la base de datos hasta todas las capas de presentación (incluyo informes), qué partes se ven afectadas... Sí, es cierto, es la más fácil de las modificaciones... :-) Imagínate cualquiera otra...

Por cierto, me niego a traducir "stakeholder" por tenedor de apuestas. Creo que la traducción más cercana podría ser "implicado en" o "interesado por" un proyecto. ¿Alguien tiene alguna otra sugerencia?

"La" manera de hacer las cosas versus "una" manera de hacer las cosas

Lo reconozco, estoy muy negativo. Esta entrada es negativa.

Acabo de leer en el blog de James Fallows una entrada (via raganwald), y comparan la forma en la que unos japoneses repostan un avión, con la forma en la que lo hacen unos chinos. Como bien dice, no es un estudio científico, pero a pesar de ello concluye que:

With usual caveats against sweeping generalization, what this made me think was: Japan is all about the way of doing things. Practice, ritual, perfectionism, as much fanatical attention to the process as to the result. China is all about finding a way to do things. Improvisation, little interest in rules, putting up with whatever is necessary to attain the result.

[El subrayado es mio, las negritas suyas]. Opino que la conclusión puede extenderse también a la idiosincrasia nacional: nos preocupa mucho lo que vayamos a conseguir, pero no tanto cómo lo conseguimos. En el mundillo informático en el que me muevo, el paradigma de "una" manera de hacer las cosas es "pero funciona", mientras que "la" manera de hacer las cosas ni siquiera se piensa, mucho menos se documenta ni se practica.

No lo veo ilógico. En el ámbito laboral, no prima tanto cómo haces las cosas (la manera en la que haces las cosas), sino qué resultados has conseguido en última instancia. Y en particular, tanto mejor si lo consigues en el menor tiempo posible, aunque eso suponga saltarse pasos "innecesarios" que luegon afectan directamente a la calidad de los resultados, o al (invisible) trabajo que hay que rehacer más adelante debido a la baja calidad de lo producido.

Tom deMarco y Tim Lister ya nos lo adelantaron en su libro Peopleware el año 1999. En su capítulo 4 (Quality, if time permits) nos sugieren que hagamos un experimento. Preguntad por ahí a 100 personas que os digan un país asociado a la alta calidad, y es muy probable que el país sea Japón. Y luego preguntad también por ahí qué país está asociado con una alta productividad. Y es muy posible que el país también sea Japón. ¿Alta calidad y alta productividad a la vez?

A ver si la influencia oriental del Japón se nota más allá de la creciente conversión de la gente al budismo.

De democratia

He encontrado dos maneras de hacer que el desarrollo de software se hagan según cierta manera, que vamos a llamar buena (no utilizaré el término mejor). La primera de ellas es utilizar plantillas para crear los distintos artefactos necesarios a lo largo del proceso. De esa forma, siguen una estructura predefinida. Si la plantilla llega al status de "formulario", entonces el tema es todavía más rápido. Existe un riesgo, que es fácil caer en el diseño por copiar y pegar. Si te das cuenta tarde de que puedes factorizar algo, el trabajo puede ser un tanto tedioso.

El segundo método es elaborar un diseño que obligue a que se utilice una determinada estrategia durante el desarrollo (esto se aplica más a la parte de construcción o codificación). Por ejemplo, con un framework de persistencia que obligue a que todo los accesos a la base de datos, incluidas las consultas, se realicen por medio de procedimientos almacenados, permite que la gestión de permisos o la modificación de la estructura física de la base de datos se pueda cambiar en ciertos casos sin que afecte a la aplicación, además de todas las demás ventajas conocidas del uso de procedimientos almacenados frente al acceso directo a las tablas en seguridad, rendimiento, coherencia de los datos...

Sí, lo sé, suena dictatorial y lo es. Pero no estamos hablando de que un proyecto sea una democracia. Sin control, sin ciertas restricciones, es imposible que llegue a nada. También entiendo que la democracia se puede hacer entre iguales, y no suele ser el caso...

Reconozco que estoy un poco sensible, pero creo que es más bien una reacción natural a la presión que impone el no poder comunicarme como me gustaría...

Creo que seguiré analizando este tema. Este pensamiento es simplemente una explosión, y hace falta destilarlo...

Martin Fowler

Indudablemente, uno de los ingenieros software que más me ha influido ha sido Martin Fowler. Su forma de razonar un diseño, su manera de expresarlo, y los ejemplos de código presentados para ello han hecho mella en mí.