"Tirar Código"

Entre los años 1999 y 2000 me inicie en el mundo del desarrollo de software. Desde esos años vengo escuchando la frase “tirar código”. La misma hace referencia al acto de escribir código fuente o “programar”. No tengo claro de dónde viene la frase, ya que en el idioma Ingles (lingua franca de la Ingeniería de Software), se utilizan las frases “to code”, “to write code”, las cuales podrían traducirse como “codificar” (programar) y “escribir código”. 

“Tirar código” es una frase común entre profesionales de distintas edades, se la he escuchado a personas nacidas en los 60 y llegando hasta el 2000. Un día, reflexionando sobre temas de calidad del software y mejores prácticas, me llego a la mente la frase y de pronto sonó inapropiada. En la República Dominicana cuando algo o alguien es “tirado” (adjetivo) tiene una connotación negativa: descuidado. “Pedro trabaja todo tirado”, o su versión más coloquial “Pedro trabaja to’ tira’o”, significa “Pedro es poco profesional o descuidado, no pone atención en los detalles”. 

Anoche mientras le hacia la observación, repetida en muchos círculos, a un grupo de estudiantes universitarios de que cambien la frase “tirar código” por “escribir código”; me puse a pensar sobre cuales podrían ser los orígenes de la frase. Realmente me da mucha curiosidad el saber 

¿Cómo pasamos de “to code / to write code” a “tirar código”?

Si alguien tiene, o cree tener, la respuesta o una idea favor escribir en los comentarios.

Software: How do you know when it is Green, Ripe, or Rotten?

Farmers Market Fruit Stand, public domain image @ http://www.publicdomainpictures.net/view-image.php?image=149772&picture=farmers-market-fruit-stand

How to buy fruits?

When I was a child, I spent a lot of time with my grandmother. She was raised in a remote agriculture community of my country. So she was very experienced with agriculture products. I love fruit juices and she love to consent all her grandchildren. One of the earlier lessons that I learned was how to pick a good, ready to eat, fruit. There were “easy” ones, like mangoes. Even a child can tell when a mango is not ready to eat yet, ripe, or overripe. But I also face more difficult challenges like melons and passion fruits. 

Those two have a similar little trick, as my grandmother teach me. You have to evaluate the outer layer, or skin, and look for overripe signs. If the outer layer was looks ripe, but firm, then you have to evaluate the inside of the fruit, without open it. Here comes the trick: you must shake the fruit near one of your ears and try to “listen” for the seeds to bounce and hit the inner cavity. If you feel or hear the seeds bouncing then there are good chances that the fruit was ready to eat.

You must have similar stories with culture and region specifics variations. There are other kind of “passed-on” skills like how to buy the best used car with a limited budget.

Now you could be a ground-up woman or man. You may be a c-level executive, a manager or any organizational role facing the decision of buy software products and / or services. And here comes the question: Do you know how to buy a software that is just “ready to eat”?

How to buy software?

Unfortunately, our elders did not taught us how to buy a good piece of software: a “healthy” one. Now we are facing that problem, and each day it becomes bigger and bigger. The average executive does not know how to evaluate the quality attributes of a software product. The more versed ones only know how to ask for aesthetics (visual), usability (easy to use, responsiveness, etc.), and functional quality. So they know how to assess if a software is “easy to use”, “looks pretty” (as of the industry and user-base standards), and if presents the functional characteristics they need (modules, features, etc.).

But there are other quality characteristics of a software products less obvious to the end user. To keep this discussion out of the technical (software engineering) jargon, just imagine (as with the fruits), that software products have an “inside” meat, that needs to be assessed as well. This quality characteristics of the “inside” parts of the software are called Structural Quality Characteristics. 

So, if you are not versed on how to evaluate the “insides” (structural quality) of a software product, do not worry. There are quantitative evaluations and even standards that can throw light into this matter. The last question will be: How to connect all this with my reality?

What to do?

Let's say that you are a COO (Chief Operations Officers), or a CFO (Chief Financial Officers); and you are involved in a big project requiring the purchase of a very expensive software product. If you are not in a very specialized industry, there will be lots, or at least two, options. So you need to select the “mature” (not the green, or rotten) one. And remember that “mature” means “good in the outside and in the inside”. Here you need to ask for the experts.

