Pesadilla en la oficina

Ahora que tenía este post pensado, me comentan que ya existe una entrada en youtube que parodia la serie “Pesadilla en la cocina”, pero en el mundo del software, es decir: “pesadilla en la oficina”. Pues ale, os adjunto el enlace para que disfrutéis del vídeo:


¿Os imagináis algo así en vuestras empresas? ¿Aguantaríais que alguien criticara tan duramente vuestro trabajo? Y ojo, no me vale la típica respuesta de listillo en plan “sólo si sabe mucho más que yo”. Las cosas son como son, nos la diga Chicote, el tal Alvarote del vídeo, o Rita la Cantaora.

La línea de Base y los cambios en producción

branch-per-taskMuchos me diréis que a qué viene esto ahora a cuento. Pues me sigo encontrando muchos casos en los que hay programadores que no terminan de entender el concepto de línea base. Además, este concepto es fundamental para entender los cambios en el ciclo de vida del software, desde el entorno de desarrollo, hasta el de producción. Y no, no me refiero a permitir o no hacer cambios directamente en producción. De eso creo que ya hemos hablado. Me refiero a controlar los cambios en cualquier entorno mediante el concepto de línea base.

¿Qué es la línea base?

La línea base es un concepto de la gestión de la configuración (otro día hablaremos de ella). La línea base se define en el IEEE 600.12/1990 como:

Una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios.

La línea base es un contrato. Un contrato igual que lo es una API, o el WSDL de un servicio web. La línea base establece en qué puedo confiar, porque es algo acordado (ni siquiera tiene porqué ser bueno, probado, excelente o definitivo). Hablamos de una versión de cada uno de los componentes software, que en conjunto, se ha acordado que es correcta en su conjunto. Pero sin suponer esto que cumpla los requisitos, ni las pruebas…simplemente es un hito.

Cuando trabajas con Subversión, TFS o Github, tenemos los conjuntos de cambios, tags o Changesets. Esas etiquetas o paquetes de cambios identifican el software en su conjunto, y son como una foto. Sí, como una foto del software en un momento y situación determinados del tiempo.

Aquí la idea no es versionar. No es un control de cambios. Es tener la posibilidad de devolver todo el código a un momento del tiempo en el que sabíamos que algo funcionaba (o no), pero al menos conocíamos su estado en conjunto. Esto es muy importante para controlar el estado de los entornos, para poder devolver un entorno (pruebas, desarrollo, calidad, preproducción, formación, producción), a un estado conocido.

Si la línea base es una foto, instalar una línea base es devolver a un entorno a un estado conocido, es un viaje al pasado.

Por ese motivo, jamás deberemos tocar el código en producción, ni en pre-producción, ni en otro entorno que no tengamos debidamente controlado con el correspondiente gestor (SVN, Github, TFS…). Porque si tocamos el código, hemos perdido la partida. Ya no podremos tener control de hacer una nueva “foto”, y empezaremos a perder el control de los cambios, de los entornos, del desarrollo.

Y claro que podemos coger ese código, hacer un checkout en desarrollo y poner ese código después para recuperar el estado del entorno de desarrollo. Y claro, también existe Santa Claus, y Blancanieves, y los siete enanitos. Si no lo hicimos en un principio, si nos hemos dejado seducir para tocar el código en producción y “jugárnosla”, hemos perdido el control y ha dejado de jugar a nuestro favor todos los beneficios de la integración continua, testing automático, etc, etc.

Alguna vez he oído decir que tocar el código en producción es como dejarse seducir por el lado oscuro de la fuerza. Tentador…pero no sólo es algo que esté mal…es algo cuyo precio vas a pagar tarde o temprano.

Eat your own dog food

dogfoodingHoy vamos a hablar de un término (dos en realidad), que están relacionados con prácticas de testing interno.

No te despistes al escuchar la frase ‘eat your own dog food’. En el mundo del desarrollo del software, nos referimos a una empresa que usa sus propios productos en el día a día, de forma interna, incluso mucho antes de salir al mercado. ¿Qué mejor demostración de confianza en tus productos y mejor forma de entregar un producto software pulido y plenamente operativo que usarlo tú mismo, de forma interna?.

