Otra razón para hacer Pair Programming

Unas semanas atrás nosotros (el equipo de desarrollo) estábamos pagando un poco de deuda técnica, antes de iniciar la sesión de codificación hicimos una pequeña reunión de planificación. Durante la reunión, les comunique a mis compañeros que realizaríamos las mejoras (refactoring) en parejas (pair programming).

Yo asigné las parejas y establecí un sistema de dos (2) rondas, durante cada ronda una pareja debía completar una tarea por cada integrante (desarrollador). Luego las parejas debían cambiar (de integrantes). Al final de la segunda ronda si algún desarrollador tenia trabajo pendiente, el (si todos hombres, aburrido), debería completar su trabajo trabajando solo. De esa manera durante el día de trabajo cada quien trabajaría con dos compañeros.

Luego de mie explicación de dos o tres minutos, alguien pregunto:
- ¿Por qué debemos hacer pair programming?
- Porque quiero forzar la nivelación y transferencia de conocimientos, contesté

Esa pregunta se quedó en mi cabeza todo el día, primero porque para mí era tan obvia la respuesta y también porque había muchas otras razones: 

• Aprender trucos del IDE
• Doble chequeo de refactoring (complejo y con posibilidad de introducir errores)
• Formación de lazos: el sentido de que estamos arreglando “nuestro” trabajo, no solo tratando con mi propia basura privada tirada en algún momento pasado
• Etc.

Resultados y Ventajas

• Pudimos reducir las violaciones reportadas por la herramienta de calidad en un 17%
• En el proceso aprendimos nuevos trucos del IDE de los compañeros, o los descubrimos por vagancia (tratando de cambiar más código en menos tiempo)
• Mejoramos archivos HTML al remover atributos no necesarios o elementos deprecados (por la especificación de HTML5)
• Discutimos el por qué las violaciones, seleccionadas manualmente, para solucionar eran importantes y como podrían afectarnos en el futuro
• Al final de la sesión todos acordamos en apartar un día de cada Sprint para pagar la deuda técnica vieja
• Ahora todos estamos más vigilantes, durante las revisiones de código, ante nuevas violaciones a los estándares de codificación 

Desventajas

• Gran parte del tiempo lo gastamos en tareas tediosas y manuales
• Para las 3 pm todos estábamos extenuados
• Conflictos de sincronización: por el hecho de haber distribuido las “violaciones” por tipo, y no por archivo o clase, hubo una alta tasa de conflictos

Retrospectiva

Puede ser mejor asignar el trabajo por archivo, o grupos de archivos. Así solo ocurrirán conflictos cuando la interfaz publica (de las clases) cambie.

También, una sesión de limpieza de código realizada por archivo o clase no es tan aburrida pues se manejan diferentes tipos de violaciones.

Another reason for Pair Programming

Some weeks ago we ( the development team) were paying some technical debt, before the coding session we did some planning. While in the short planning meeting I told to my team mates that we'll be doing our refactoring in pairs (pair programming).

I assigned the pairs and established two rounds, during each round a pair need to complete only one task per developer. Then pairs must switch. At the end of the second round if any developer had pending work he (yes all boys, boring), must complete it alone. That way during the day everyone get to work with two partners.

After my 2 to 3 minutes explanation someone asked: 
- Why don we need to do pair programming?
- Because I want to force some knowledge transfer level, I said

That question got stuck in my head the hole day, first because for me the answer was so obvious and also because there were so many other reasons like:

• To learn IDE tricks
• Double checking of (complex, and error prone) refactoring
• Bounding: the sense that we are fixing "our" work, not just dealing with private garbage let by me
• Etc.

Results & Pros

• We manage to reduce the issues reported by our code quality tool by 17%
• In the process we learned new IDE tricks from peers, or discovered by laziness (trying to change more code in less time)
• We improve HTML files by removing unnecessary attributes or deprecated elements (by HTML5 spec)
• We discuss why the, cherry-picked, list of violations to fix were important and how they could affect us in the future
• By the end of the session we all agree to set apart one day of each sprint to paid old technical debt
• Now everyone is more vigilant, during code reviews, for newly introduced violations to coding standards

Cons

• Most of the time it was tedious manual labor
• Around 3 pm everyone was exhausted
• Merge conflicts: because I distributed "violations" by type, not by, physical, file or class there was a high frequency of conflicts