Your due diligence should be to demand that your IT staff, external organization, or an individual consultant bring together an assessment process that translate all this stuff into a simple, quantitative, decision matrix.

¿Por qué los equipos de Scrum tienen un tamaño limitado?

Visto desde distintos ángulos podemos ver diferentes explicaciones para la recomendación. Primero vemos cual es la recomendación (tomada de The Scrum Guide v2016, p6. Development Team Size):

El espíritu de la “regla”

"Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint."

El límite inferior: 3

"Fewer than three Development Team members decrease interaction and results in smaller productivity gains."

Tamaño mínimo de un equipo de Scrum

El límite superior: 9

“Having more than nine members requires too much coordination.”

Tamaño máximo de un equipo de Scrum

Integrantes: solo los ejecutores

"The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog." 

Así que, tendremos equipos con un mínimo de cinco (5) integrantes y un máximo de once (11). Debemos recordar que el equipo de Scrum se compone del Equipo de Desarrollo, el Scrum Master y el Product Owner. En este cálculo asumimos que el Scrum Master y el Product Owner no son ejecutores (no toman trabajo dentro del sprint backlog).

En este artículo nos enfocaremos en el tema de los canales de comunicación. Para saber cuántos canales de comunicación tendremos en un equipo se utiliza la formula CM = ( n * (n - 1) ) / 2, donde n es la cantidad de integrantes del equipo. Volviendo a nuestros límites tenemos que:

• Inferior n=5: CM = 10 dado por (5 * 4 ) / 2
• Superior n=11: CM = 55 dado por (11 * 10) / 2

Es decir, que en un equipo de Scrum pudiéramos tener que manejar entre 10 y 55 canales de comunicación a lo interno del equipo. A esto súmele la interacción con entes externos. Recordemos también que se recomienda que el área principal de trabajo para un equipo de Scrum sea un espacio compartido por todos los miembros (colocación), esto entre otras cosas para aumentar la comunicación osmótica. En otras palabras, se busca que la comunicación sea abierta y que permee, y haya un máximo grado de sincronización entre los miembros. 

Se busca que los miembros escuchen la mayor cantidad de información posible, aun esta no esté dirigida directamente a ellos. Dependiendo de la cultura del equipo esto puede suponer un alto grado de interrupciones a las labores individuales de cada miembro ya que fácilmente se puede romper su concentración cuando necesitan concentrarse en alguna tarea. 

La cantidad de canales de comunicación también dificulta la labor del Scrum Master. Este deberá poder gestionar impedimentos, mejorar la dinámica del equipo, llevar una bitácora mental de las distintas interacciones entre los miembros y sus oportunidades de mejora. 

En un equipo muy grande, la duración de las ceremonias tendría que extenderse para darle tiempo a cada miembro a tener una participación de calidad. Tomando el daily como ejemplo tenemos que cada miembro del equipo puede hablar hasta 1min:40secs en un equipo de 9 (máximo). A medida que la cantidad de miembros crece este tiempo se irá reduciendo.

Un tema que puede ser analizado por su propio peso y que se relaciona con los canales de comunicación son los medios utilizados. Yo y mis compañeros de equipo utilizamos mayormente la comunicación oral, cara a cara, pero también utilizamos canales electrónicos como Slack. Imagine ahora que además de tener 55 canales de comunicación posibles “cara a cara” ahora también podemos hacer lo mismo en Slack. Podemos tener también grupos cerrados donde se manejen temas que pudieran interesar a todo el equipo. 

En resumen, la cantidad de miembros del equipo impacta de manera directa y positiva la cantidad de canales de comunicación totales. Con el aumento de los canales de comunicación vienen muchas complicaciones en cuanto a la autogestión de un equipo. Esta no es la razón única o principal para mantener un tamaño limitado sobre los equipos agiles, pero definitivamente es un factor de peso considerable.

Como ilustración aquí se presentan la cantidad de canales para equipos de dos a cinco personas.

Canales de comunicación: equipos de 2 a 5 integrantes