Esta práctica, que también podremos oir como “dogfooding” (este es el segundo término), puede tener varios orígenes:

  • Queremos dar una imagen de confianza en nuestros productos. Es una manera de decir al público: “eh, fijaos si nos fiamos de nuestro software, que lo usamos día a día internamente”.
  • Qué mejor beta-testing que precisamente usar el producto de forma interna. Tendremos la garantía de que todos los defectos encontrados van a ser reportados, y resueltos de forma inmediata.
Hay muchas compañías que aplican este concepto. Apple usa internamente sus productos, Microsoft es otro habitual en el uso de esta práctica: usa sus lenguajes y entornos de desarrollo para crear sus…lenguajes y entornos de desarrollo, sistemas y aplicaciones. Incluso Microsoft usó Windows Server 2012 todavía sin terminar como plataforma para dar servicio a Bing a nivel mundial.  De hecho, Microsoft lleva toda su historia ligada al concepto de dogfooding con sus productos.
Pero son muchos los desarrolladores que lo hacen. Esto era muy típico por ejemplo hace algunos años con las típicas soluciones sectoriales de pequeñas compañías que desarrollaban software interno para su gestión (facturación, contabilidad, nóminas y gestión de…presupuestos, clientes, proveedores, etc.) y con el tiempo acababan vendiendo el software a empresas de su sector, o incluso a otros sectores.
¿Y tú? ¿Te atreverías a usar internamente en tu empresa el propio software que produces y confiar en él hasta el punto de dejar tus procesos de negocio críticos en sus manos?

ÑaaS (Ñapa as a Service)

ñapa-as-a-serviceHoy os traigo una delicatesen que un buen amigo me ha proporcionado. Como ilustra la figura adjunta, la ñapa es una de las lacras de esta profesión del desarrollo de software, y por desgracia, hay quien la ofrecen como servicio de forma habitual.

Quiero pensar que el autor de la imagen, al escribir “Programming the spanish way”, no hablaba en serio. Me niego a pensar que la forma habitual de programar en España sea la Ñapa.

Para los lectores de otros países, o que me lean mediante el traductor automático, vamos a ofrecer una traducción del término “Ñapa”. No os molestéis en buscar en la RAE (Real Academia Española de la lengua). El término Ñapa no aparece allí. Sin embargo, es harto conocido al menos en España

ÑAPA: chapuza, mierda, parche, remiendo. En informática, dícese del trabajo mal remunerado y peor ejecutado, que consiste en construir un simulacro de aquello que espera ver el cliente, con el mínimo esfuerzo, y totalmente alejado de lo que una mente sana entendería como adecuado.

Eso es una ñapa. Este término está muy relacionado con otros que ya he blogueado (y algunos que aún no he terminado de escribir) como: cantamañanas, o vendemotos, o vendedor de humos (smokeseller para los amigos). Es gracias a esta fauna de la selva informática, a quienes debemos agradecer la existencia de las ñapas.

También hay que agradecerlos a los clientes, que también los hay, que son capaces de cambiar de opinión cada poco tiempo para disfrute de los programadores. Esos programadores que se encuentran que después de docenas o cientos de horas construyendo aplicaciones, éstas dejan de tener sentido debido a “un pequeño cambio”.

Y me rio, me parto de la risa ácida que me entra de forma visceral e insostenible, cuando me salta el iluso de turno con su “esto se arregla siendo ágil”. Hay amigo, esto no lo arregla SCRUM, ni CMMI ni nadie. Cuando el cliente decide que lo más importante no es identificar el impacto de un cambio, ni priorizarlo. Solamente llevarlo a cabo. Aunque haya que tirar a la basura semanas y semanas de duro trabajo para rehacer desde cero miles de líneas de código.

La ñapa o chapuza, es una enfermedad del software (podéis leer más enfermedades del software que he ido recopilando en esta categoría, como la comentitis, singletonitis, excusitis, cacheitis, patronitis… ). Y esta enfermedad es difícil de erradicar. Desde mi experiencia, lo más importante no es la metodología, no es ser más o menos ágil. Sino ser consecuentes y tener la mente fría. Identificar el impacto de las cosas, y asumir que los cambios existen, y que la forma más rápida de llevarlos a cabo es precisamente…no ponerse a ellos de forma inmediata. Sino ponerlos en cartera y ver cómo se relaciona con otros cambios solicitados, los desarrollos en curso, etc, etc.