Retrospective

Maybe it is better to assign work by file, or groups of files. That way the conflicts will only occur when public interfaces get touch.

Also, a per class / file cleaning session is not so boring because you get to handle different kinds of violations.

Canned Software

It’s the day you go shopping (groceries), you go to your preferred supermarket and start your routine. You take all fresh goods, and then head to the canned ones. Your children love canned chicken soup; you know it’s not as healthy as the home-made version, but you use it as a prize for good behavior.

They take a two-week supply and gave it for you to put all the cans in the shopping cart. You, as a responsible parent, inspect the cans one by one, looking for defects and the most important fact: the expiration date. You realize that all cans have the same taste, but they are from different brands. Some already had expired (last year!), some will expire in about a month, and finally you see a group of units with an expiration date about one year in the future. As everyone expects, you pick the last group (is always good to have some canned food if a zombie apocalypse occurs).

Now imagine, just for a moment, that instead of canned chicken soup, you went to shop canned software. And that software will be used to run your business, your brand new car, your home fire detection system, or something as delicate as a life support medical machine. 

Continuing with this history, imagine that instead of an expiration date the software cans are labeled with two important information: what they do (functionalities) or ingredients if they were chicken soup; and what is the expected date when that software will no longer be maintained by its creators (expiration date). That last piece of information talks about the internal quality of the software. It says to you: How easy can this software be extended or fixed. Going back to the chicken soup if we have:

Rotten Software Can

• A can of software (soup) with a past Expiration Date: that means that is not possible for the team working behind that software to fix, add, or change features because the product is a total mess (internally).
• A can of software (soup) with an Expiration Date in the near future: this is a software system (project) that is already dying. Its internal quality is reaching the no return point. In a matter of month this system will no longer be maintainable by its team.
• A can of software (soup) with an Expiration Date so distant that nobody can really say when it will happen: this system is the most reliable, extensible, less risky one. 

Fresh Software Can

Of course we are assuming that the first quality feature (functional) is the same for the three scenarios. 

The second quality feature (expiration date) is what is commonly called the Maintainability Index.

So, please, the next time you need to buy a software system, check its expiration date, you don’t want to poison your business, home, car, or children.

Maintainability Index: opinions and usefulness

The usage of this metric is not universally accepted in the software industry. For example checkout (van Deursen 2014) Think Twice Before Using the "Maintainability Index", where the author exposes why he is not quite sure if the metric should be used. 

The main concern is about the reference data (base-line) used to measure software systems. The maintainability index can be considered a relative metric. Is a common practice for software laboratories to test systems (for its internal quality properties), and use that data so build a ranking. If the baseline does not represent the universe of software products relevant for the subject of the analysis the output is not very useful.

Thankfully, labs like the Software Improvement Group (SGI) calibrates their base data yearly. 

Crazy Ideas

Imagine that the Gods of Code gave you a magic wand*. This impressive tool allows you to instantly analyze a code base and give a score from 0 to 10 about its maintainability; where zero (0) means impossible to change, and then (10) really easy to change.

Suddenly, you receive three consulting proposals from distinct clients (A, B, and C). They are requesting you to implement some new features in their flag-ship product. Using your magic wand, you determine that:

• Product A has a maintainability index of 6, 
• Product B has one of 1.5, and 
• Product C has a maintainability index of 9 

Your potential clients have stated that their product is mission critical and that the impact of introducing new defects (bugs) to that product can be catastrophic. Because of that they will transfer that risk to you: any new bug found during a two-month certification period need to be fixed ASAP and without any additional payment.

Assuming a pricing strategy X (time based, effort based, etc.), can we 

• Charge Client C the regular rate? 
• Charge Client A the regular rate adjusted (multiplied) by some risk based factor (inversely proportional to the maintainability index)? 
• Just drop client B and avoid that risk? 

Do you get where I’m going? 

• Can we educate our customers by using a pricing strategy that directly reflects the level of risk and effort we need to put in order to work with their messy piece of code? 
• With time, and some hard experiences, will our customer be more vigilant about the quality of their code base, and maybe start demanding more quality for all developers, inside or outside their organization? 

* Don’t wait for the Gods, you can use SonarQube, PMD, ReSharper, Checkstyle, and many others.