- Tags:: #📚Books, #✍️OwnPosts , [[My engineering management principles, values, and practices]], [[Work Methodology]]
- Author:: [[Kent Beck]] y [[Cynthia Andres]]
- Liked:: #4/5
- Link:: [Extreme Programming Explained [Book] (oreilly.com)](https://www.oreilly.com/library/view/extreme-programming-explained/0201616416/)
- Source year: [[2005-01-01]]
- Year read: [[2020-01-01]]
# Part I
Published in [Book review (1/2): Extreme Programming Explained (Second Edition) de Kent Beck y Cynthia Andres (substack.com)](https://drmario.substack.com/p/book-review-12-extreme-programming)
Hoy me incorporo al equipaso de [[Mercadona Tech]] y ya me habían soplado que son [ultra fanes de XP](https://youtu.be/DSxFvswXjy0?t=1370). Ha llovido desde mi primer (y último hasta la fecha) contacto con Extreme Programming, que fue allá por 2015, teórico, y un poco de refilón (algunas preguntas en los exámenes de Professional Scrum Master y Professional Scrum Developer).
Antes de mi primerito día selling lechugas, quería recordar prácticas, y sobre todo los **valores**, concretados en **principios** y los porqués. Intenté hacer un atajo y primero me lei la [Extreme Programming Pocket Guide](https://www.oreilly.com/library/view/extreme-programming-pocket/9781449399849/) y de ahí salí escandalizado…
https://twitter.com/Dr___Mario/status/1310269262049816576?s=20
…pero LaGenteTM, sabiamente me aconsejó que fuera a por el original, este "Extreme Programming Explained", en especial @jcesarperez:
https://twitter.com/jcesarperez/status/1310299764668403713?s=20)[
Y es curioso porque, efectivamente, he salido encantadísimo de la vida, aunque creo que es un approach a la creación del software bastante... valiente, y complicado de hacer correctamente (pero vamos, _pretends to be shocked_, hacer las cosas bien cuesta trabajo). Estoy deseando probarlo, especialmente en un equipo que tiene pinta de estar tomándoselo bastante en serio.
El libro, por cierto, está para mi gusto genialmente estructurado: te cuenta primero los valores, después principios (la concreción de esos valores en torno al software) y las prácticas de XP, con luego algunos extendidos bastante interesantes alrededor (cómo afecta XP a todos los actores en una empresa, una discusión más larga sobre diseño incremental, testing...). No voy a reproducirlos todos aquí (para eso está el propio libro), pero sí quiero resaltar aquellas cosas que me han sorprendido más.
Hay tanta tela que cortar que lo tengo que dividir en dos entregas.
En ésta:
- ¿Por qué “extreme”?
- La oralidad de XP.
- Incremental Design.
# ¿Por qué "extreme"?
Según el propio Kent Beck, "extreme" aquí se refiere a la pureza: dice que ha destilado aquello que ha hecho o ha visto que se ha hecho que funciona. Pero claramente es extreme también en contraste con cómo se venían haciendo las cosas:
>Practices that seemed impossibly extreme five years ago, when the first edition of this book was published [1999!], are now common. Five years from now the practices in this book will probably seem conservative. [p. 21]
## Todavía es "extreme" (pero ojalá no lo fuera)
¡Muchas de las propuestas me siguen pareciendo bastante poco convencionales hoy! Me asustan incluso, pero Kent Beck todo esto se lo veía venir. Me gusta mucho **que se anticipe y hable precisamente de estas emociones** en múltiples partes del libro:
>Is about social change (...) giving up the defenses that protect us but interfere with our productivity. **It may leave us feeling exposed.** [p. 1]
>Raise your expectations for accountability and teamwork, then help the team through **the inevitable anxiety that comes with change**. [p. 57]
>Sometimes the desire for more time is a mask worn to protect from the fear of the consequences of getting going. [p. 31]
>XP also encourages human contact among the team, reducing the loneliness that is often at the heart of job dissatisfaction. [p. 6]
Y uno de mis fragmentos favoritos porque como mega control freak que soy, me siento totalmente reflejado:
>Energized work (...) I'm my own case I think **I turn to long work hours as a way of grabbing control in a situation in which I am otherwise out of control**. I can't control how the whole project is going (...) but I can always stay later (...) past the point where I have started removing value from the project. [p. 41]
No es casualidad, es que precisamente considera que el objetivo de XP es humanizar el desarrollo de software con todo lo que ello supone, porque con ello también conseguirá una mayor productividad, es decir, **humanidad y productividad están en una situación de win-win:**
>XP is my attempt to reconcile humanity and productivity in my own practice of software development. [p. 3]
XP además es muy prosocial. Hace **especial hincapié en las relaciones interpersonales** entre todas las personas que intervienen en el hacer del software:
>The key to success lies not in self-mortification but in acceptance that we are people in a person-to-person business. [p. 4]
Y de hecho...
>Its reliance on the close collaboration of **actively engaged individuals with ordinary talent.**
^b9a679
De relaciones interpersonales en software, en realidad, se ha hablado muchísimo. No hay casi libro de software que no cite la mítica frase de [[Gerald Weinberg]]: [[🦜 No matter how it looks at first, it's always a people problem]]. Lo que me resulta sorprendente de XP es integrarlas tanto en el framework de trabajo y la exhaustividad con que las trata.
# La oralidad de XP
## No a la comunicación escrita
Una de las cosas que más me sorprende de XP, y con la que más me cuesta comulgar, plenamente es su defensa de la comunicación oral frente a la escrita.
>Written communication is inherently more wasteful (...) it is a one-way communication. [p. 23]
>Maintain only the code and the tests as permanent artifacts. Generate other documents from the code and tests. **Rely on social mechanisms to keep alive important history of the project**. [p. 66]
Súper a favor de que cualquier documento esté lo más cerca posible del código (generar docs del código, por ejemplo). Pero me cuesta aceptar la idea de depender de "social mechanisms" tanto: la memoria falla, es imprecisa, la gente se va de los equipos… Entiendo que Kent Beck propone crear un clima del que la gente no se quiere ir y en el que mantener viva la historia de un proyecto, pero se pueden ir igual y tengo la sensación de que la barrera de entrada al proyecto es mayor, como por ejemplo cuentan en
[Your developer won’t get hit by a bus. They’ll get hired by Netflix!](https://www.neomindlabs.com/post/your-developer-wont-get-hit-by-a-bus-theyll-get-hired-by-netflix)
[[SWE hiring best practices]]:
>Sticking to the standards evangelized by the community and adding proper documentation (possibly in the form of useful tests) makes onboarding a breeze, which creates more productive developers, which makes hiring more accessible, which reduces your “bus factor.”
Tiene sentido en el marco de humanizar el software, que quieras fomentar la conversación oral, porque esto favorece el tratar las emociones, la empatía... Sin embargo, creo que Beck no es del todo justo con los méritos de la comunicación escrita. Por ejemplo, cuando afirma lo siguiente:
>Extensive internal documentation of software is an example of a practice that violates mutual benefit (...). I can see a posible benefit to the future person should the documentation still happen to be valid, but no benefit now. [p. 26]
Sí que veo beneficios en el now: el más directo es que escribir es pensar y cristalizar. Como se menciona en [[Who Builds a House Without Drawing Blueprints_]]: “Writing is nature's way of letting you know how sloppy your thinking is”.
Aunque en justicia, el comentario de Beck, como apuntó mucha gente en el hilo de Twitter al principio de esta newsletter, quizá va referido sobre todo a la parte de "extensive" y al contexto de la época (por ejemplo, los grandes documentos de especificaciones en un waterfall). Además, para él esa cristalización son los tests funcionales, los unitarios, y el propio código. Still, pienso mucho en la línea de lo que se cuenta en [[Who Builds a House Without Drawing Blueprints_]]
>Programmers who advocate writing tests before writing code often believe those tests can serve as a specification. Writing tests does force us to think, and anything that gets us to think before coding is helpful. **However, writing tests in code does not get us thinking above the code level.** We can write a specification as a list of high-level descriptions of tests the program should pass essentially a list of properties the program should satisfy. But that is usually not a good way to write a specification, because it is very difficult to deduce from it what the program should or should not do in every situation.
## Bien de conversación
Otra cosa que contradice totalmente mi intuición es cuan intensiva propone que sea ese hablar entre compañeros:
>People evaluating XP teams should understand what an effective team looks like. This may differ from other teams they have seen. **For example, talking and working go together on an XP team. The hum of conversation is a sign of health. Silence is the sound of risk pilling up.** [p. 79]
[](https://cdn.substack.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F516d3b3b-80b7-4e6e-983f-89eae4680636_630x630.jpeg)
A mi me ha tocado hacer mucho más tener que pedir a un equipo que por favor no me montaran el "Hablar por Hablar", que lo contrario. Pero el amigo Kent Beck, que ha pensado muy fuerte todo esto, tiene respuesta para todo:
>Perhaps this sounds like a perpetual coffee klatch with everyone sitting around 'caring and sharing' and no one doing anything. **Other values held by the team keep this from happening.** [p. 18]
### The signature practice: pair programming
De hecho, quizá la práctica más popular desde fuera de XP es el **pair programming**. Pero que lo que propone Beck es mucho más que practicarlo de cuando en cuando, sino al revés, solo de cuando en cuando ve a programar tú solo:
>Write all production programs with two people sitting at one machine. [p. 42]
>Pairing doesn't mean that you can't think alone. People need both companionship and privacy (...). **You can even prototype alone and still respect pairing. However, this is not an excuse to act outside of the team (...) bring the resulting idea, not the code, back to the team.** With a partner, you'll reimplement it quickly. The results will be more widely understood. [p. 42]
Este último matiz me pareció muy interesante, me hizo aceptar la práctica con mucho más convencimiento, porque creo que en el pair programming como double check y difusor de conocimiento, pero no creo mucho en el pensamiento colaborativo como mecanismo principal para resolver algo. Siento que me funciona mucho mejor alternar reflexiones / exploraciones individuales con puestas en común, que intentar algo (que se me hace tan raro) como pensar en compañía, verbalmente. En mis equipos normalmente, previo al coding de features no triviales, hacemos un documento de análisis sobre el que colaboramos (como conté en [[📖 Fundamentals of Software Architecture. An Engineering Approach]]: ‘Mención especial, "The bottleneck trap"‘).
El propio Beck afirma que, lógicamente, este pair programming tan intensivo cansa, que no puedes estar 8 horas de trabajo pairing (¡aunque el propone 6!), pero que merece la pena por múltiples motivos: mantenerte en la tarea, brainstorming, obligar a clarificar, desatascar al compañero y ser más responsable. Todos los que hemos jugado al Among Us sabemos que mucho de esto es cierto.
Me sorprende también las rotaciones que propone:
>I like to program with someone new every couple of hours. [p. 42]
Que aquí ya me vuelvo loco... ¿cómo se gestionan los cambios de contexto en las tareas? ¿Será porque tienen que tener granularidades muy pequeñas?
### ¿Open offices ok?
Lógicamente, si buscas que haya una conversación siempre en marcha, necesitas una open office:
>Sit together (...). Develop in an open space big enough for the whole team. [p. 37]
Sin embargo, me pregunto cómo casa todo esto con lo que lei en su día en el también mítico [[📖 Peopleware 3rd Edition]] sobre las open offices:
>...without warning, open-plan seating was upon us like a plague upon the land. The advocates of the new format produced not one shred of evidence that effectiveness would not be impared.
Curiosamente en Peopleware sí que hay varias referencias a varios estudios al respecto, que no dejan en buen lugar a la open office.
[](https://cdn.substack.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F709800ae-2dc7-4eb7-bafa-c90304c2c1ce_2334x1415.png)
Se ve cierta correlación del performance con la "quietud", "privacidad" y la ausencia de interrupciones. En cualquier caso, en ese estudio no se estaban aplicando el resto de prácticas de XP: aplicar todas las prácticas es lo que hace que XP funcione plenamente, por toda una serie de sinergias entre ellas.
### Socialización, pero lógicamente hay límites
Beck trata incluso qué pasa si hay incomodidades haciendo pair programming, y hasta incluso, si surgen sentimientos:
>Pairing and personal space. When programmers aren't emotionally mature enough to separate approval from arousal, working with a person of the opposite gender can bring up sexual feeling that are not in the best interest of the team. [p. 43]
Se siente un poco distópico el tratarlo así, pero es que es verdad que estas cosas pasan, que está bien hablarlas, y no deja de ser cierto lo que comenta al respecto.
Otra de mis partes favoritas del libro ha sido este fragmento:
>Fussing about the constraints distracts you from your goals (...). If you have six weeks to get a project done, the only thing you control is your own behavior (...). You can't control others' expectations. You can tell them what you know (...) so their expectation have a chance of matching reality. **It's not my job to manage someone else expectations.** [p. 5]
Siempre que he currado como líder de equipos he pensado que mi trabajo principal es precisamente gestión de expectativas:
https://twitter.com/Dr___Mario/status/1314129664273788928
Este fragmento ha sido de lo más liberador que he leído en mucho tiempo.
# [[Incremental design]]
Este es otro de los puntos que me resultaron chocantes al leer la pocket guide, pero que me ha quedado muchísimo más claro al leer este libro.
Invertir mucho en diseño al principio de un proyecto/feature viene de distintos estudios a finales de los locos años 80. Por ejemplo en [[📖 Code Complete 2nd Edition]] de Steve McConnelll encontramos lo siguiente:
>If you can prevent defects or detect and remove them early, you can realize a significant schedule benefit. Studies have found that reworking defective requirements, design, and code typically consumes 40 to 50 percent of the total cost of software development (Jones 1986b; Boehm 1987a). As a rule of thumb, every hour you spend on defect prevention will reduce your repair time "3 to 10 hours" (Jones 1994). In the worst case, **reworking a software-requirements problem once the software is in operation typically costs 50 to 200 times what it would take to rework the problem in the requirements stage** (Boehm and Papaccio 1988). Given that about **60 percent of all defects usually exist at design time** (Glib 1988), you can save enormous amounts of time by detecting defects earlier than system testing.
La idea del incremental design que propone XP, por el contrario, es no invertir mucho tiempo en diseño upfront, porque lo contrario es un ejercicio especulativo:
>Incremental design suggests that the most effective time to design is in the light of experience. [p. 52]
>One factor to take into consideration in deciding when to design is the value available through the different strategies. [p. 106]
[](https://cdn.substack.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F57529ea9-2178-4b88-9078-df80e91844e5_1724x1926.png)[](https://cdn.substack.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F405ce549-8e0a-46e8-9cd6-0f0d10f4c2b3_2378x1669.png)
Tiene muchísimo sentido para mí esto, pero, ¿cómo sabes ante qué problema/situación estás a priori, sin diseñar y sin la experiencia? Aunque luego lo aclara: se trata de invertir lo justo en diseño inicial para obtener el suficiente feedback para otra ronda.
Beck, además, cuestiona esos estudios previos que parecen afirmar que siempre cuesta más arreglar los defectos con el tiempo (aunque lo cierto es que lo hace sin data) :/
>For an assumption that shaped software development orthodoxy for decades, the increasing cost of change over time received little scrutiny. This assumption may no longer be valid [p. 52]
>Refactorings can occur at any level of scale. **Few design decisions are difficult to change once made**. [p. 53]
>XP teams work hard to create conditions under which the cost of changing the software doesn't rise catastrophically. [p. 52]
>Unfortunately, design in software has been shackled by metaphors from physical design activities (...) in software, however, reversing a day's work is trivial. [p. 104]
Luego matiza que no es tan trivial:
- Require habilidad el saber hasta dónde llegar:
>There is an art to designing just **enough** to get feedback, and then using that feedback to improve the design enough to get the next round of feedback. [p. 104]
- Hay que partir grandes cambios para que cada semana, aún así, se entregue funcionalidad:
>Sometimes the team can't make a design improvement in a week and still deliver new functionality. Part of incremental design is figuring out how to stage design improvements (...). As you touch the existing code, concentrate those assumptions in as few places as possible. Eventually, the job (...) will fit into a week. Such long-running changes may seem to cost more than stopping development and making the change all at once. (...) **Design is in service of a trust relationship between technical and business people. Weekly delivery of requested functionality is the cornerstone of that relationship.** [p. 108]
- Y por supuesto, también require disciplina:
>Most often, I didn't improve the design because I was focused to narrowly on the problem of adding one more feature to the system. [p. 108]
También hace una aclaración muy importante, que yo desde luego necesitaba:
>Some of the teams who read and applied the first edition of this book didn't get the part of the message about the last _responsible_ moment. They piled story on story (...). **Without daily attention to design, the cost of changes does skyrocket**. [p. 52].
Este tipo de aclaraciones ponen de relieve algo que nos afecta mucho en este sector (me imagino que en todos): oir los titulares y quedarse con una idea errónea. Realmente los matices luego son tan potentes que cambian bastante la idea, como por ejemplo comentaba en [[✍️ Ask HN. How bad should the code be in a startup.]]
# Part II
Published in [Book review (2/2): Extreme Programming Explained (Second Edition) de Kent Beck y Cynthia Andres (substack.com)](https://drmario.substack.com/p/book-review-22-extreme-programming)
Segunda parte y final del resumen del “Extreme Programming Explained. Un poco más y acabo copiando y pegando el libro entero. El menú del día es:
- Kent Beck 🤜🤛 Frederick Taylor.
- ¿Hay un problema de incentivos en XP?
- El mercado global del trabajador de software.
- Despedida y cierre.
[](https://cdn.substack.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2F4569233c-d9a2-4bc9-80fb-8498307d2ff0_1100x825.jpeg)
# Kent Beck 🤜🤛 Frederick Taylor
Uno de los side (¿no tan side en realidad?) topics que trata Kent Beck hacia el final del libro es cómo la herencia que traemos de la "organización científica" del trabajo del [[Taylorismo]] es la responsable de mucha _malfunción_ al construir software. Hacer software no es un proceso industrial, el Taylorismo parte de unas premisas que no aplican aquí.
## Las cosas salen de acuerdo con el plan
Aquí, todo el capítulo 8, "Estimation" del [[📖 Rapid Development]] es espectacular:
> The basic software-estimation story is that software development is a process of gradual refinement. You begin with a fuzzy picture of what you want to build and then spend the rest of the project trying to bring that picture into clear focus. **Because the picture of the software you're trying to build is fuzzy, the estimate of the time and effort need to build it is fuzzy too**. (p. 165)
## La micro-optimización lleva a macro-optimización
En software, micro-optimizar no suele ser suficiente: mantener una visión de sistema, holística, nos puede desbloquear mejoras mucho más dramáticas. Por no hablar de que hacer cambios a nivel de sistema es mucho menos traumático que en un proceso físico (de esto ya hablamos en el post anterior).
## La gente es intercambiable y necesitan decirles qué hacer.
No hay mucho que comentar en esto, ¿no?
## Una estructura social que… no pega.
- Separa planificación de ejecución
- Crea un departamento de calidad separado.
> No one wants to think of himself as a cog. (p. 136)
>
> Taylor assumed that workers would 'soldier' whenever possible (…) Sends the message that engineering and quality are separate, parallel activities. (p. 132)
La alternativa a esto (especialmente a esta estratificación social) e inspiración de XP, es esa referencia que seguro que has leído por múltiples otras vías, que es el [[Toyota Production System]], donde, entre otras cosas, **todo el mundo es responsable de la calidad.**
# ¿Hay un problema de incentivos en XP?
Cuando uno oye frases del tipo "todo el mundo es responsable de la calidad", asiente con la cabeza. Pues sí, ¿quién va a decir que no? Pero pasa un poco lo que se comenta en un artículo que cito muchísimas veces, [[🗞️ How to read self-help]]:
> But this is a hallmark of wisdom: **it’s trivial to read but nearly impossible to put into practice** (…) we need lots of examples to drive this wisdom home. We should be more forgiving of self-help (the genre) and more forgiving of ourselves. Putting wisdom into practice takes requires reading, reflection, and practice."
Es decir, ¿cómo se gestiona esto en la práctica? ¿Cuál es el incentivo para que se honre este ideal? Este es **el punto que me parece más crítico de XP:** una de las cosas más importantes a tener en cuenta para que tengamos o no éxito con él. Me surgen muchas preguntas:
- ¿Para tener éxito con XP es condición necesaria y suficiente que inherentemente la gente que forma parte de tu empresa tenga una motivación intrínseca por hacer un buen trabajo, y por entender que es un esfuerzo colectivo?
- El objetivo es de equipo, pero, si todos somos responsables, ¿cómo evaluamos el rendimiento de un trabajador?
- ¿Cómo somos responsables todos de la calidad y, al mismo tiempo, lo hacemos de una forma eficiente (esto es, no estamos todos a absolutamente todo)?
- …
El propio capítulo sobre el [[Toyota Production System]] que incluye este libro nos resuelve un poco la primera cuestión (quizá también la tercera). Tenemos que cambiar de un modelo "push" de trabajo (que haya mucho trabajo work in progress, es decir, muchas "partes" entre cada paso de la cadena de montaje de manera que cada paso de la cadena pueda trabajar independientemente y no tenga que esperar nunca al paso anterior), a un modelo "pull":
> Workers are accountable for the quality of their work **because the parts they create are immediately put to use by the next step in the line**. (p. 136)
>
> If you use a part immediately, you get the value of the part itself as well as information about whether the upstream machine is working correctly (…) **leads to pressure to keep all the machines in a line working smoothly** and also provides the information necessary to keep the machines working smoothly. (p. 136)
Que vamos a tener problemas con la evaluación de los miembros de un equipo XP también lo prevé Kent Beck. Él mismo nos dice:
> …most reviews and raises are based on individual goals and achievements, but XP focuses on team performance. **If a programmer spends half of his time pairing with others, how can you evaluate his individual performance? How much incentive does he have to help** other if he will be evaluated on individual performance? (p. 82)
Esto, por tanto, puede guiar malamente las decisiones de los developers, como por ejemplo a la hora de decidir si invertir tiempo en mejorar el diseño del software (que es crucial pero no visible) vs. añadir una feature más (que es algo mucho más vistoso). Incluso puede haber impacto en el throughput de toda la organización:
>The [[Theory of Constraints]] says that in any system there is one constraint at a time (occasionally two). To improve overall system throughput you have to first find the constraint; make sure it is working full speed; then find ways of either increasing the capacity of the constraint, offloading some of the work onto non-constraints, or eliminating the constraint entirely.
^2fb484
> The [[Theory of Constraints]] shares with other theories of organizational change the assumption that the whole organization is focused on overall throughput, not on micro-optimization. **If everyone is trying to make sure his function is not seen as the constraint, no change will happen...**
^da43d6
> The reward system and culture need to align with overall throughput instead of individual productivity** for the change to stick. (p. 99)
> Sometimes XP can facilitate **shifting the constraint out of software development completely** (…) The programmers may learn to go fast enough that product marketing can't specify features fast enough. (p. 89)
Beck nos anticipa dos posibles soluciones a este problema de evaluación: evaluación por equipo o evaluación individual pero con distinto criterio al típico.
## Evaluación por equipo
> The need for altruistic behavior, however, moves some teams to give raises to the team as a whole instead of to individuals. (p. 82)
Este modelo es el que me resulta más coherente, con diferencia, con la naturaleza de XP (equipo, auto-organización...), pero no termina de solucionar qué ocurre cuando hay miembros del equipo que no encajan. ¿Entiendo que la autonomía de los equipos permitiría que éstos mismos tomaran cartas en el asunto (p. ej., sugiriendo planes de rendimiento, transferencia a otros equipos...)? ¿Cómo nos aseguramos de que los equipos no se conviertan, por otro lado, en ghettos? Y aún así, ¿cómo evitas la competición entre equipos? ¿Se trata de dar un paso aún mayor, de más alto nivel, y asegurarte que tienes una cultura de empresa en la que todo el mundo entendería que la competición individual no tiene lugar? ¿Volvemos a dejar las cosas un poco en manos de la motivación intrínseca del trabajador?
Mientras escribía este post (it’s been 84 years…), aparecía esta noticia un poco controvertida, sobre como [Typeform introdujo un sistema monetario interno para agradecer a tus compañeros su colaboración](https://sifted.eu/articles/typeform-culture/). Meanwhile, at Mercadona Tech:
[](https://cdn.substack.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fbucketeer-e05bbc84-baa3-437e-9518-adb32be77984.s3.amazonaws.com%2Fpublic%2Fimages%2Ff1707331-600f-40b7-b0fa-cc915fde4448_940x861.png)
Nuestra moneda de agradecimiento, 100% real no fake
## Evaluación individual, pero ojito
La alternativa es seguir con las evaluaciones individuales hasta ahora, pero puesto que XP es transparente, un manager tiene mejor información para decidir. Eso sí, teniendo en cuenta que la vara de medir sea:
> In XP, valuable employees: act respectful, **play well with others**, take initiative, deliver on their commitments (p. 82)
Entiendo que cómo alinear los valores de todas las personas en tu organización da para un libro aparte, pero me deja el tema mucho más abierto de lo que me gustaría, para lo crítico que creo que es. Con todo, al final siempre veo una reducción, un leitmotiv en software management que, por un lado es esperanzador (en tanto que es accionable y sencillo de entender), pero al mismo tiempo solo te deja un grado de libertad/acción: **necesitas** **un recruiting exquisito (con la actitud del candidato)** para encontrar a esa gente que entiende o puede llegar a interiorizar que:
> **Without a change of heart, all the practices and principles in the world will produce only small, short-term gains.** You and the rest of the team [business, product...] share a fate. Act like it and you may come to believe it (…) We, in software, have the opportunity to create new social structures in which technical excellence is joined with business vision to create new products and services of unique value. (p. 154)
>
> Tools and techniques change often, but they don't change a lot. People, however, change slowly but deeply. **The challenge of XP is to encourage deep change, to renew individual values and mutual relationships** to give software a seat at the table for the next fifty years." (p. 155)
Así lo contaba Fernando Díaz, el CTO de Mercadona Tech, el año pasado (su poquito de stalking cuando vas a entrar a trabajar en un sitio es importante):
# El mercado global del software
En este capítulo Beck utiliza el [[offshoring]] un poco como excusa (un caso de estudio en el que sería complicado aplicar XP) para hacer una reflexión muy interesante, especialmente en el contexto que nos encontramos ahora.
Arrancamos fuertecito. Ojo a esto, que es 2005:
> I don't like the political and racial overtones of the word 'offshore': high-paid white people taking advantage of low-paid dark people and then complaining about 'them' taking 'our' jobs (p. 149).
Para Kent Beck, la globalización en el contexto de la industria del software **no es un juego de suma cero**, y uno de los principios de XP, el de _mutual benefit_ ("every activity should benefit all concerned") es perfectamente posible con el offshoring.
> If the software industry learns to create more value at lower cost, the increase in demand will more than make up for the temporary loss of jobs in any one location. (p. 150)
Pero eso sí, todo el mundo tiene que ponerse las pilas. Todos tenemos algo que ofrecer, pero... hay que ofrecerlo:
> In high-cost-base areas, improved efficiency, integrity and accountability are imperative for survival. The days of one hundred expensive contractors without accountability working on one project are numbered. The same project will be done with ten efficient and accountable programmers or it will go elsewhere (…). **High-cost-base teams need to focus on high-leverage projects, where the strength of direct communication is most valuable".**
>
> To compete, **low-cost-base teams need to increase the value** they create too. **Just because you can afford to throw lots of bodies at a problem doesn't mean that is the most profitable way to solve it.**
# Otras notas
Que no planees mucho:
> Planning is a form of necessary waste. Work on gradually reducing the percentage of time you spend planning. (p. 46)
Y que hables con el cliente!
> The objection I hear to customer involvement is that someone will get exactly the system he wants, but the system won't be suitable for anyone else. It's easier to generalize a successful system that to specialize a system that doesn't solve anyone's problem (p. 62)
^0304ba
> The sausage factory (…) 'if the customer knew how messed up software development was, they'd never trust us'. Are you sure they trust you now?. Software reflects the organization that builds it. The customers are already using the software so they already know a lot about how you develop. (…) When you act trustworthy and have nothing to hide, you are more productive." (p. 62)
^37b65b
# Conclusión
Hay ciertos libros que uno sufre mucho para resumirlos, porque hay poca paja que recortar ([Bauman, no se me ocurre resumir ningún libro tuyo más](https://www.notion.so/drmario/Liquid-Life-c50415b7f09247d2a0a7115e8d169c2a)). Más que resúmenes, son retrabajos, re-organizaciones con el objetivo de asimilarlos mejor. Éste es claramente uno: no le sobra nada, y me explota la cabeza lo bueno que es Kent Beck anticipándose a las cuestiones que como lector vas a ir teniendo, y, especialmente, lo adelantado que iba Beck en algunas cuestiones (y lo que se moja).
En cuanto a XP, es la primera vez que estoy en una organización que lo usa (vs. procesos "Scrum-like"), con lo que solo tengo las impresiones que me causa lo que he leído. Recuerdo que cuando solo lo conocía superficialmente, o hacía prácticas esporádicas (algún pair programming tonto por ahí), me generaba bastante rechazo. Ahora que creo que lo entiendo mejor, mi sensación es que es un sistema muy coherente, que suena muy bien y que si se hace bien, tiene pinta de permitir niveles de rendimiento que serían difíciles de otra manera. PERO, sí que creo que es difícil hacerlo bien. Es decir, un equipo haciendo XP “a medio gas”, puede ser mucho más mediocre que un equipo sin XP. Es una apuesta valiente, pero que con un compromiso fuerte, tiene pinta de que marque muchísimo la diferencia.