Gracias José Antonio Herrero por la imagen.

Metodología XP – Introducción

extreme programmingHoy me apetece hablar de la metodología XP (eXtreme Programming). Personalmente, me gusta porque es de las primeras metodologías ágiles con la que tuve contacto, allá por el año 1999. Al igual que en otras metodologías ágiles, es una metodología adaptativa y centrada en las personas. XP agrega buenas prácticas que abarcan más allá de la gestión de proyectos definiendo aspectos más técnicos y cercanos al desarrollo software. El autor o precursor de esta metodología fue Kent Beck, y está basada en 5 valores fundamentales:

  • Respeto: todos los miembros del equipo muestran respeto por el trabajo de cada uno de los demás.
  • Simplicidad: la he puesto en segundo lugar, porque aunque en teoría leeréis que lo simple y la búsqueda de lo simple es la base de XP, me niego a verlo por detrás del respeto.
  • Comunicación: cada una de las tareas del equipo se consideran una forma de comunicación, desde el código, pruebas unitarias, etc.
  • Feedback: XP fue una de las primeras metodologías en incorporar el feedback del cliente. De hecho, el cliente se considera parte del equipo de trabajo.
  • Valor: se refiere principalmente al valor o valentía necesarios para realizar algunas de las prácticas ágiles que XP incorpora. Como el comenzar a programar lo antes posible, o valentía para que el código sea refactorizado y no haya deuda técnica desde el principio, etc.

Como metodología, XP es muy ligera, o más bien podríamos decir, poco estructurada (“ligera” podría considerarse como un término despectivo en el mundo del desarrollo del software). Lo que sí hace XP es incorporar una serie de técnicas o buenas prácticas. Algunas prácticas fundamentales de XP:

  • Programación por parejas: es el punto más controvertido, ya que propone que sean dos personas las que se dediquen a programar. Una persona escribiendo y otra revisando (se pueden alternar). De todas formas, el código se discute antes y durante la escritura. Aquí se practica el famoso “cuatro ojos ven mejor que dos”.
  • Desarrollo por iteraciones: el código se construye mediante iteraciones que van sumando valor o funcionalidad al resultado final.
  • Simplicidad: el axioma “KISS” (Keep It Simple, Stupid), se aplica con regularidad.
  • Refactorización: el código se refactoriza regularmente para que la calidad de código sea notoria, y se evite la deuda técnica. Recordemos que refactorizar, tal y como hemos indicado ya en este blog, nos puede llevar a la refactoritis, una enfermedad de la que ya hemos hablado anteriormente en este mismo blog.

El uso correcto de las plantillas…está en el contenido

Hola, de nuevo colaboro en el arranque de un proyecto, desde mi área de calidad. Y de nuevo, ayudo en la adaptación de las plantillas y procesos para que el proyecto se adapte a lo que el cliente necesita, cumpliendo al mismo tiempo los más altos estándares de calidad.

Acabo de recibir una felicitación porque el conjunto de plantillas y documentación para el proyecto, ha sido percibido por el cliente como excelente. Y sí, para no mentir, son las cosas que te llevas a casa tras un día de duro trabajo que te animan. Las cosas que te animan a seguir luchando por mejorar, por buscar la excelencia, por no apoltronarse sentados en la autocomplacencia.

Pero claro, como buen culo inquieto, quiero más. Y me pongo a pensar que efectivamente, las plantillas, con sus guías, ejemplos y bien pensada estructura, cubren todas las necesidades…¿o no? Pero…¿qué pasa con el contenido?

En algún momento,  todas esas plantillas se convertirán en documentación real, en contenidos que reflejen la realidad del proyecto en un cierto momento y sus objetivos, suposiciones y carencias. Y sin embargo, aquí es donde realmente empieza el valor aportado al cliente. Es como si al cliente le hubiéramos dado un puente. Y sí, el puente está bien. Pero el cliente no quiere un puente. Quiere cruzar el río. Del mismo modo, lo que necesita el cliente no es las plantillas. De hecho, no quiere ni la documentación. Sino el seguro, la garantía que proporciona el tener un adecuado control del proyecto.

La documentación me recuerda al seguro de la vivienda o del coche. Los programadores no quieren oir hablar de la documentación. Esto ya lo comentaba en mi artículo “Nos gusta programar, pero no documentar“. Tampoco nadie quiere un seguro de coche o vivienda. Pero es algo necesario, ya que no podemos circular por ahí, sin convertirnos en “bombas en potencia”. Del mismo modo, un proyecto sin adecuada documentación se convierte en una bomba en potencia, ya que ante el más mínimo problema, empezamos todos a correr como pollos sin cabeza, apagando el fuego como si fuéramos bomberos.

Y es importante recordar, que podemos ser muy buenos creando código super-optimizado, clases y estructuras de información super-funcionales y cumpliendo los más modernos estándares…Pero sin una adecuada documentación, no sirve. Eso me recuerda a los ofuscadores de código. Conozco  gente que no lo necesitaba: su código era auto-ofuscado.

En fin, espero que el equipo de los proyectos sigan trabajando bien, y sobre todo, documentando adecuadamente (evitando la “documentitis”, por supuesto).

Windows 10 y la gestión de pruebas beta

Hola a todos,
Supongo que muchos ya conoceréis el concepto de Alfa y Beta en el mundo del software. Pero es importante destacar, y en ello ISTQB lo diferencia claramente:

  • Pruebas Beta es un software que se da a probar al cliente en su casa. Vamos, que se lo lleva a su casa, o su oficina, y lo prueba.
  • Pruebas Alfa es un software por el contrario, que se prueba en un entorno controlado por el equipo fabricante, en las instalaciones del fabricante.

Y digo esto porque es muy típico confundir con el concepto de pruebas Alfa y Beta con la versión Beta y la versión Alfa (o pre-Beta) de un software.

Me acabo de acordar porque precisamente estos días, me he instalado Windows 10 en versión Beta, a través del Microsoft Insider Program.

Desde el punto de vista de la gestión de proyectos software, es muy interesante este concepto, ya que permitiría, bien llevado, a llevar el agilismo a extremos insospechados. Un cliente puede usar una aplicación (o en este caso, el sistema operativo), y a través del análisis de su uso del software, se podrían detectar funcionalidades mejorables, funcionalidades más usadas, etc. Por supuesto, en el caso de Windows 10, tenemos el caso del feedback tipo “esta aplicación no me ha funcionado”, o “esta página web no se ha visto bien”.

No digo que Microsoft esté haciendo Windows 10 añadiendo funcionalidades ad-hoc a nuestros gustos. Simplemente, que estamos cada vez más, ante una forma de trabajar adaptativa (ágil), permitiendo a posibles usuarios/clientes el ver prototipos tempranos, más o menos terminados.

Otro caso, también de Microsoft, es Windows 10 para móviles. Todos los usuarios de algunos modelos seleccionados, pueden instalarse una versión bastante avanzada (pero aún no terminada), para obtener feedback del uso, pulir defectos, detectar incompatibilidades, etc.

Por supuesto que todo esto ya existe, y tenemos aplicaciones web (recordemos que GMail ha sido una gran parte de su historia una versión Beta: más exactamente algo más de 5 años entre 2004 y 2009) que se ofrecen a los usuarios de manera muy temprana. Sin embargo, la aproximación que ha tomado este fabricante me parece valiente, y a la vez arriesgada, ya que una mala gestión del modelo de betas podría afectar gravemente a su imagen, si por ejemplo todos los ordenadores o todos los móviles dejasen de funcionar, o si los móviles comenzasen a hacer llamadas de forma autónoma y arbitraria.

Aquí desde el punto de vista de las pruebas y de la ingeniería del software, vemos como se presenta una disyuntiva, y hay que buscar un equilibrio entre la estabilidad del producto (por muy beta que sea), y la necesidad de hacerlo probar a un público lo mayor posible para obtener feedback. Desde luego, es necesario tener un gran control de las pruebas realizadas, y obtener métricas que nos permitan estimar (de forma aproximada, claro), el número de defectos y su gravedad en caso de liberar nuestro producto inacabado.

¿Y vosotros? ¿Os atreveríais a hacer público un software inacabado siguiendo un modelo de pruebas Beta? ¿Cómo gestionaríais los riesgos de hacer público un producto sin terminar?