Machine Translated by Google

Machine Translated by Google

Elogios para The Clean Coder

“'Uncle Bob' Martin definitivamente sube el listón con su último libro. Explica sus expectativas para un
programador profesional en cuanto a las interacciones de gestión, la gestión del tiempo, la presión,
la colaboración y la elección de las herramientas a utilizar. Más allá de TDD y ATDD, Martin explica lo
que todo programador que se considera un profesional no sólo necesita saber, sino que también debe
seguir para hacer crecer la joven profesión del desarrollo de software”.

—Markus Gartner

Desarrollador de software sénior

it­ágil GmbH
[Link]­[Link]
[Link]

“Algunos libros técnicos inspiran y enseñan; algo de deleite y diversión. Rara vez un libro técnico hace
estas cuatro cosas. Robert Martin siempre lo ha hecho para mí y The Clean Coder no es una excepción.
Lea, aprenda y viva las lecciones de este libro y podrá considerarse con precisión un profesional del
software”.

—George Bullock
Gerente sénior de programas
Microsoft Corp.

“Si una carrera en informática hubiera 'requerido lectura después de graduarse', sería esta. En el
mundo real, tu código incorrecto no desaparece cuando termina el semestre, no obtienes una A en
codificación maratónica la noche anterior a la entrega de una tarea y, lo peor de todo, tienes que tratar
con personas. Entonces, los gurús de la codificación no son necesariamente profesionales. The Clean
Coder describe el viaje hacia el profesionalismo. . . y hace un trabajo notablemente entretenido”.

—Jeff Overbey
Universidad de Illinois en Urbana­Champaign

“El Clean Coder es mucho más que un conjunto de reglas o directrices. Contiene sabiduría y
conocimientos ganados con esfuerzo que normalmente se obtienen a través de muchos años de
prueba y error o trabajando como aprendiz de un maestro artesano. Si se considera un profesional
del software, necesita este libro”.

—RL Bogetti
Diseñador líder de sistemas
Salud Baxter

[Link]
Machine Translated by Google

Esta página se dejó en blanco intencionalmente.

Machine Translated by Google

El codificador limpio
Machine Translated by Google

La serie de Robert C. Martin

Visite [Link]/martinseries para obtener una lista completa de las publicaciones disponibles.

La serie Robert
líderes, C. Martin
analistas deestá dirigiday agerentes
negocios desarrolladores de software,
que desean aumentarequipos
sus
habilidades y competencias al nivel de un maestro artesano. La serie contiene
libros que guían a los profesionales del software en los principios,
patrones y prácticas de programación, gestión de proyectos de software,
recopilación de requisitos, diseño, análisis, pruebas y otros.
Machine Translated by Google

El codificador limpio
UN CÓDIGO DE CONDUCTA PARA
PROGRAMADORES PROFESIONALES

Roberto C. Martín

Upper Saddle River, Nueva Jersey • Boston • Indianápolis • San Francisco

Nueva York • Toronto • Montreal • Londres • Múnich • París • Madrid

Ciudad del Cabo • Sídney • Tokio • Singapur • Ciudad de México

Machine Translated by Google

Muchas de las designaciones utilizadas por fabricantes y vendedores para distinguir sus productos se consideran marcas comerciales.
Cuando esas designaciones aparecen en este libro y el editor tenía conocimiento de un reclamo de marca registrada, las designaciones
se imprimieron con letras mayúsculas iniciales o en mayúsculas.

El autor y el editor han tenido cuidado en la preparación de este libro, pero no ofrecen garantía expresa o implícita de ningún tipo y
no asumen responsabilidad por errores u omisiones. No se asume ninguna responsabilidad por daños incidentales o consecuentes
relacionados con o que surjan del uso de la información o los programas contenidos en este documento.

El editor ofrece excelentes descuentos en este libro cuando se solicita en cantidad para compras al por mayor o ventas especiales,
que pueden incluir versiones electrónicas y/o portadas personalizadas y contenido específico para su negocio, objetivos de capacitación,
enfoque de marketing e intereses de marca. Para obtener más información, póngase en contacto con:

Ventas corporativas y gubernamentales de EE.

UU. (800) 382­3419
corpsales@[Link]

Para ventas fuera de los Estados Unidos, comuníquese con:

Ventas Internacionales

internacional@[Link]

Visítenos en la Web: [Link]/ph

Datos de catalogación en publicación de la Biblioteca del Congreso

Martín, Roberto C.
El codificador limpio: un código de conducta para programadores profesionales / Robert Martin.
pag. centímetro.

Incluye referencias bibliográficas e índice.

ISBN 0­13­708107­3 (pbk.: papel alk.)
1. Programación de computadoras—Aspectos morales y éticos. 2. Programadores
informáticos. Ética profesional. I. Título.
QA76.9.M65M367 2011
005.1092—dc22 2011005962

Copyright © 2011 Pearson Education, Inc.

Reservados todos los derechos. Impreso en los Estados Unidos de América. Esta publicación está protegida por derechos de autor y se debe
obtener permiso del editor antes de cualquier reproducción prohibida, almacenamiento en un sistema de recuperación o transmisión en cualquier
forma o por cualquier medio, ya sea electrónico, mecánico, fotocopia, grabación o similar. Para información sobre permisos escribir a:

Educación Pearson, Inc.

Departamento de Derechos y Contratos 501
Boylston Street, Suite 900 Boston, MA
02116 Fax: (617)
671­3447

ISBN­13: 978­0­13­708107­3
ISBN­10: 0­13­708107­3

Texto impreso en Estados Unidos en papel reciclado en RR Donnelley en Crawfordsville, Indiana.

Primera impresión, mayo de 2011.
Machine Translated by Google

Entre 1986 y 2000 trabajé estrechamente con Jim Newkirk, un colega de Teradyne.
Él y yo compartíamos la pasión por la programación y el código limpio.
Pasábamos noches, tardes y fines de semana juntos jugando con diferentes estilos de
programación y técnicas de diseño. Estábamos continuamente intrigando sobre
ideas de negocios. Finalmente formamos juntos Object Mentor, Inc..
Aprendí muchas cosas de Jim mientras llevábamos a cabo nuestros planes juntos.
Pero uno de los más importantes fue su actitud de ética de trabajo; era algo que me
esforzaba por emular. Jim es un profesional. Estoy orgulloso de haber trabajado con él
y de llamarlo mi amigo.
Machine Translated by Google

Esta página se dejó en blanco intencionalmente.

Machine Translated by Google

CONTENIDO

Prefacio xiii
Prefacio xix
Expresiones de gratitud xxiii
Sobre el autor xxxx
En la portada xxxi

Introducción previa al requisito 1

Capítulo 1 Profesionalismo 7
Ten cuidado con lo que pides 8

Asumir la responsabilidad 8

Primero, no hacer daño 11

Ética de trabajo 16

Bibliografía 22

Capítulo 2 Decir no 23
Roles adversarios 26

Hay mucho en juego 29

Ser un “jugador de equipo” 30

El costo de decir sí 36

Código imposible 41

ix
Machine Translated by Google

CONTENIDO

Capítulo 3 Decir si 45
Un lenguaje de compromiso 47

Aprender a decir "sí" 52

Conclusión 56

Capítulo 4 Codificación 57
Preparación 58
La zona de flujo 62
Bloqueo del escritor 64

Depuración 66

Tomar tu propio ritmo 69

Llegar tarde 71

Ayuda 73

Bibliografía 76

Capítulo 5 Desarrollo basado en pruebas 77

El jurado está en 79
Las tres leyes del TDD 79
Lo que no es TDD 83

Bibliografía 84

Capítulo 6 Práctica 85
Algunos antecedentes sobre la práctica 86

El dojo de codificación 89

Ampliando su experiencia 93
Conclusión 94

Bibliografía 94

Capítulo 7 Pruebas de aceptación 95

Requisitos de comunicación 95

Pruebas de aceptación 100

Conclusión 111

Capítulo 8 Estrategias de prueba 113

El control de calidad no debería encontrar nada 114

incógnita
Machine Translated by Google

CONTENIDO

La pirámide de automatización de pruebas 115

Conclusión 119

Bibliografía 119

Capítulo 9 Gestión del tiempo 121

Reuniones 122
Enfoque­maná 127

Time Boxing y tomates 130

Evitación 131

Callejones sin salida 131

Marismas, ciénagas, pantanos y otros desastres 132

Conclusión 133

Capítulo 10 Estimación 135

¿Qué es una estimación? 138
IMPERTINENTE 141

Estimación de tareas 144

La ley de los grandes números 147

Conclusión 147

Bibliografía 148

Capítulo 11 Presión 149

Evitar la presión 151

Manejo de la presión 153

Conclusión 155

Capítulo 12 Colaboración 157

Programadores versus personas 159
Cerebelos 164
Conclusión 166

Capítulo 13 Equipos y proyectos ¿Se combinan? 167

168
Conclusión 171

Bibliografía 171

xi
Machine Translated by Google

CONTENIDO

Capítulo 14 Tutoría, aprendizaje y artesanía 173

Grados de fracaso 174

tutoría 174

Aprendizaje 180

Artesanía 184
Conclusión 185

Apéndice A Herramientas 187

Herramientas 189
Control de código fuente 189
IDE/Editor 194

Seguimiento de problemas 196

Construcción continua 197

Herramientas de prueba unitaria 198

Herramientas de prueba de componentes 199

Herramientas de prueba de integración 200

UML/MDA 201
Conclusión 204

Índice 205

xiii
Machine Translated by Google

PREFACIO

Ha leído este libro, así que supongo que es un profesional del software. Eso es bueno; Yo
también. Y ya que tengo tu atención, déjame decirte por qué elegí este libro.

Todo empieza hace poco tiempo en un lugar no muy lejano. Cue el telón, las luces y la cámara, Charley….

Hace varios años trabajaba en una corporación mediana que vendía productos altamente regulados. Ya
conoces el tipo; Nos sentábamos en una granja de cubículos en un edificio de tres pisos, los directores y
superiores tenían oficinas privadas, y reunir a todos los que necesitaba en la misma sala para una reunión
tomó aproximadamente una semana.

Estábamos operando en un mercado muy competitivo cuando el gobierno abrió un nuevo producto.

De repente teníamos un conjunto completamente nuevo de clientes potenciales; todo lo que teníamos
que hacer era conseguir que compraran nuestro producto. Eso significaba que teníamos que presentar
la solicitud ante el gobierno federal en una fecha límite determinada, pasar una auditoría de evaluación en
otra fecha y salir al mercado en una tercera fecha.

xiii
Machine Translated by Google

PREFACIO

Una y otra vez nuestra dirección nos destacó la importancia de esas fechas. Un solo desliz
y el gobierno nos mantendría fuera del mercado durante un año, y si los clientes no pudieran
registrarse el primer día, entonces se registrarían con otra persona y nos quedaríamos sin
negocio.

Era el tipo de ambiente en el que algunas personas se quejan y otras señalan que “la
presión hace diamantes”.

Fui responsable técnico de proyectos, ascendido desde desarrollo. Mi responsabilidad era poner
en funcionamiento el sitio web el día de su lanzamiento, para que los clientes potenciales
pudieran descargar información y, lo más importante, formularios de inscripción. Mi socio en el
esfuerzo fue el director del proyecto empresarial, a quien llamaré Joe. El papel de Joe era
trabajar en el otro lado, ocupándose de las ventas, el marketing y los requisitos no técnicos.
También era el tipo al que le gustaba el comentario de "la presión hace diamantes".

Si ha trabajado mucho en las empresas estadounidenses, probablemente haya visto las

acusaciones, las críticas y la aversión al trabajo que son completamente naturales.
Nuestra empresa tenía una solución interesante a ese problema entre Joe y yo.

Un poco como Batman y Robin, nuestro trabajo era hacer las cosas. Me reunía con el equipo
técnico todos los días en un rincón; Reconstruiríamos el cronograma todos los días,
descubriríamos el camino crítico y luego eliminaríamos todos los obstáculos posibles de ese
camino crítico. Si alguien necesitaba software; iríamos a buscarlo. Si les “encantaría” configurar
el firewall pero “Dios, es hora de almorzar”, les invitaríamos a almorzar. Si alguien quisiera
trabajar en nuestro ticket de configuración pero tuviera otras prioridades, Joe y yo iríamos a
hablar con el supervisor.

Luego el gerente.

Luego el director.

Hicimos las cosas.

Es un poco exagerado decir que pateamos sillas, gritamos y gritamos, pero usamos
todas las técnicas que teníamos en el bolso para hacer las cosas, inventamos algunas nuevas
en el camino y lo hicimos de manera ética. forma de la que estoy orgulloso hasta el día de hoy.

xiv
Machine Translated by Google

PREFACIO

Me consideraba un miembro del equipo, no por encima de lanzarme a escribir una declaración SQL o hacer
un pequeño emparejamiento para sacar el código. En ese momento, pensaba en Joe de la misma manera,
como un miembro del equipo, no por encima de él.

Con el tiempo me di cuenta de que Joe no compartía esa opinión. Ese fue un día muy triste para mí.

Era viernes a las 13:00 horas; El sitio web estaba programado para funcionar muy temprano el lunes siguiente.

Habíamos terminado. *HECHO*. Todos los sistemas estaban funcionando; estábamos listos. Reuní a todo
el equipo técnico para la reunión final de scrum y estábamos listos para accionar el interruptor. Más que
“solo” el equipo técnico, teníamos con nosotros a la gente de negocios de marketing, los propietarios de
productos.

Estábamos orgullosos. Fue un buen momento.

Entonces Joe pasó por aquí.

Dijo algo como: “Malas noticias. Legal no tiene los formularios de inscripción listos, por lo que no podemos
comenzar a funcionar todavía”.

Esto no fue gran cosa; Nos habíamos visto retenidos por una cosa u otra durante todo el proyecto y teníamos
la rutina de Batman/Robin controlada. Estaba listo y mi respuesta fue esencialmente: “Está bien socio,
hagamos esto una vez más.
Legal está en el tercer piso, ¿verdad?

Entonces las cosas se pusieron raras.

En lugar de estar de acuerdo conmigo, Joe preguntó: "¿De qué estás hablando Matt?"

Le dije: “Ya sabes. Nuestro canto y baile de siempre. Estamos hablando de cuatro archivos PDF,
¿verdad? Eso está hecho; ¿Legal solo tiene que aprobarlos? ¡Vamos a pasar el rato en sus cubículos,
darles el mal de ojo y terminar esto !

Joe no estuvo de acuerdo con mi evaluación y respondió: “Estaremos en funcionamiento a fines de la próxima
semana. No es gran cosa”.

xvi
Machine Translated by Google

PREFACIO

Probablemente puedas adivinar el resto del intercambio; sonaba algo como esto:

Matt: “¿Pero por qué? Podrían hacer esto en un par de horas”.

Joe: "Quizás haga falta más que eso".

Matt: “Pero tienen todo el fin de semana. Mucho tiempo. ¡Hagamos esto!

Joe: “Matt, estos son profesionales. No podemos simplemente mirarlos fijamente e insistir
en que sacrifiquen sus vidas personales por nuestro pequeño proyecto”.

Matt: (pausa) “. . . José . . . ¿Qué crees que le hemos estado haciendo al equipo de
ingeniería durante los últimos cuatro meses?

Joe: "Sí, pero estos son profesionales".

Pausa.

Respirar.

Qué. Hizo. José. Justo. ¿Decir?

En ese momento pensé que el personal técnico eran profesionales, en el mejor sentido de la
palabra.

Sin embargo, pensándolo bien, no estoy tan seguro.

Veamos esa técnica de Batman y Robin por segunda vez, desde una perspectiva diferente. Pensé
que estaba exhortando al equipo a lograr su mejor desempeño, pero sospecho que Joe estaba
jugando un juego, con la suposición implícita de que el cuerpo técnico era su oponente. Piénselo:
¿por qué era necesario correr, patear sillas y apoyarse en la gente?

¿No deberíamos haber podido preguntarle al personal cuándo terminarían, obtener una
respuesta firme, creer en la respuesta que nos dieron y no quemarnos con esa creencia?

Ciertamente, para los profesionales, deberíamos. . . y, al mismo tiempo, no pudimos.

Joe no confió en nuestras respuestas y se sintió cómodo microgestionando la tecnología.

xvi
Machine Translated by Google

PREFACIO

equipo—y al mismo tiempo, por alguna razón, confiaba en el equipo legal y no estaba
dispuesto a microgestionarlos.

¿A qué se debe todo eso?

De alguna manera, el equipo legal había demostrado profesionalismo de una manera que el
equipo técnico no había demostrado.

De alguna manera, otro grupo había convencido a Joe de que no necesitaban una niñera, que
no estaban jugando y que debían ser tratados como compañeros respetados.

No, no creo que tuviera nada que ver con certificados elegantes colgados en las paredes o con
unos cuantos años extra de universidad, aunque esos años de universidad podrían
haber incluido bastante entrenamiento social implícito sobre cómo comportarse.

Desde aquel día, hace tantos años, me he preguntado cómo tendría que cambiar la
profesión técnica para ser considerada profesional.

Oh, tengo algunas ideas. Escribí un poco en blogs, leí mucho, logré mejorar mi propia
situación de vida laboral y ayudé a algunos otros. Sin embargo, no conocía ningún libro que
estableciera un plan, que hiciera todo explícito.

Entonces, un día, de la nada, recibí una oferta para revisar el primer borrador de un libro; el
libro que tienes en tus manos ahora mismo.

Este libro le dirá paso a paso exactamente cómo presentarse e interactuar como profesional.
No con clichés trillados, no con apelaciones a trozos de papel, sino con lo que se puede hacer
y cómo hacerlo.

En algunos casos, los ejemplos son palabra por palabra.

Algunos de esos ejemplos tienen respuestas, contrarrespuestas, aclaraciones e incluso consejos

sobre qué hacer si la otra persona intenta "simplemente ignorarte".

xvii
Machine Translated by Google

PREFACIO

Oye, mira eso, aquí viene Joe otra vez, esta vez a la izquierda del escenario:

Oh, aquí estamos, de vuelta en BigCo, con Joe y conmigo, una vez más en el gran proyecto de
conversión de un sitio web.

Sólo que esta vez imagínalo un poco diferente.

En lugar de eludir compromisos, el personal técnico los asume.

En lugar de eludir las estimaciones o dejar que otra persona haga la planificación (y
luego quejarse), el equipo técnico en realidad se autoorganiza y asume compromisos
reales.

Ahora imagine que el personal realmente está trabajando en conjunto. Cuando los programadores se
ven bloqueados por las operaciones, levantan el teléfono y el administrador del sistema comienza a
trabajar.

Cuando Joe viene a encender un fuego para arreglar el ticket 14321, no es necesario; puede ver que el
DBA está trabajando diligentemente, no navegando por la web. Del mismo modo, las estimaciones que
recibe del personal parecen francamente consistentes y no tiene la sensación de que el proyecto
tenga una prioridad en algún lugar entre el almuerzo y la consulta del correo electrónico.
Todos los trucos e intentos de manipular el cronograma no se responden con un “Lo intentaremos”,
sino con un “Ese es nuestro compromiso; Si quieres crear tus propios objetivos, siéntete libre”.

Después de un tiempo, sospecho que Joe comenzaría a pensar en el equipo técnico como en
profesionales. Y tendría razón.

¿Esos pasos para transformar tu comportamiento de técnico a profesional? Los encontrará

en el resto del libro.

Bienvenido al siguiente paso en su carrera; Sospecho que te va a gustar.

—Matthew Heusser

Naturalista de procesos de software

xviii
Machine Translated by Google

PREFACIO

A las 11:39 am EST del 28 de enero de 1986, sólo 73,124 segundos después del
lanzamiento y a una altitud de 48.000 pies, el transbordador espacial Challenger quedó
hecho añicos por la falla del propulsor de cohete sólido (SRB) derecho. Siete valientes
astronautas, entre ellos la profesora de secundaria Christa McAuliffe, se perdieron. La
expresión del rostro de la madre de McAuliffe mientras contemplaba la muerte de su hija
a nueve millas de altura me persigue hasta el día de hoy.

El Challenger se desintegró porque los gases de escape calientes del SRB defectuoso
se escaparon entre los segmentos de su casco, salpicando el cuerpo del

xix
Machine Translated by Google

PREFACIO

tanque de combustible externo. El fondo del tanque principal de hidrógeno líquido explotó,
encendiendo el combustible y empujando el tanque hacia adelante para estrellarse contra el
tanque de oxígeno líquido que estaba encima. Al mismo tiempo, el SRB se desprendió de su

puntal trasero y giró alrededor de su puntal delantero. Su morro perforó el tanque de oxígeno
líquido. Estos vectores de fuerza aberrantes provocaron que toda la nave, que se movía muy por
encima de mach 1,5, girara contra la corriente de aire. Las fuerzas aerodinámicas rápidamente
hicieron trizas todo.

Entre los segmentos circulares del SRB se encontraban dos juntas tóricas concéntricas de caucho
sintético. Cuando los segmentos se atornillaron, las juntas tóricas se comprimieron, formando
un sello hermético que los gases de escape no deberían haber podido penetrar.

Pero la noche anterior al lanzamiento, la temperatura en la plataforma de lanzamiento bajó a

17°F, 23 grados por debajo de la temperatura mínima especificada por las juntas tóricas y 33
grados por debajo de cualquier lanzamiento anterior. Como resultado, las juntas tóricas se
volvieron demasiado rígidas para bloquear adecuadamente los gases calientes. Al encenderse el
SRB se produjo un pulso de presión a medida que los gases calientes se acumulaban
rápidamente. Los segmentos del propulsor se hincharon hacia afuera y relajaron la compresión
en las juntas tóricas. La rigidez de las juntas tóricas les impidió mantener el sello hermético, por
lo que algunos de los gases calientes se filtraron y vaporizaron las juntas tóricas a lo largo de 70
grados de arco.

Los ingenieros de Morton Thiokol que diseñaron el SRB sabían que había problemas con las juntas
tóricas y habían informado de esos problemas a los gerentes de Morton Thiokol y la NASA
siete años antes. De hecho, las juntas tóricas de lanzamientos anteriores habían resultado dañadas
de manera similar, aunque no lo suficiente como para ser catastróficas. El lanzamiento más frío
había sufrido los mayores daños. Los ingenieros habían diseñado una reparación para el problema,
pero su implementación se había retrasado mucho.

Los ingenieros sospecharon que las juntas tóricas se endurecían con el frío. También sabían que
las temperaturas para el lanzamiento del Challenger eran más frías que cualquier lanzamiento
anterior y muy por debajo de la línea roja. En resumen, los ingenieros sabían que el riesgo era
demasiado alto. Los ingenieros actuaron basándose en ese conocimiento. escribieron notas

xx
Machine Translated by Google

PREFACIO

levantando gigantescas banderas rojas. Instaron encarecidamente a Thiokol y a los directivos de la

NASA a no realizar el lanzamiento. En una reunión de última hora celebrada pocas horas antes
del lanzamiento, esos ingenieros presentaron sus mejores datos. Se enfurecieron, engatusaron y
protestaron. Pero al final, los directivos los ignoraron.

Cuando llegó el momento del lanzamiento, algunos de los ingenieros se negaron a ver la
transmisión porque temían una explosión en la plataforma. Pero cuando el Challenger ascendió
con gracia hacia el cielo, empezaron a relajarse. Momentos antes de la destrucción,
mientras veían pasar el vehículo por Mach 1, uno de ellos dijo que habían “esquivado una bala”.

A pesar de todas las protestas, memorandos e insistencias de los ingenieros, los gerentes creían
que sabían más. Pensaron que los ingenieros estaban exagerando. No confiaban en los datos de
los ingenieros ni en sus conclusiones. Se lanzaron porque estaban bajo una inmensa presión
financiera y política. Esperaban que todo estuviera bien.

Estos directivos no sólo eran tontos, sino también criminales. Las vidas de siete buenos hombres y
mujeres, y las esperanzas de una generación que miraba hacia los viajes espaciales, se
desvanecieron esa fría mañana porque esos gerentes antepusieron sus propios miedos, esperanzas
e intuiciones a las palabras de sus propios expertos. Tomaron una decisión que no tenían derecho
a tomar. Usurparon la autoridad de quienes realmente sabían: los ingenieros.

Pero ¿qué pasa con los ingenieros? Ciertamente los ingenieros hicieron lo que se suponía
que debían hacer. Informaron a sus superiores y lucharon duramente por su puesto.
Pasaron por los canales apropiados e invocaron todos los protocolos correctos. Hicieron lo que
pudieron, dentro del sistema, y aun así los gerentes los ignoraron. Así pues, parecería que los
ingenieros pueden salir airosos del asunto.

Pero a veces me pregunto si alguno de esos ingenieros permaneció despierto por la noche,
atormentado por esa imagen de la madre de Christa McAuliffe, y deseando haber llamado a Dan
Rather.

xxi
Machine Translated by Google

PREFACIO

ACERCA DE ESTE LIBRO

Este libro trata sobre el profesionalismo del software. Contiene muchos consejos pragmáticos
en un intento de responder preguntas, como

• ¿Qué es un profesional del software?

• ¿Cómo se comporta un profesional?

• ¿Cómo aborda un profesional los conflictos, los horarios ajustados y las situaciones irrazonables?
gerentes?

• ¿ Cuándo y cómo debe un profesional decir “no”?

• ¿Cómo afronta un profesional la presión?

Pero, escondida detrás de los consejos pragmáticos de este libro, encontrará una actitud que
lucha por abrirse paso. Es una actitud de honestidad, de honor, de respeto por uno mismo
y de orgullo. Es la voluntad de aceptar la terrible responsabilidad de ser artesano e ingeniero. Esa
responsabilidad incluye trabajar bien y trabajar limpio. Incluye comunicarse bien y estimar
fielmente. Incluye administrar su tiempo y enfrentar decisiones difíciles de riesgo­recompensa.

Pero esa responsabilidad incluye otra cosa, una cosa aterradora. Como ingeniero, usted tiene un conocimiento

profundo sobre sus sistemas y proyectos que ningún gerente podría tener. Ese conocimiento conlleva la

responsabilidad de actuar.

BIBLIOGRAFÍA

[McConnell87]: Malcolm McConnell, Challenger 'Un mal funcionamiento importante', nuevo

York, Nueva York: Simon & Schuster, 1987
[Wiki­Challenger]: “Desastre del transbordador espacial Challenger”

[Link]

XXII
Machine Translated by Google

EXPRESIONES DE GRATITUD

Mi carrera ha sido una serie de colaboraciones y esquemas. Aunque he tenido

muchos sueños y aspiraciones privadas, siempre parecía encontrar a alguien con quien
compartirlos. En ese sentido me siento un poco como los Sith: “Siempre hay dos”.

La primera colaboración que pude considerar profesional fue con John

Marchese a la edad de 13 años. Él y yo planeamos construir computadoras
juntos. Yo era el cerebro y él era la fuerza. Le mostré dónde soldar un cable y lo soldó.
Le mostré dónde montar un relé y lo montó. Fue muy divertido y pasamos cientos de
horas haciéndolo. De hecho, construimos bastantes objetos de aspecto impresionante
con relés, botones, luces e incluso teletipos. Por supuesto, ninguno de ellos hizo
nada, pero fueron muy impresionantes y trabajamos muy duro en ellos. A Juan:
¡Gracias!

En mi primer año de secundaria conocí a Tim Conrad en mi clase de alemán.

Tim era inteligente. Cuando nos asociamos para construir una computadora, él era el
cerebro y yo la fuerza. Me enseñó electrónica y me dio mi primera introducción a un
PDP­8. De hecho, él y yo construimos una calculadora binaria electrónica de 18 bits
que funciona a partir de componentes básicos. Podría sumar, restar, multiplicar y dividir.
Nos tomó un año de fines de semana y todas las vacaciones de primavera, verano y
Navidad. Trabajamos furiosamente en ello. Al final, funcionó muy bien. A Tim: ¡Gracias!

xxiii
Machine Translated by Google

EXPRESIONES DE GRATITUD

Tim y yo aprendimos a programar computadoras. Esto no fue fácil de lograr en 1968, pero lo
logramos. Conseguimos libros sobre ensamblador PDP­8, Fortran, Cobol, PL/1, entre otros.
Los devoramos. Escribimos programas que no teníamos esperanzas de ejecutar porque no
teníamos acceso a una computadora. Pero los escribimos de todos modos por puro amor.

Nuestra escuela secundaria comenzó un plan de estudios de informática en nuestro segundo año.
Conectaron un teletipo ASR­33 a un módem de acceso telefónico de 110 baudios. Tenían una
cuenta en el sistema de tiempo compartido Univac 1108 en el Instituto de Tecnología de Illinois.
Tim y yo inmediatamente nos convertimos en los operadores de facto de esa máquina.
Nadie más podría acercarse a él.

El módem se conectó levantando el teléfono y marcando el número. Cuando escuchó el

chirrido del módem de respuesta, presionó el botón "orig" en el Teletipo, lo que provocó que el
módem de origen emitiera su propio chirrido.
Luego colgó el teléfono y se estableció la conexión de datos.

El teléfono tenía un candado en el dial. Sólo los profesores tenían la llave. Pero eso no
importó, porque aprendimos que se podía marcar un teléfono (cualquier teléfono) marcando
el número de teléfono en el interruptor. Yo era baterista, así que tenía bastante buena
sincronización y reflejos. Podría marcar ese módem, con el bloqueo puesto, en menos de 10
segundos.

Teníamos dos teletipos en el laboratorio de computación. Una era la máquina en línea y la otra era
una máquina fuera de línea. Ambos fueron utilizados por los estudiantes para escribir
sus programas. Los estudiantes escribirían sus programas en los teletipos con la perforadora
de cinta de papel activada. Cada pulsación de tecla fue grabada en cinta. Los estudiantes
escribieron sus programas en IITran, un lenguaje interpretado notablemente poderoso.
Los estudiantes dejaban sus cintas de papel en una canasta cerca de los Teletipos.

Después de la escuela, Tim y yo marcábamos la computadora (haciendo tapping, por

supuesto), cargábamos las cintas en el sistema por lotes IITran y luego colgábamos. A 10
caracteres por segundo, este no fue un procedimiento rápido. Aproximadamente una hora
después, volvíamos a llamar y obteníamos las impresiones, nuevamente a 10 caracteres por
segundo. El Teletipo no separó los listados de los estudiantes expulsando páginas. Simplemente se imprimió un

XXIV
Machine Translated by Google

EXPRESIONES DE GRATITUD

después del siguiente, así que los cortamos con tijeras, sujetamos con un clip la cinta de
papel de entrada a su lista y los colocamos en la cesta de salida.

Tim y yo éramos los amos y dioses de ese proceso. Incluso los profesores nos dejaban solos
cuando estábamos en ese salón. Estábamos haciendo su trabajo y ellos lo sabían.
Nunca nos pidieron que lo hiciéramos. Nunca nos dijeron que podíamos. Nunca nos dieron
la llave del teléfono. Nosotros acabamos de mudarnos y ellos se mudaron, y nos dieron una
correa muy larga. A mis profesores de matemáticas, el Sr. McDermit, el Sr. Fogel y el Sr.
Robien: ¡Gracias!

Luego, después de que todos los deberes de los estudiantes estuvieran hechos,
jugábamos. Escribimos programa tras programa para hacer cualquier cantidad de cosas raras
y locas. Escribimos programas que graficaban círculos y parábolas en ASCII en un teletipo.
Escribimos programas de paseos aleatorios y generadores de palabras aleatorias. Calculamos
50 factoriales hasta el último dígito. Pasamos horas y horas inventando programas para
escribir y luego hacerlos funcionar.

Dos años más tarde, Tim, nuestro compadre Richard Lloyd y yo fuimos contratados
como programadores en ASC Tabulated en Lake Bluff, Illinois. Tim y yo teníamos 18 años en
ese momento. Habíamos decidido que la universidad era una pérdida de tiempo y que debíamos
comenzar nuestras carreras de inmediato. Fue aquí donde conocimos a Bill Hohri, Frank
Ryder, Big Jim Carlin y John Miller. Dieron a algunos jóvenes la oportunidad de aprender
de qué se trata la programación profesional. La experiencia no fue del todo positiva ni del todo
negativa. Sin duda fue educativo. A todos ellos y a Richard, que catalizó e impulsó gran parte
de ese proceso: gracias.

Después de dejar de fumar y derrumbarme a la edad de 20 años, trabajé una temporada como
reparador de cortadoras de césped para mi cuñado. Se me daba tan mal que tuvo que
despedirme. ¡Gracias Wes!

Aproximadamente un año después terminé trabajando en Outboard Marine Corporation. En

ese momento yo estaba casado y tenía un bebé en camino. A mí también me despidieron.
¡Gracias, John, Ralph y Tom!

xxvi
Machine Translated by Google

EXPRESIONES DE GRATITUD

Luego fui a trabajar a Teradyne, donde conocí a Russ Ashdown, Ken Finder, Bob Copithorne,
Chuck Studee y CK Srithran (ahora Kris Iyer). Ken era mi jefe.
Chuck y CK eran mis amigos. Aprendí mucho de todos ellos. ¡Gracias chicos!

Luego estaba Mike Carew. En Teradyne, él y yo nos convertimos en el dúo dinámico.

Escribimos varios sistemas juntos. Si querías hacer algo y hacerlo rápido, conseguías que
Bob y Mike lo hicieran. Nos divertimos mucho juntos.
¡Gracias mike!

Jerry Fitzpatrick también trabajó en Teradyne. Nos conocimos mientras jugábamos juntos
a Dungeons & Dragons, pero rápidamente formamos una colaboración. Escribimos software
en un Commodore 64 para apoyar a los usuarios de D&D. También iniciamos un
nuevo proyecto en Teradyne llamado "La Recepcionista Electrónica". Trabajamos juntos
durante varios años y él se convirtió, y sigue siendo, un gran amigo. ¡Gracias, Jerry!

Pasé un año en Inglaterra mientras trabajaba para Teradyne. Allí me asocié con Mike
Kergozou. Él y yo planificamos juntos todo tipo de cosas, aunque la mayoría de esos planes
tenían que ver con bicicletas y pubs. Pero era un programador dedicado que estaba muy
centrado en la calidad y la disciplina (aunque quizás no estuviera de acuerdo). ¡Gracias mike!

Al regresar de Inglaterra en 1987, comencé a conspirar con Jim Newkirk. Ambos dejamos
Teradyne (con meses de diferencia) y nos unimos a una nueva empresa llamada
Clear Communications. Pasamos varios años juntos allí, trabajando duro para ganar los
millones que nunca llegaron. Pero continuamos con nuestras intrigas. ¡Gracias Jim!

Al final fundamos juntos Object Mentor. Jim es la persona más directa, disciplinada
y centrada con la que he tenido el privilegio de trabajar.
Me enseñó tantas cosas que no puedo enumerarlas aquí. En cambio, le he dedicado
este libro.

Hay tantas otras personas con las que he conspirado, tantas otras con las que he
colaborado, tantas otras que han tenido un impacto en mi vida profesional: Lowell
Lindstrom, Dave Thomas, Michael Feathers, Bob Koss, Brett Schuchert, Dean
Wampler, Pascal Roy, Jeff Langr, James Grenning, Brian Button, Alan Francis,

xxvi
Machine Translated by Google

EXPRESIONES DE GRATITUD

Mike Hill, Eric Meade, Ron Jeffries, Kent Beck, Martin Fowler, Grady Booch y una lista
interminable de otros. Gracias a todos y cada uno.

Por supuesto, la mayor colaboradora de mi vida ha sido mi encantadora esposa, Ann

Marie. Me casé con ella cuando tenía 20 años, tres días después de que ella cumpliera 18.
Durante 38 años ella ha sido mi compañera constante, mi timón y mi vela, mi amor y mi
vida. Espero pasar otras cuatro décadas con ella.

Y ahora, mis colaboradores y socios intrigantes son mis hijos. Trabajo en estrecha
colaboración con mi hija mayor Ángela, mi encantadora mamá gallina e intrépida
asistente. Ella me mantiene en el buen camino y nunca me deja olvidar una cita o un
compromiso. Planifico planes de negocios con mi hijo Micah, el fundador de [Link].
Su cabeza para los negocios es mucho mejor que la mía. ¡Nuestra última empresa,
[Link], es muy emocionante!

Mi hijo menor, Justin, acaba de empezar a trabajar con Micah en 8th Light. Mi hija menor,
Gina, es ingeniera química y trabaja para Honeywell. ¡Con esos dos, los planes serios
apenas comienzan!

Nadie en tu vida te enseñará más que tus hijos. ¡Gracias, niños!

xxvii
Machine Translated by Google

Esta página se dejó en blanco intencionalmente.

Machine Translated by Google

SOBRE EL AUTOR

Robert C. Martin (“Tío Bob”) ha sido programador desde 1970. Es fundador y presidente
de Object Mentor, Inc., una firma internacional de desarrolladores y administradores de
software altamente experimentados que se especializan en ayudar a las empresas a
realizar sus proyectos. Object Mentor ofrece consultoría de mejora de procesos, consultoría
de diseño de software orientado a objetos, capacitación y servicios de desarrollo de
habilidades a las principales corporaciones de todo el mundo.

Martin ha publicado decenas de artículos en diversas revistas especializadas y es

ponente habitual en conferencias y ferias comerciales internacionales.

Es autor y editor de numerosos libros, entre ellos:

• Diseño de aplicaciones C++ orientadas a objetos utilizando el método Booch

• Patrones Lenguajes de Diseño de Programas 3

xxxx
Machine Translated by Google

SOBRE EL AUTOR

• Más gemas de C++

• Programación extrema en la práctica

• Desarrollo ágil de software: principios, patrones y prácticas

• UML para programadores de Java

• Código limpio

Líder en la industria del desarrollo de software, Martin se desempeñó durante tres años como editor
en jefe del Informe C++ y fue el primer presidente de Agile Alliance.

Robert también es el fundador de Uncle Bob Consulting, LLC y cofundador, junto con su hijo
Micah Martin, de The Clean Coders LLC.

xxx
Machine Translated by Google

EN LA PORTADA

La impresionante imagen de la portada, que recuerda al ojo de Sauron, es M1, la Nebulosa

del Cangrejo. M1 está situado en Tauro, aproximadamente un grado a la derecha de Zeta
Tauri, la estrella en la punta del cuerno izquierdo del toro. La nebulosa del Cangrejo es el
remanente de una supernova que explotó por todo el cielo en la fecha bastante auspiciosa del
4 de julio de 1054 d.C. A una distancia de 6.500 años luz, esa explosión se les apareció a los chinos.

xxxi
Machine Translated by Google

EN LA PORTADA

observadores como una nueva estrella, aproximadamente tan brillante como Júpiter. De hecho, ¡era visible
durante el día! Durante los siguientes seis meses, poco a poco desapareció de la vista a simple vista.

La imagen de portada es una combinación de luz visible y de rayos X. La imagen visible fue tomada por el
telescopio Hubble y forma la envoltura exterior. El objeto interior que parece un blanco de tiro con arco azul
fue captado por el telescopio de rayos X Chandra.

La imagen visible muestra una nube de polvo y gas en rápida expansión mezclada con elementos pesados
que quedaron de la explosión de la supernova. Esa nube tiene ahora 11 años luz de diámetro, pesa 4,5
masas solares y se está expandiendo a una velocidad vertiginosa de 1.500 kilómetros por segundo. La
energía cinética de esa vieja explosión es, cuanto menos, impresionante.

En el centro del objetivo hay un punto azul brillante. Ahí es donde está el púlsar . Fue la formación del púlsar
lo que provocó la explosión de la estrella en primer lugar.
Casi una masa solar de material en el núcleo de la estrella condenada implosionó en una esfera de neutrones
de unos 30 kilómetros de diámetro. La energía cinética de esa implosión, junto con el increíble aluvión de
neutrinos creado cuando todos esos neutrones se formaron, desgarraron la estrella y la volaron al cielo.

El púlsar gira unas 30 veces por segundo; y parpadea mientras gira. Podemos verlo parpadeando en
nuestros telescopios. Esos pulsos de luz son la razón por la que lo llamamos púlsar, que es la abreviatura de
Estrella Pulsante.

xxxiii
Machine Translated by Google

PRE REQUISITO
INTRODUCCIÓN

(No te saltes esto, lo necesitarás).

Supongo que acaba de leer este libro porque es programador informático y le

intriga la noción de profesionalismo. Deberías serlo.
El profesionalismo es algo que nuestra profesión necesita urgentemente.

Yo también soy programador. Soy programador desde hace 421 años; y en ese tiempo—
Déjame decirte : lo he visto todo. Me han despedido. Me han elogiado. He sido líder
de equipo, gerente, gruñón e incluso director ejecutivo. He trabajado con brillantes

1. Que no cunda el pánico.

1
Machine Translated by Google

PRERREQUISITO INTRODUCCIÓN

programadores y he trabajado con babosas.2 He trabajado en sistemas de software/hardware

integrados de vanguardia y alta tecnología, y he trabajado en sistemas de nómina corporativa.
He programado en COBOL, FORTRAN, BAL, PDP­8, PDP­11, C, C++, Java, Ruby, Smalltalk y una
gran cantidad de otros lenguajes y sistemas.
He trabajado con ladrones de sueldos poco confiables y con profesionales consumados.
Esta última clasificación es el tema de este libro.

En las páginas de este libro intentaré definir qué significa ser un programador profesional. Describiré
las actitudes, disciplinas y acciones que considero esencialmente profesionales.

¿Cómo sé cuáles son estas actitudes, disciplinas y acciones? Porque tuve que aprenderlos de la
manera más difícil. Verás, cuando conseguí mi primer trabajo como programador, profesional fue la
última palabra que hubieras usado para describirme.

Era el año 1969. Yo tenía 17 años. Mi padre había presionado a una empresa local llamada ASC
para que me contratara como programador temporal a tiempo parcial. (Sí, mi padre podía hacer
cosas así. Una vez lo vi caminar frente a un automóvil que iba a toda velocidad con la mano
extendida ordenándole "¡Para!" El auto se detuvo. Nadie le dijo "no" a mi papá). Me puso a trabajar
en la habitación donde se guardaban todos los manuales de las computadoras IBM. Me hicieron poner
años y años de actualizaciones en los manuales. Fue aquí donde vi por primera vez la frase: "Esta
página se dejó en blanco intencionalmente".

Después de un par de días de actualizar manuales, mi supervisor me pidió que escribiera un programa
Easycoder3 sencillo. Me emocionó que me lo pidieran. Nunca antes había escrito un programa
para una computadora real. Sin embargo, había inhalado los libros de Autocoder y tenía una
vaga idea de cómo empezar.

El programa consistía simplemente en leer registros de una cinta y reemplazar las identificaciones
de esos registros con nuevas identificaciones. Los nuevos ID comenzaron en 1 y se incrementaron en

2. Un término técnico de origen desconocido.

3. Easycoder fue el ensamblador de la computadora Honeywell H200, que era similar al
Autocoder para la computadora IBM 1401.

2
Machine Translated by Google

PRERREQUISITO INTRODUCCIÓN

1 por cada nuevo registro. Los registros con las nuevas identificaciones debían escribirse en un

cinta nueva.

Mi supervisor me mostró un estante que contenía muchas pilas de tarjetas perforadas rojas y
azules. Imagina que compraste 50 barajas de naipes, 25 barajas rojas y 25 barajas azules. Luego
apilaste esas barajas una encima de la otra.
Así se veían estos montones de cartas. Tenían rayas rojas y azules, y las rayas eran unas 200 cartas
cada una. Cada una de esas franjas contenía el código fuente de la biblioteca de subrutinas que los
programadores solían utilizar.
Los programadores simplemente tomarían el mazo superior de la pila, asegurándose de no tomar
nada más que cartas rojas o azules, y luego lo pondrían al final de su mazo de programa.

Escribí mi programa en algunos formularios de codificación. Los formularios de codificación

eran grandes hojas de papel rectangulares divididas en 25 líneas y 80 columnas. Cada línea
representaba una carta. Escribiste tu programa en el formulario de codificación usando letras mayúsculas
y un lápiz número 2. En las últimas 6 columnas de cada línea escribiste un número de secuencia
con ese lápiz n.° 2. Normalmente, incrementaba el número de secuencia en 10 para poder insertar
tarjetas más tarde.

El formulario de codificación pasó a manos de los perforadores clave. Esta empresa tenía varias
docenas de mujeres que tomaban formularios codificados de una gran canasta de entrada y luego
los “escribían” en máquinas perforadoras de llaves. Estas máquinas se parecían mucho a las
máquinas de escribir, excepto que los caracteres se perforaban en tarjetas en lugar de imprimirse en papel.

Al día siguiente, los pulsadores me devolvieron mi programa por correo interno.

Mi pequeño mazo de tarjetas perforadas estaba envuelto por mis formularios de codificación y una
banda elástica. Revisé las tarjetas en busca de errores al marcar las teclas. No hubo ninguno. Entonces
puse la plataforma de la biblioteca de subrutinas al final de mi plataforma de programas y luego la
llevé arriba a los operadores de la computadora.

Las computadoras estaban detrás de puertas cerradas en una sala ambientalmente

controlada con piso elevado (para todos los cables). Llamé a la puerta y un operador
me quitó austeramente mi mazo y lo puso en otra cesta de entrada dentro de la sala de
ordenadores. Cuando llegaran a eso, controlarían mi mazo.

3
Machine Translated by Google

PRERREQUISITO INTRODUCCIÓN

Al día siguiente recuperé mi mazo. Estaba envuelto en una lista de los resultados de la carrera y se mantenía
junto con una banda elástica. (¡Usábamos muchas bandas elásticas en aquellos días!)

Abrí el listado y vi que mi compilación había fallado. Los mensajes de error en el listado me resultaron muy
difíciles de entender, así que se los comuniqué a mi supervisor. Lo examinó, murmuró en voz
baja, tomó algunas notas rápidas en la lista, agarró mi mazo y luego me dijo que lo siguiera.

Me llevó a la sala de punzonado y se sentó ante una máquina perforadora vacía.

Una por una corrigió las tarjetas que tenían errores y añadió una o dos tarjetas más. Rápidamente le
explicó lo que estaba haciendo, pero todo pasó como un relámpago.

Llevó la nueva plataforma a la sala de ordenadores y llamó a la puerta. Le dijo algunas palabras mágicas
a uno de los operadores y luego entró en la sala de computadoras detrás de él. Me hizo una seña
para que lo siguiera. El operador instaló las unidades de cinta y cargó la platina mientras mirábamos. Las
cintas giraron, la impresora traqueteó y luego todo terminó. El programa había funcionado.

Al día siguiente, mi supervisor me agradeció mi ayuda y despidió mi empleo. Aparentemente, ASC

no sentía que tuviera tiempo para cuidar a un joven de 17 años.

Pero mi conexión con ASC apenas había terminado. Unos meses más tarde conseguí un trabajo de
segundo turno a tiempo completo en ASC operando impresoras fuera de línea. Estas impresoras imprimían
correo basura a partir de imágenes impresas almacenadas en cinta. Mi trabajo consistía en cargar papel
en las impresoras, cargar las cintas en las unidades de cinta, solucionar atascos de papel y, por lo
demás, simplemente observar cómo funcionaban las máquinas.

Era el año 1970. La universidad no era una opción para mí ni tenía ningún atractivo particular. La
guerra de Vietnam todavía estaba en pleno apogeo y las universidades eran caóticas. Continué inhalando
libros sobre COBOL, Fortran, PL/1, PDP­8 e IBM 360 Assembler. Mi intención era evitar la escuela

y conducir tan duro como pudiera para conseguir un trabajo en programación.

4
Machine Translated by Google

PRERREQUISITO INTRODUCCIÓN

Doce meses después logré ese objetivo. Me ascendieron a programador de tiempo completo
en ASC. Yo y dos de mis buenos amigos, Richard y Tim, también de 19 años, trabajamos con un
equipo de otros tres programadores escribiendo un sistema de contabilidad en tiempo real para un
sindicato de camioneros. La máquina era una Varian 620i. Era una minicomputadora simple similar
en arquitectura a una PDP­8 excepto que tenía una palabra de 16 bits y dos registros. El lenguaje
era ensamblador.

Escribimos cada línea de código en ese sistema. Y me refiero a cada línea. Escribimos el sistema
operativo, los cabezales de interrupción, los controladores IO, el sistema de archivos para los
discos, el intercambiador de superposiciones e incluso el enlazador reubicable. Sin mencionar todo
el código de la aplicación. Escribimos todo esto en 8 meses trabajando 70 y 80 horas semanales para
cumplir con un plazo infernal. Mi salario era de 7.200 dólares al año.

Entregamos ese sistema. Y luego lo dejamos.

Renunciamos de repente y con malicia. Verá, después de todo ese trabajo y después de haber
entregado un sistema exitoso, la empresa nos dio un aumento del 2%. Nos sentimos engañados y
abusados. Varios de nosotros conseguimos trabajo en otros lugares y simplemente dimitimos.

Yo, sin embargo, adopté un enfoque diferente y muy desafortunado. Un amigo y yo irrumpimos
en la oficina del jefe y renunciamos juntos bastante ruidosamente. Esto fue emocionalmente
muy satisfactorio... por un día.

Al día siguiente me di cuenta de que no tenía trabajo. Yo tenía 19 años, estaba desempleado, sin
título. Me entrevisté para algunos puestos de programación, pero esas entrevistas no salieron bien.
Entonces trabajé en el taller de reparación de cortadoras de césped de mi cuñado durante cuatro
meses. Desafortunadamente yo era un pésimo reparador de cortadoras de césped. Al final tuvo que
dejarme ir. Caí en un mal momento.

Me quedaba despierto hasta las 3 de la madrugada todas las noches comiendo pizza y viendo viejas
películas de monstruos en el viejo televisor en blanco y negro con orejas de conejo de mis padres.
Sólo algunos de los fantasmas eran personajes de las películas. Me quedé en la cama hasta la 1 de la tarde
porque no quería afrontar mis días tristes. Tomé un curso de cálculo en un colegio comunitario local y lo
reprobé. Yo estaba hecho un desastre.

5
Machine Translated by Google

PRERREQUISITO INTRODUCCIÓN

Mi madre me llevó aparte y me dijo que mi vida era un desastre y que había sido un idiota por dejarlo sin
tener un nuevo trabajo, y por haberlo hecho tan emocionalmente, y por haberlo hecho junto con
mi amigo. Me dijo que nunca renuncias sin tener un nuevo trabajo y que siempre lo haces con calma,
tranquilidad y solo. Ella me dijo que debería llamar a mi antiguo jefe y rogarle que me devolviera mi
antiguo trabajo.
Ella dijo: "Necesitas comer un pastel de humildad".

Los chicos de diecinueve años no son conocidos por su apetito por el pastel humilde, y yo no fui la
excepción. Pero las circunstancias habían pasado factura a mi orgullo. Al final llamé a mi jefe y le di un gran
mordisco a ese humilde pastel. Y funcionó. Él estaba feliz de volver a contratarme por $6,800 por año y yo
estaba feliz de aceptarlo.

Pasé otros dieciocho meses trabajando allí, observando mis P y Q y tratando de ser un empleado
lo más valioso posible. Me recompensaron con ascensos y aumentos, y con un sueldo regular. La
vida era buena. Cuando dejé esa empresa fue en buenos términos y con una oferta de un mejor trabajo
en mi bolsillo.

Se podría pensar que había aprendido la lección; que ahora era un profesional. Nada de eso. Esa fue sólo la
primera de muchas lecciones que necesitaba aprender. En los años siguientes me despedirían de un trabajo
por omitir fechas críticas por descuido, y casi me despedirían de otro por filtrar inadvertidamente
información confidencial a un cliente. Tomaría la iniciativa en un proyecto condenado al fracaso y lo arruinaría
sin pedir la ayuda que sabía que necesitaba. Defendería agresivamente mis decisiones técnicas a pesar
de que iban en contra de las necesidades de los clientes. Contrataría a una persona totalmente no
calificada, cargando a mi empleador con una enorme responsabilidad con la que lidiar. Y lo
peor de todo es que haría que despidieran a otras dos personas por mi incapacidad para liderar.

Así que piense en este libro como un catálogo de mis propios errores, un documento secante de mis propios
crímenes y un conjunto de pautas para que usted evite caminar en mis primeros zapatos.

6
Machine Translated by Google

1 PROFESIONALIDAD

“Oh, ríete, Curtin, viejo. Es una gran broma que nos hace el Señor, o el destino, o
la naturaleza, lo que prefieras. ¡Pero quienquiera que lo haya jugado ciertamente
tenía sentido del humor! ¡Ja!"
— Howard, El tesoro de la Sierra Madre

7
Machine Translated by Google

CAPÍTULO 1 PROFESIONALISMO

Entonces, ¿quieres ser un desarrollador de software profesional? Quieres mantener

la cabeza en alto y declarar al mundo: "¡Soy un profesional!" Quieres que la gente te
mire con respeto y te trate con deferencia. Quieres que las madres te señalen y
les digan a sus hijos que sean como tú. Lo quieres todo. ¿Bien?

TEN CUIDADO CON LO QUE PIDES

Profesionalismo es un término cargado. Sin duda, es una insignia de honor y orgullo, pero
también es un indicador de responsabilidad y rendición de cuentas. Los dos van de la
mano, por supuesto. No puedes enorgullecerte y honrar algo de lo que no puedes rendir
cuentas.

Es mucho más fácil no ser un profesional. Los no profesionales no tienen que

asumir la responsabilidad del trabajo que realizan; se lo dejan a sus empleadores.
Si un no profesional comete un error, el empleador arregla el desorden. Pero cuando
un profesional comete un error, limpia el desorden.

¿Qué pasaría si permitiera que un error se filtrara a través de un módulo y le costara

a su empresa $10,000? El no profesional se encogería de hombros, diría “suceden
cosas” y comenzaría a escribir el siguiente módulo. ¡El profesional le extendería a
la empresa un cheque por 10.000 dólares!1

Sí, se siente un poco diferente cuando es tu propio dinero, ¿no? Pero ese
sentimiento es el que tiene un profesional todo el tiempo. De hecho, ese sentimiento
es la esencia del profesionalismo. Porque, como ve, el profesionalismo consiste en
asumir la responsabilidad.

Asumir la responsabilidad

Leíste la introducción, ¿verdad? Si no, regresa y hazlo ahora; establece el

contexto para todo lo que sigue en este libro.

Aprendí a asumir responsabilidades sufriendo las consecuencias de no asumirlas.

1. ¡Ojalá tenga una buena política de Errores y Omisiones!

8
Machine Translated by Google

Asumir la responsabilidad

En 1979 trabajaba para una empresa llamada Teradyne. Yo era el “ingeniero responsable” del
software que controlaba un sistema basado en mini y microcomputadoras que medía la
calidad de las líneas telefónicas. La minicomputadora central estaba conectada a través de líneas
telefónicas dedicadas o de acceso telefónico de 300 baudios a docenas de
microcomputadoras satelitales que controlaban el hardware de medición. Todo el código fue
escrito en ensamblador.

Nuestros clientes eran los responsables de servicio de las principales compañías telefónicas.
Cada uno tenía la responsabilidad de 100.000 líneas telefónicas o más. Mi sistema ayudó a
estos gerentes de área de servicio a encontrar y reparar fallas y problemas en las líneas
telefónicas antes de que sus clientes los notaran. Esto redujo los índices de quejas de los clientes
que las comisiones de servicios públicos midieron y utilizaron para regular las tarifas que
podían cobrar las compañías telefónicas. En resumen, estos sistemas eran increíblemente
importantes.

Todas las noches, estos sistemas ejecutaban una “rutina nocturna” en la que la minicomputadora
central decía a cada una de las microcomputadoras satelitales que probaran cada
línea telefónica bajo su control. Cada mañana, la computadora central recuperaba la lista de
líneas defectuosas, junto con sus características defectuosas. Los gerentes del área de
servicio usarían este informe para programar a los reparadores para que solucionen las fallas
antes de que los clientes puedan quejarse.

En una ocasión envié una nueva versión a varias docenas de clientes. "Barco" es exactamente
la palabra correcta. Escribí el software en cintas y las envié a los clientes. Los clientes cargaron
las cintas y luego reiniciaron los sistemas.

La nueva versión solucionó algunos defectos menores y agregó una nueva característica

que nuestros clientes habían estado demandando. Les habíamos dicho que proporcionaríamos
esa nueva función en una fecha determinada. Apenas logré pasar las cintas durante la noche
para que llegaran en la fecha prometida.

Dos días después recibí una llamada de nuestro gerente de servicio de campo, Tom. Me dijo
que varios clientes se habían quejado de que la “rutina nocturna” no se había completado y que
no habían recibido informes. Mi corazón se hundió porque para poder enviar el software a
tiempo, no había probado la rutina. Había probado gran parte del

9
Machine Translated by Google

CAPÍTULO 1 PROFESIONALISMO

otras funciones del sistema, pero probar la rutina tomó horas y tuve que enviar el
software. Ninguna de las correcciones de errores estaba en el código de la rutina, así que me
sentí seguro.

Perder un informe nocturno fue un gran problema. Esto significaba que los reparadores tenían
menos que hacer y más tarde tendrían exceso de reservas. Esto significaba que algunos clientes
podrían notar un fallo y quejarse. Perder los datos de una noche es suficiente para que un
gerente del área de servicio llame a Tom y lo ataque.

Encendí nuestro sistema de laboratorio, cargué el nuevo software y luego comencé una rutina.
Tardaron varias horas pero luego abortó. La rutina falló. Si hubiera realizado esta prueba

antes de realizar el envío, las áreas de servicio no habrían perdido datos y los gerentes del
área de servicio no estarían molestando a Tom en este momento.

Llamé a Tom para decirle que podía duplicar el problema. Me dijo que la mayoría de los otros
clientes lo habían llamado con la misma queja. Luego me preguntó cuándo podría arreglarlo. Le
dije que no lo sabía, pero que estaba trabajando en ello. Mientras tanto le dije que los clientes
deberían volver al software antiguo. Estaba enojado conmigo diciendo que esto era un doble
golpe para los clientes ya que habían perdido datos de toda una noche y no podían usar la
nueva función que les prometieron.

El error fue difícil de encontrar y las pruebas tomaron varias horas. La primera solución no
funcionó. El segundo tampoco. Me tomó varios intentos y, por lo tanto, varios días, descubrir qué
había salido mal. Todo el tiempo, Tom me llamaba cada pocas horas preguntándome cuándo
arreglaría esto. También se aseguró de que yo supiera los comentarios que estaba recibiendo
de los gerentes del área de servicio y lo vergonzoso que era para él decirles que
volvieran a colocar las cintas viejas.

Al final encontré el defecto, envié las cintas nuevas y todo volvió a la normalidad. Tom, que no
era mi jefe, se calmó y dejamos atrás todo el episodio. Mi jefe vino a verme cuando todo
terminó y me dijo: "Apuesto a que no volverás a hacer eso". Estuve de acuerdo.

Al reflexionar me di cuenta que enviar sin probar la rutina había sido irresponsable. La razón
por la que descuidé la prueba fue para poder decir que había enviado

10
Machine Translated by Google

PRIMERO, NO HACER DAÑO

a tiempo. Se trataba de salvar las apariencias. No me había preocupado ni el cliente ni mi empleador.

Sólo me preocupaba mi propia reputación. Debería haber asumido la responsabilidad desde el principio y
decirle a Tom que las pruebas no estaban completas y que no estaba preparado para enviar el software a
tiempo. Eso habría sido difícil y Tom se habría enfadado. Pero ningún cliente habría perdido datos y ningún
administrador de servicio habría llamado.

PRIMERO , NO HACER DAÑO

Entonces, ¿cómo asumimos la responsabilidad? Hay algunos principios. Recurrir al juramento hipocrático puede
parecer arrogante, pero ¿qué mejor fuente existe? Y, de hecho, ¿no tiene sentido que la primera
responsabilidad y el primer objetivo de un aspirante a profesional sea utilizar sus poderes para el bien?

¿Qué daño puede hacer un desarrollador de software? Desde un punto de vista puramente
del software, puede dañar tanto la función como la estructura del software. Exploraremos
cómo evitar hacer precisamente eso.

NO DAÑAR EL FUNCIONAMIENTO

Claramente, queremos que nuestro software funcione. De hecho, la mayoría de nosotros somos
programadores hoy en día porque conseguimos que algo funcionara una vez y queremos volver a tener esa sensación.
Pero no somos los únicos que queremos que el software funcione. Nuestros clientes y empleadores también
quieren que funcione. De hecho, nos pagan para que creemos software que funcione tal como ellos quieren.

Dañamos la función de nuestro software cuando creamos errores. Por tanto, para ser profesionales no debemos
crear errores.

"¡Pero espera!" Te oigo decir. “Eso no es razonable. El software es demasiado complejo para crearlo sin
errores”.

Por supuesto que tienes razón. El software es demasiado complejo para crearlo sin errores.
Desafortunadamente eso no te libera del apuro. El cuerpo humano es demasiado complejo para
comprenderlo en su totalidad, pero los médicos aún juran no causar daño. Si ellos no se libran de un apuro
así , ¿cómo podremos hacerlo nosotros?

11
Machine Translated by Google

CAPÍTULO 1 PROFESIONALISMO

“¿Nos estás diciendo que debemos ser perfectos?” ¿Te oigo objetar?

No, te digo que debes ser responsable de tus imperfecciones. El hecho de que seguramente se
produzcan errores en su código no significa que usted no sea responsable de ellos. El hecho de
que la tarea de escribir software perfecto sea prácticamente imposible no significa que usted no sea
responsable de la imperfección.

Es responsabilidad de un profesional ser responsable de los errores, aunque los errores sean prácticamente
seguros. Entonces, mi aspirante a profesional, lo primero que debes practicar es disculparte. Las disculpas
son necesarias, pero insuficientes. No puedes simplemente seguir cometiendo los mismos errores una y
otra vez. A medida que madure en su profesión, su tasa de error debería disminuir rápidamente hacia la
asíntota de cero. Nunca llegará a cero, pero es tu responsabilidad acercarte lo más posible a él.

El control de calidad no debería encontrar nada

Por lo tanto, cuando publique su software, debe esperar que el control de calidad no encuentre
problemas. Es extremadamente poco profesional enviar intencionalmente un código que usted sabe que
es defectuoso al control de calidad. ¿Y qué código sabes que está defectuoso? ¡Cualquier código del
que no estés seguro !

Algunas personas utilizan el control de calidad para detectar errores. Les envían un código que no han
comprobado minuciosamente. Dependen del control de calidad para encontrar los errores e informarlos a los
desarrolladores. De hecho, algunas empresas recompensan el control de calidad en función de la cantidad
de errores que encuentran. Cuantos más errores, mayor será la recompensa.

No importa que se trate de un comportamiento desesperadamente costoso que daña a la empresa

y al software. No importa que este comportamiento arruine los cronogramas y socave la confianza de la
empresa en el equipo de desarrollo. No importa que este comportamiento sea simplemente vago e
irresponsable. Publicar código para control de calidad que no sabes que funciona no es profesional. Viola la
regla de “no hacer daño”.

¿El control de calidad encontrará errores? Probablemente, así que prepárate para disculparte y luego
descubre por qué esos errores lograron pasar desapercibidos y haz algo para evitar que vuelva a suceder.

12
Machine Translated by Google

PRIMERO, NO HACER DAÑO

Cada vez que el control de calidad, o peor aún, un usuario, encuentra un problema, usted debería
sorprenderse, disgustarse y estar decidido a evitar que vuelva a suceder.

Debes saber que funciona

¿Cómo puedes saber que tu código funciona? Eso es fácil. Pruébalo. Pruébalo de nuevo. Pruébalo.
Pruébelo. ¡Pruébalo de siete maneras hasta el domingo!

Quizás le preocupe que probar tanto su código le lleve demasiado tiempo. Después de todo, tienes
horarios y plazos que cumplir. Si dedica todo su tiempo a realizar pruebas, nunca escribirá nada más.
¡Buen punto! Entonces, automatice sus pruebas. Escriba pruebas unitarias que pueda ejecutar en
cualquier momento y ejecútelas con tanta frecuencia como pueda.

¿Qué parte del código debería probarse con estas pruebas unitarias automatizadas? ¿Realmente necesito

responder esa pregunta? ¡Todo ello! Todo. De. Él.

¿Estoy sugiriendo una cobertura de prueba del 100%? No, no lo estoy sugiriendo . Lo estoy exigiendo .
Cada línea de código que escriba debe probarse. Período.

¿No es eso poco realista? Por supuesto que no. Sólo escribes código porque esperas que se ejecute.
Si espera que se ejecute, debe saber que funciona. La única forma de saberlo es probándolo.

Soy el principal contribuyente y responsable de un proyecto de código abierto llamado FitNesse. Al

momento de escribir este artículo hay 60ksloc en FitNesse. 26 de esos 60 están escritos en más de 2000
pruebas unitarias. Emma informa que la cobertura de esas 2000 pruebas es de ~90%.

¿Por qué la cobertura de mi código no es mayor? ¡Porque Emma no puede ver todas las líneas de
código que se están ejecutando! Creo que la cobertura es mucho mayor que eso.
¿La cobertura es del 100%? No, el 100% es una asíntota.

¿Pero no es difícil probar algún código? Sí, pero sólo porque ese código ha sido diseñado para
que sea difícil de probar. La solución a esto es diseñar su código para que sea fácil.
para probar. Y la mejor manera de hacerlo es escribir las pruebas primero, antes de escribir el código
que las supera.

13
Machine Translated by Google

CAPÍTULO 1 PROFESIONALISMO

Esta es una disciplina conocida como Test Driven Development (TDD), sobre la que hablaremos más en un
capítulo posterior.

Control de calidad automatizado

Todo el procedimiento de control de calidad de FitNesse es la ejecución de las pruebas unitarias y de aceptación.
Si esas pruebas pasan, lo envío. Esto significa que mi procedimiento de control de calidad dura unos tres
minutos y puedo ejecutarlo cuando quiera.

Ahora bien, es cierto que nadie muere si hay un error en FitNesse. Nadie pierde tampoco millones de dólares.
Por otro lado, FitNesse tiene miles de usuarios y una lista de errores muy pequeña.

Ciertamente, algunos sistemas son tan críticos que una breve prueba automatizada es insuficiente
para determinar si están listos para su implementación. Por otro lado, usted como desarrollador necesita
un mecanismo relativamente rápido y confiable para saber que el código que ha escrito funciona y no interfiere
con el resto del sistema. Entonces, como mínimo, sus pruebas automatizadas deberían indicarle que es muy
probable que el sistema pase el control de calidad.

NO DAÑAR LA ESTRUCTURA

El verdadero profesional sabe que ofrecer funciones a expensas de la estructura es una tontería. Es la estructura
de su código lo que le permite ser flexible. Si comprometes la estructura, comprometes el futuro.

El supuesto fundamental que subyace a todos los proyectos de software es que el software es fácil de cambiar.
Si se viola este supuesto al crear estructuras inflexibles, se socava el modelo económico en el que se basa
toda la industria.

En resumen: debe poder realizar cambios sin costes exorbitantes.

Desafortunadamente, demasiados proyectos quedan atrapados en un pozo de alquitrán de estructura deficiente.

Tareas que antes llevaban días empiezan a tardar semanas y luego meses. La gerencia, desesperada por
recuperar el impulso perdido, contrata más desarrolladores para acelerar las cosas. Pero estos promotores
simplemente contribuyen al caos, profundizando el daño estructural y aumentando el impedimento.

14
Machine Translated by Google

PRIMERO, NO HACER DAÑO

Se ha escrito mucho sobre los principios y patrones de diseño de software que sustentan
estructuras que son flexibles y mantenibles.2 Los desarrolladores de software profesionales
memorizan estas cosas y se esfuerzan por adaptar su software a ellas. Pero hay un truco en
esto que muy pocos desarrolladores de software siguen: si quieres que tu software sea flexible,
¡tienes que flexibilizarlo!

La única forma de demostrar que su software es fácil de cambiar es realizar cambios

sencillos en él. Y cuando descubre que los cambios no son tan fáciles como pensaba,
perfecciona el diseño para que el siguiente cambio sea más fácil.

¿Cuándo haces estos cambios fáciles? ¡Todo el tiempo! Cada vez que miras un módulo, le
realizas cambios pequeños y livianos para mejorar su estructura.
Cada vez que lees el código, ajustas la estructura.

Esta filosofía a veces se denomina refactorización despiadada. Yo lo llamo “la regla de los Boy
Scouts”: siempre registre un módulo más limpio que cuando lo revisó. Siempre haz algún acto
de bondad al azar con el código cada vez que lo veas.

Esto va completamente en contra de la forma en que la mayoría de la gente piensa sobre el

software. Piensan que realizar una serie continua de cambios en el software que
funciona es peligroso. ¡No! Lo peligroso es permitir que el software permanezca estático. Si
no lo estás flexionando, cuando necesites cambiarlo , lo encontrarás rígido.

¿Por qué la mayoría de los desarrolladores temen realizar cambios continuos en su código?
¡Tienen miedo de romperlo! ¿Por qué tienen miedo de romperlo? Porque no tienen
pruebas.

Todo vuelve a las pruebas. Si tiene un conjunto automatizado de pruebas que cubre
prácticamente el 100% del código, y si ese conjunto de pruebas se puede ejecutar rápidamente
por capricho, entonces simplemente no tendrá miedo de cambiar el código. ¿Cómo demuestras
que no tienes miedo de cambiar el código? Lo cambias todo el tiempo.

Los desarrolladores profesionales están tan seguros de su código y sus pruebas que
son exasperantemente casuales a la hora de realizar cambios aleatorios y oportunistas.
Cambiarán el nombre de una clase, por capricho. Notarán un método más o menos largo mientras

2. [PPP2001]

15
Machine Translated by Google

CAPÍTULO 1 PROFESIONALISMO

leer un módulo y repartirlo como algo natural. Transformarán una declaración de

cambio en una implementación polimórfica o colapsarán una jerarquía de herencia
en una cadena de comando. En resumen, tratan el software de la misma manera que
un escultor trata la arcilla: le dan forma y moldean continuamente.

ÉTICA DE TRABAJO

Tu carrera es tu responsabilidad. No es responsabilidad de su empleador asegurarse

de que usted sea comercializable. No es responsabilidad de su empleador capacitarlo,
enviarlo a conferencias o comprarle libros. Estas cosas son tu
responsabilidad. ¡Ay del desarrollador de software que confía su carrera a su
empleador!

Algunos empleadores están dispuestos a comprarle libros y enviarlo a clases de

capacitación y conferencias. Está bien, te están haciendo un favor. Pero nunca caiga
en la trampa de pensar que esto es responsabilidad de su empleador. Si su
empleador no hace estas cosas por usted, debe encontrar una manera de hacerlas usted mismo.

Tampoco es responsabilidad de su empleador darle el tiempo que necesita para

aprender. Algunos empleadores pueden proporcionar ese tiempo. Algunos
empleadores pueden incluso exigirle que se tome el tiempo. Pero, de nuevo, te están
haciendo un favor y deberías estar debidamente agradecido. Estos favores no son algo
que debas esperar.

Le debes a tu empleador una cierta cantidad de tiempo y esfuerzo. A modo de

argumento, utilicemos el estándar estadounidense de 40 horas semanales. Estas
40 horas deben dedicarse a los problemas de su empleador , no a sus problemas.

Debes planear trabajar 60 horas por semana. Los primeros 40 son para su
empleador. Los 20 restantes son para ti. Durante las 20 horas restantes, deberías
leer, practicar, aprender y mejorar tu carrera.

Puedo oírte pensar: “¿Pero qué pasa con mi familia? ¿Qué pasa con mi vida? ¿Se
supone que debo sacrificarlos por mi empleador?

16
Machine Translated by Google

ÉTICA DE TRABAJO

No me refiero a todo tu tiempo libre aquí. Estoy hablando de 20 horas extra por
semana. Eso es aproximadamente tres horas por día. Si utiliza su hora de almuerzo
para leer, escucha podcasts mientras viaja y dedica 90 minutos al día a aprender
un nuevo idioma, lo tendrá todo cubierto.

Haz los cálculos. En una semana hay 168 horas. Dale a tu empleador 40 y a tu carrera
otros 20. Eso deja 108. Otros 56 para dormir dejan 52 para todo lo demás.

Quizás no quieras hacer ese tipo de compromiso. Está bien, pero no deberías
considerarte un profesional. Los profesionales dedican tiempo
cuidando su profesión.

Quizás pienses que el trabajo debería quedarse en el trabajo y que no deberías llevártelo
a casa. ¡Estoy de acuerdo! No deberías trabajar para tu empleador durante esas 20
horas. En cambio, deberías estar trabajando en tu carrera.

A veces estos dos están alineados entre sí. A veces, el trabajo que realiza para su
empleador es muy beneficioso para su carrera. En ese caso, dedicarle algo de
esas 20 horas es razonable. Pero recuerda, esas 20 horas son para ti. Deben utilizarse
para hacerse más valioso como profesional.

Quizás piense que esta es una receta para el agotamiento. Al contrario, es una receta
para evitar el burnout. Es de suponer que te convertiste en desarrollador de software
porque te apasiona el software y tu deseo de ser un profesional está motivado por esa
pasión. Durante esas 20 horas deberías estar haciendo aquellas cosas que
refuercen esa pasión. ¡Esas 20 horas deberían ser divertidas!

CONOCE TU CAMPO
¿Sabes qué es una tabla de Nassi­Schneiderman? Si no, ¿por qué no? ¿Conoce
la diferencia entre una máquina de estados Mealy y Moore? Debería.
¿Podrías escribir una clasificación rápida sin buscarla? ¿Sabes lo que significa el término
“Análisis de Transformación”? ¿Podrías realizar una descomposición funcional con
diagramas de flujo de datos? ¿Qué significa el término "datos vagabundos"? ¿Has oído el
término “Conascencia”? ¿Qué es una mesa de Parnas?

17
Machine Translated by Google

CAPÍTULO 1 PROFESIONALISMO

Una gran cantidad de ideas, disciplinas, técnicas, herramientas y terminologías decoran los
últimos cincuenta años de nuestro campo. ¿Cuánto sabes de esto? Si quieres ser un profesional,
debes conocer una parte considerable y aumentar constantemente el tamaño de esa parte.

¿Por qué deberías saber estas cosas? Después de todo, ¿no está nuestro campo
progresando tan rápidamente que todas estas viejas ideas se han vuelto irrelevantes? La
primera parte de esa pregunta parece obvia a primera vista. Ciertamente nuestro campo está
progresando ya un ritmo feroz. Sin embargo, es bastante interesante que ese progreso sea en
muchos aspectos periférico. Es cierto que ya no esperamos 24 horas para que se complete
la compilación. Es cierto que escribimos sistemas que tienen un tamaño de gigabytes. Es
cierto que trabajamos en medio de una red global que brinda acceso instantáneo a la
información. Por otro lado, estamos escribiendo las mismas afirmaciones if y while que escribíamos
hace 50 años. Mucho ha cambiado. Mucho no.

La segunda parte de la pregunta ciertamente no es cierta. Muy pocas ideas de los últimos 50
años se han vuelto irrelevantes. Algunos han quedado marginados, es verdad. La idea de realizar
un desarrollo en cascada ciertamente ha caído en desgracia. Pero eso no significa que no
debamos saber qué es y cuáles son sus puntos buenos y malos.

Sin embargo, en general, la gran mayoría de las ideas logradas con tanto esfuerzo en los últimos
50 años son tan valiosas hoy como lo eran entonces. Quizás ahora sean incluso más valiosos.

Recuerde la maldición de Santayana: “Aquellos que no pueden recordar el pasado están

condenados a repetirlo”.

Aquí hay una lista mínima de cosas con las que todo profesional del software debería estar
familiarizado:

• Patrones de diseño. Debería poder describir los 24 patrones del libro GOF y tener un
conocimiento práctico de muchos de los patrones de los libros POSA.

• Principios de diseño. Debes conocer los principios SÓLIDOS y tener una buena
comprensión de los principios componentes.
• Métodos. Debe comprender XP, Scrum, Lean, Kanban, Cascada, Análisis estructurado
y Diseño estructurado.

18
Machine Translated by Google

ÉTICA DE TRABAJO

• Disciplinas. Debes practicar TDD, diseño orientado a objetos, programación estructurada, integración
continua y programación en pares.

• Artefactos: Debe saber utilizar: UML, DFD, diagramas de estructura, redes de Petri, diagramas y

tablas de transición de estados, diagramas de flujo y tablas de decisión.

APRENDIZAJE CONTINUO

El ritmo frenético de cambio en nuestra industria significa que los desarrolladores de software
deben continuar aprendiendo cantidades copiosas sólo para mantenerse al día. ¡Ay de los arquitectos
que dejen de codificar! Rápidamente se volverán irrelevantes. ¡Ay de los programadores que
dejen de aprender nuevos lenguajes! Verán cómo la industria los pasa por alto. ¡Ay de los
desarrolladores que no logren aprender nuevas disciplinas y técnicas! Sus pares sobresaldrán a medida
que decaigan.

¿Visitaría a un médico que no se mantuviera al día con las revistas médicas?

¿Contrataría a un abogado fiscal que no se mantuviera al día con las leyes y los precedentes
fiscales? ¿Por qué los empleadores deberían contratar desarrolladores que no se mantienen actualizados?

Lea libros, artículos, blogs, tweets. Ir a conferencias. Ir a grupos de usuarios.

Participar en grupos de lectura y estudio. Aprenda cosas que están fuera de su zona de confort. Si
eres programador .NET, aprende Java. Si eres programador de Java, aprende Ruby. Si eres
programador de C, aprende Lisp. Si realmente quieres esforzarte, aprende Prolog and Forth.

PRÁCTICA

Los profesionales practican. Los verdaderos profesionales trabajan duro para mantener sus
habilidades afiladas y listas. No basta con hacer simplemente el trabajo diario y llamarlo práctica.
Hacer su trabajo diario es desempeño, no práctica. La práctica es cuando ejercita
específicamente sus habilidades fuera del desempeño de su trabajo con el único propósito de refinar
y mejorar esas habilidades.

¿Qué podría significar para un desarrollador de software practicar? A primera vista, el concepto
parece absurdo. Pero detente y piensa por un momento. Considere cómo los músicos dominan su oficio.
No es actuando. Es practicando. ¿Y cómo practican? Entre otras cosas, realizan ejercicios especiales.
Escalas, estudios y carreras. Lo hacen una y otra vez para entrenar sus dedos y su mente, y para
mantener el dominio de su habilidad.

19
Machine Translated by Google

CAPÍTULO 1 PROFESIONALISMO

Entonces, ¿qué podrían hacer los desarrolladores de software para practicar? Hay un capítulo completo
en este libro dedicado a diferentes técnicas de práctica, por lo que no entraré en muchos detalles aquí.
Una técnica que utilizo frecuentemente es la repetición de ejercicios sencillos como el Juego de Bolos o
los Factores Prime. A estos ejercicios los llamo kata. Hay muchos katas de este tipo para elegir.

Un kata suele presentarse en forma de un problema de programación sencillo de resolver, como escribir la
función que calcula los factores primos de un número entero. El objetivo de hacer el kata no es descubrir
cómo resolver el problema; ya sabes cómo hacerlo. El objetivo del kata es entrenar tus dedos y tu cerebro.

Haré uno o dos katas todos los días, a menudo como parte de mi adaptación al trabajo. Podría hacerlo en
Java, Ruby, Clojure o algún otro lenguaje en el que quiera mantener mis habilidades. Usaré el kata para
perfeccionar una habilidad en particular, como acostumbrar mis dedos a presionar teclas de acceso directo
o usar ciertas refactorizaciones.

Piense en el kata como un ejercicio de calentamiento de 10 minutos por la mañana y un ejercicio de

enfriamiento de 10 minutos por la noche.

COLABORACIÓN

La segunda mejor manera de aprender es colaborar con otras personas. Los desarrolladores de
software profesionales hacen un esfuerzo especial para programar, practicar, diseñar y planificar juntos. Al
hacerlo, aprenden mucho unos de otros y hacen más, más rápido y con menos errores.

Esto no significa que tengas que dedicar el 100% de tu tiempo a trabajar con otros.
El tiempo a solas también es muy importante. Por mucho que me guste combinar programas con
otros, me vuelve loco si no puedo escaparme solo de vez en cuando.

MENTORÍA

La mejor manera de aprender es enseñar. Nada te introducirá hechos y valores en tu cabeza más rápido
y con más fuerza que tener que comunicarlos a las personas de las que eres responsable. Por tanto,
el beneficio de la enseñanza favorece fuertemente al profesor.

20
Machine Translated by Google

ÉTICA DE TRABAJO

Del mismo modo, no hay mejor manera de incorporar gente nueva a una organización que
sentarse con ellos y mostrarles los entresijos. Los profesionales asumen la responsabilidad
personal de orientar a los jóvenes. No permitirán que un joven se mueva sin
supervisión.

CONOCE TU DOMINIO
Es responsabilidad de todo profesional del software comprender el dominio de las soluciones
que está programando. Si está escribiendo un sistema de contabilidad, debe conocer el campo
de la contabilidad. Si está escribiendo una solicitud de viaje, debe conocer la industria de
viajes. No es necesario ser un experto en el dominio, pero existe una cantidad razonable de
diligencia debida que debe realizar.

Al iniciar un proyecto en un nuevo dominio, lea uno o dos libros sobre el tema.
Entreviste a sus clientes y usuarios sobre los fundamentos y conceptos básicos del
dominio. Pase algún tiempo con los expertos e intente comprender sus principios y
valores.

El peor tipo de comportamiento poco profesional es simplemente codificar a partir de

una especificación sin comprender por qué esa especificación tiene sentido para el negocio.
Más bien, debería saber lo suficiente sobre el dominio para poder reconocer y cuestionar
los errores de especificación.

IDENTIFICA CON TU EMPLEADOR / CLIENTE

Los problemas de su empleador son sus problemas. Es necesario comprender cuáles son
esos problemas y trabajar para encontrar las mejores soluciones. A medida que desarrolla un
sistema, debe ponerse en el lugar de su empleador y asegurarse de que las funciones
que está desarrollando realmente satisfagan las necesidades de su empleador.

Es fácil para los desarrolladores identificarse entre sí. Es fácil caer en un nosotros
Actitud versus ellos con su empleador. Los profesionales evitan esto a toda costa.

21
Machine Translated by Google

CAPÍTULO 1 PROFESIONALISMO

HUMILDAD
La programación es un acto de creación. Cuando escribimos código estamos creando
algo de la nada. Estamos imponiendo audazmente orden al caos. Estamos controlando con
confianza, con detalle preciso, el comportamiento de una máquina que de otro modo podría
causar daños incalculables. Y entonces, la programación es un acto de
arrogancia suprema.

Los profesionales se saben arrogantes y no son falsamente humildes. Un profesional conoce su

trabajo y se enorgullece de su trabajo. Un profesional confía en sus capacidades y asume
riesgos audaces y calculados basándose en esa confianza. Un profesional no es tímido.

Sin embargo, un profesional también sabe que habrá momentos en los que fracasará, sus
cálculos de riesgo serán incorrectos, sus capacidades se quedarán cortas; se mirará en
el espejo y verá a un tonto arrogante sonriéndole.

Entonces, cuando un profesional sea el blanco de una broma, será el primero en reír.
Nunca ridiculizará a los demás, pero aceptará el ridículo cuando lo merezca y se reirá cuando
no lo sea. No degradará a otro por cometer un error, porque sabe que puede ser el próximo
en fallar.

Un profesional comprende su suprema arrogancia y que el destino eventualmente se dará cuenta

y nivelará su puntería. Cuando ese objetivo se conecta, lo mejor que puedes hacer es
seguir el consejo de Howard: reír.

BIBLIOGRAFÍA

[PPP2001]: Robert C. Martin, Principios, patrones y prácticas de desarrollo de software ágil, Upper
Saddle River, Nueva Jersey: Prentice Hall, 2002.

22
Machine Translated by Google

2DECIR NO

"Hacer; o no. No hay forma de intentarlo”.

—Yoda

A principios de los años 70, dos de mis amigos de diecinueve años y yo estábamos trabajando en un
sistema de contabilidad en tiempo real para el sindicato Teamster en Chicago para una empresa llamada
ASC. Si le vienen a la mente nombres como Jimmy Hoffa, debería hacerlo. No te metiste con los camioneros
en 1971.

Se suponía que nuestro sistema entraría en funcionamiento en una fecha determinada. En esa fecha había
mucho dinero en juego. Nuestro equipo había estado trabajando 60, 70 y 80 horas a la semana para intentar
cumplir con ese cronograma.

23
Machine Translated by Google

CAPÍTULO 2 DECIR NO

Una semana antes de la fecha de entrada en funcionamiento, finalmente conseguimos

montar el sistema en su totalidad. Había muchos errores y problemas que solucionar, y
trabajamos frenéticamente en la lista. Apenas había tiempo para comer y dormir, y mucho menos para pensar.

Frank, el director de ASC, era un coronel retirado de la Fuerza Aérea. Era uno de esos gerentes
ruidosos y directos. Era su camino o la autopista, y él te pondría en esa autopista lanzándote desde
10,000 pies sin paracaídas. Nosotros, los de diecinueve años, apenas pudimos establecer contacto
visual con él.

Frank dijo que tenía que estar hecho antes de la fecha. Eso fue todo lo que había que hacer.
Llegaría la fecha y habríamos terminado. Período. Sin discusión. Cambio y fuera.

Mi jefe, Bill, era un tipo simpático. Había estado trabajando con Frank durante bastantes años y
entendía lo que era posible con Frank y lo que no. Nos dijo que íbamos a vivir la fecha, pasara lo
que pasara.

Así que transmitimos la fecha en vivo. Y fue un desastre abrasador.

Había una docena de terminales semidúplex de 300 baudios que conectaban la sede de Teamster
en Chicago con nuestra máquina cincuenta kilómetros al norte, en los suburbios. Cada una de esas
terminales se cerraba cada 30 minutos aproximadamente. Habíamos visto este problema antes,
pero no habíamos simulado el tráfico que los ingresadores de datos del sindicato estaban
repentinamente ingresando a nuestro sistema.

Para empeorar las cosas, las hojas impresas en los teletipos ASR35 que también estaban
conectados a nuestro sistema mediante líneas telefónicas de 110 baudios se congelarían en
medio de la impresión.

La solución a estos congelamientos fue reiniciar. Por lo tanto, tendrían que hacer que todos
aquellos cuya terminal todavía estuviera activa terminaran su trabajo y luego se detuvieran. Cuando
todos estaban detenidos, nos llamaban para reiniciar. Las personas que habían quedado
congeladas tendrían que empezar de nuevo. Y esto sucedía más de una vez por hora.

Después de medio día así, el gerente de la oficina del Teamster nos dijo que apagáramos el
sistema y no lo volviéramos a encender hasta que lo tuviéramos funcionando. Mientras tanto, habían
perdido medio día de trabajo y iban a tener que reingresarlo todo usando el sistema antiguo.

24
Machine Translated by Google

DECIR NO

Escuchamos los gemidos y rugidos de Frank por todo el edificio. Continuaron durante mucho,
mucho tiempo. Luego Bill y el analista de nuestro sistema, Jalil, vinieron a vernos y nos
preguntaron cuándo podríamos tener el sistema estable. Dije: "cuatro semanas".

La expresión de sus rostros fue de horror y luego de determinación. “No”, dijeron, “debe estar
funcionando el viernes”.

Entonces dije: “Mira, apenas logramos que este sistema funcionara la semana pasada.
Necesitamos superar los problemas y las cuestiones. Necesitamos cuatro semanas”.

Pero Bill y Jalil se mantuvieron firmes. “No, realmente tiene que ser viernes. ¿Al menos
puedes intentarlo?

Entonces el líder de nuestro equipo dijo: "Está bien, lo intentaremos".

El viernes fue una buena elección. La carga del fin de semana fue mucho menor. Pudimos
encontrar más problemas y corregirlos antes de que llegara el lunes. Aun así, todo el castillo de
naipes estuvo a punto de derrumbarse de nuevo. Los problemas de congelación seguían ocurriendo
una o dos veces al día. También hubo otros problemas. Pero gradualmente, después de
algunas semanas más, logramos que el sistema llegara al punto en que las quejas
disminuyeron y parecía que la vida normal podría ser posible.

Y luego, como les dije en la introducción, todos renunciamos. Y se quedaron con una verdadera
crisis entre manos. Tuvieron que contratar un nuevo grupo de programadores para tratar de lidiar
con el enorme flujo de problemas provenientes del cliente.

¿A quién podemos culpar de esta debacle? Claramente, el estilo de Frank es parte del
problema. Sus intimidaciones le dificultaron escuchar la verdad.
Ciertamente, Bill y Jalil deberían haber presionado a Frank mucho más fuerte que lo hicieron.
Ciertamente nuestro jefe de equipo no debería haber cedido ante la exigencia del viernes.
Y ciertamente debería haber seguido diciendo "no" en lugar de ponerme en fila detrás del líder
de nuestro equipo.

Los profesionales le dicen la verdad al poder. Los profesionales tienen el coraje de decir no a sus
directivos.

25
Machine Translated by Google

CAPÍTULO 2 DECIR NO

¿Cómo le dices que no a tu jefe? Después de todo, ¡es tu jefe! ¿No se supone que debes hacer lo que
dice tu jefe?

No. No si eres un profesional.

A los esclavos no se les permite decir que no. Los trabajadores pueden dudar en decir que
no. Pero se espera que los profesionales digan que no. De hecho, los buenos directivos anhelan a
alguien que tenga el valor de decir que no. Es la única forma en que realmente puedes hacer algo.

A DV ROLES ERSARIALES

Uno de los críticos de este libro realmente odió este capítulo. Dijo que casi le hizo dejar el libro.
Había formado equipos donde no había relaciones de confrontación; Los equipos trabajaron juntos en
armonía y sin confrontación.

Me alegro por este crítico, pero me pregunto si sus equipos están realmente tan libres de confrontaciones
como él supone. Y si lo son, me pregunto si son tan eficientes como podrían ser. Mi propia
experiencia ha sido que las decisiones difíciles se toman mejor mediante la confrontación de roles
adversarios.

Los gerentes son personas con un trabajo que hacer y la mayoría de los gerentes saben cómo hacerlo
bastante bien. Parte de ese trabajo es perseguir y defender sus objetivos tan agresivamente
como puedan.

Del mismo modo, los programadores también son personas con un trabajo que hacer, y la mayoría
de ellos saben cómo realizarlo bastante bien. Si son profesionales, perseguirán y defenderán sus
objetivos tan agresivamente como puedan .

Cuando su jefe le dice que la página de inicio de sesión debe estar lista mañana, está persiguiendo y
defendiendo uno de sus objetivos. Él está haciendo su trabajo. Si sabe muy bien que es imposible
tener lista la página de inicio de sesión mañana, entonces no está haciendo su trabajo si dice "Está
bien, lo intentaré". La única manera de hacer tu trabajo, en ese momento, es decir "No, eso es
imposible".

¿Pero no tienes que hacer lo que dice tu jefe? No, su jefe cuenta con usted para defender
sus objetivos con tanta agresividad como él defiende los suyos.
Así es como ustedes dos llegarán al mejor resultado posible.

26
Machine Translated by Google

ROLES ADVERSARIOS

El mejor resultado posible es el objetivo que usted y su gerente comparten. El truco consiste en
encontrar ese objetivo, y eso suele requerir negociación.

A veces la negociación puede resultar placentera.

Mike: "Paula, necesito que la página de inicio de sesión esté lista mañana".

Paula: “¡Oh, guau! ¿Tan pronto? Bueno, está bien, lo intentaré”.

Mike: “Está bien, eso es genial. ¡Gracias!"

Esa fue una pequeña y agradable conversación. Se evitó toda confrontación. Ambas partes salieron
sonriendo. Lindo.

Pero ambas partes se comportaron de manera poco profesional. Paula sabe muy bien que la
página de inicio de sesión le llevará más de un día, así que simplemente está mintiendo.
Puede que no lo considere una mentira. Tal vez piense que realmente lo intentará, y tal vez
tenga una pequeña esperanza de lograrlo. Pero al final sigue siendo mentira.

Mike, por otro lado, aceptó el “lo intentaré” como un “sí”. Eso es simplemente una tontería. Debería haber
sabido que Paula estaba tratando de evitar la confrontación, por lo que debería haber insistido en el
tema diciendo: “Pareces vacilante. ¿Estás seguro de que podrás hacerlo mañana?

Aquí hay otra conversación agradable.

Mike: "Paula, necesito que la página de inicio de sesión esté lista mañana".

Paula: "Oh, lo siento Mike, pero me llevará más tiempo que eso".

Mike: "¿Cuándo crees que podrás hacerlo?"

Paula: “¿Qué tal dentro de dos semanas?”

Mike: (garabatea algo en su temporizador) "Está bien, gracias".

Por muy agradable que fuera, también fue terriblemente disfuncional y absolutamente poco
profesional. Ambas partes fracasaron en su búsqueda del mejor resultado posible.
En lugar de preguntar si dos semanas estaría bien, Paula debería haber sido más asertiva: "Me
llevará dos semanas, Mike".

27
Machine Translated by Google

CAPÍTULO 2 DECIR NO

Mike, por otro lado, simplemente aceptó la fecha sin cuestionarlo, como si sus propios objetivos no
importaran. Uno se pregunta si no va a informar simplemente a su jefe de que la demostración para
clientes tendrá que posponerse por culpa de Paula. Ese tipo de comportamiento pasivo­agresivo es
moralmente reprobable.

En todos estos casos ninguna de las partes ha perseguido un objetivo común aceptable. Ninguna de las
partes ha estado buscando el mejor resultado posible. Probemos esto.

Mike: "Paula, necesito que la página de inicio de sesión esté lista mañana".

Paula: "No, Mike, es un trabajo de dos semanas".

Mike: “¿Dos semanas? ¡Los arquitectos lo estimaron en tres días y ya han pasado cinco!

Paula: “Los arquitectos se equivocaron, Mike. Hicieron sus estimaciones antes de que
el marketing del producto se hiciera cargo de los requisitos. Tengo al menos
diez días más de trabajo por hacer en esto. ¿No viste mi estimación
actualizada en la wiki?

Mike: (luciendo severo y temblando de frustración) “Esto no es aceptable, Paula. Los clientes vendrán
mañana para una demostración y tengo que mostrarles la página de inicio de sesión en
funcionamiento”.

Paula: "¿Qué parte de la página de inicio de sesión necesitas trabajar

mañana?"

Mike: “¡Necesito la página de inicio de sesión! Necesito poder iniciar sesión”.

Paula: “Mike, puedo darte una maqueta de la página de inicio de sesión que te permitirá iniciar
sesión. Ya la tengo funcionando. En realidad, no verificará su nombre de usuario y
contraseña, y no le enviará por correo electrónico una contraseña olvidada. No tendrá el
banner de noticias de la compañía "Times­squareing" en la parte superior, y el botón
de ayuda y el texto flotante no funcionarán. No almacenará una cookie para
recordarlo la próxima vez y no le impondrá ninguna restricción de permiso. Pero podrás
iniciar sesión. ¿Eso bastará?

Mike: "¿Podré iniciar sesión?"

Paula: “Sí, podrás iniciar sesión”.

Mike: "¡Eso es genial, Paula, eres un salvavidas!" (se aleja bombeando aire y diciendo “¡Sí!”)

28
Machine Translated by Google

ALTOS EN JUEGO

Llegaron al mejor resultado posible. Lo hicieron diciendo que no y luego buscando una
solución que fuera mutuamente aceptable para ambos. Actuaban como profesionales. La
conversación fue un poco contradictoria y hubo algunos momentos incómodos, pero eso es
de esperarse cuando dos personas persiguen de manera asertiva objetivos que no están
perfectamente alineados.

¿ Y EL POR QUÉ ?

Quizás pienses que Paula debería haber explicado por qué la página de inicio de sesión
iba a tardar tanto más. Mi experiencia es que el por qué es mucho menos importante
que el hecho. El hecho es que la página de inicio de sesión requerirá dos semanas.
Por qué tardarán dos semanas es sólo un detalle.

Aún así, saber por qué podría ayudar a Mike a comprender y, por tanto, a aceptar el hecho.
Me parece bien. Y en situaciones en las que Mike tiene la experiencia técnica y el
temperamento para comprender, esas explicaciones podrían resultar útiles. Por otro lado,
Mike podría no estar de acuerdo con la conclusión. Mike podría decidir que Paula lo estaba
haciendo todo mal. Podría decirle que no necesita todas esas pruebas, ni todas esas
revisiones, o que el paso 12 podría omitirse. Proporcionar demasiados detalles puede
ser una invitación a la microgestión.

ALTAS APUESTAS

El momento más importante para decir no es cuando hay más en juego. Cuanto más hay en
juego, más valioso se vuelve el no.

Esto debería ser evidente. Cuando el costo del fracaso es tan alto que la supervivencia de su
empresa depende de ello, debe estar absolutamente decidido a brindar a sus gerentes la
mejor información posible. Y eso muchas veces significa decir no.

Don (Director de Desarrollo): “Entonces, nuestra estimación actual para la finalización

del proyecto Golden Goose es dentro de doce semanas, con una
incertidumbre de más o menos cinco semanas”.

Charles (CEO): (se queda mirando fijamente durante quince segundos mientras su cara se enrojece) “No

¿Quieres sentarte ahí y decirme que quizás falten diecisiete semanas para el
parto?

29
Machine Translated by Google

CAPÍTULO 2 DECIR NO

Don: "Eso es posible, sí".

Charles: (se levanta, Don se levanta un segundo después) “¡Maldita sea, Don! ¡Se
suponía que esto se haría hace tres semanas! Galitron me llama todos
los días preguntándome dónde está su maldito sistema.
¿ No les voy a decir que tienen que esperar otros cuatro meses? Tienes
que hacerlo mejor”.

Don: Chuck, te dije hace tres meses, después de todos los despidos, que necesitaríamos
cuatro meses más. Quiero decir, Cristo Chuck, ¡cortaste mi personal en un
veinte por ciento! ¿Le dijiste a Galitron entonces que llegaríamos tarde?
Charles: “Sabes muy bien que no lo hice. No podemos darnos el lujo de perder ese
pedido, Don. (Charles hace una pausa, su cara se pone blanca) Sin Galitron,
estamos realmente arruinados. Lo sabes, ¿no? Y ahora con este retraso,
me temo. . . ¿Qué le diré a la junta? (Se sienta lentamente en su asiento,
tratando de no desmoronarse.) Don, tienes que hacerlo mejor.

Don: “No hay nada que pueda hacer, Chuck. Ya hemos pasado por esto.
Galitron no reducirá el alcance y no aceptará ninguna liberación
provisional. Quieren hacer la instalación una vez y terminar de una vez.
Simplemente no puedo hacerlo más rápido. No va a suceder”.

Carlos: “Maldita sea. Supongo que no importaría si te dijera tu trabajo.

estaba en juego”.

Don: "Despedirme no va a cambiar la estimación, Charles".

Charles: “Hemos terminado aquí. Vuelve con tu equipo y mantén este proyecto.
emocionante. Tengo que hacer algunas llamadas telefónicas muy difíciles”.

Por supuesto, Charles debería haberle dicho a Galitron que no hace tres meses cuando se
enteró por primera vez de la nueva estimación. Al menos ahora está haciendo lo correcto
al llamarlos (y a la junta directiva). Pero si Don no se hubiera mantenido firme, esas
llamadas podrían haberse retrasado aún más.

SER UN “ JUGADOR DE EQUIPO” "

Todos hemos oído lo importante que es “jugar en equipo”. Ser un jugador de equipo significa
jugar tu posición lo mejor que puedas y ayudar a tus compañeros cuando se meten en un
aprieto. Un jugador de equipo se comunica con frecuencia, está atento a sus compañeros y
ejecuta sus propias responsabilidades lo mejor posible.

30
Machine Translated by Google

SER UN “ JUGADOR DE EQUIPO”

Un jugador de equipo no es alguien que dice sí todo el tiempo. Considere este escenario:

Paula: “Mike, tengo esas estimaciones para ti. El equipo está de acuerdo en que estaremos listos
para ofrecer una demostración en unas ocho semanas, una semana más o menos”.

Mike: "Paula, ya hemos programado la demostración para dentro de seis semanas".

Paula: “¿Sin saber nada de nosotros primero? Vamos Mike, no puedes presionar eso.
sobre nosotros”.

Mike: "Ya está hecho".

Paula: (suspiro) “Está bien, mira, volveré con el equipo y descubriré qué podemos entregar de
manera segura en seis semanas, pero no será todo el sistema. Faltarán algunas funciones
y la carga de datos estará incompleta”.

Mike: "Paula, el cliente espera ver una demostración completa".

Paula: "Eso no va a pasar, Mike".

Mike: “Maldita sea. Ok, elabora el mejor plan que puedas y házmelo saber.
mañana."

Paula: “Eso puedo hacerlo”.

Mike: “¿No hay algo que puedas hacer para adelantar esta fecha? Tal vez
hay una manera de trabajar de forma más inteligente y ser creativo”.

Paula: “Todos somos bastante creativos, Mike. Tenemos un buen manejo del
problema, y la fecha va a ser de ocho o nueve semanas, no de seis”.
Mike: "Podrías trabajar horas extras".

Paula: “Eso simplemente nos hace ir más lento, Mike. Recuerda el desastre que hicimos
¿La última vez que exigimos horas extras?

Mike: "Sí, pero eso no tiene por qué suceder esta vez".

Paula: “Será como la última vez, Mike. Confía en mí. Serán ocho o nueve semanas, no seis”.

Mike: “Está bien, consígueme tu mejor plan, pero sigue pensando en cómo hacerlo en seis
semanas. Sé que ustedes descubrirán algo”.

Paula: “No, Mike, no lo haremos. Te conseguiré un plan para seis semanas, pero le faltarán
muchas funciones y datos. Así es como va a ser”.

Mike: "Está bien, Paula, pero apuesto a que ustedes pueden hacer milagros si lo intentan".

(Paula se aleja sacudiendo la cabeza.)

Más tarde, en la reunión de estrategia del Director…

31
Machine Translated by Google

CAPÍTULO 2 DECIR NO

Don: “Está bien, Mike, como sabes, el cliente vendrá para una demostración dentro de seis
semanas. Esperan ver que todo funcione”.

Mike: “Sí, y estaremos listos. Mi equipo se está rompiendo el trasero con esto y lo vamos a
lograr. Tendremos que trabajar horas extras y ser bastante creativos, ¡pero lo
lograremos!”

Don: "Es fantástico que usted y su personal trabajen en equipo".

¿Quiénes eran los verdaderos jugadores del equipo en este escenario? Paula jugaba para el equipo,
porque representaba lo que se podía y no se podía hacer lo mejor que podía. Ella defendió
agresivamente su posición, a pesar de las zalamerías y halagos de Mike. Mike jugaba en un
equipo de uno. Mike es para Mike. Claramente no está en el equipo de Paula porque simplemente
la comprometió con algo que ella dijo explícitamente que no podía hacer. Tampoco está en el
equipo de Don (aunque no estaría de acuerdo) porque simplemente mintió entre dientes.

Entonces, ¿por qué Mike hizo esto? Quería que Don lo viera como un jugador de equipo y tiene fe
en su capacidad para engatusar y manipular a Paula para que intente cumplir el plazo de seis
semanas. Mike no es malvado; simplemente tiene demasiada confianza en su capacidad para
lograr que la gente haga lo que él quiere.

INTENTANDO

Lo peor que podría hacer Paula en respuesta a las manipulaciones de Mike es decir "Está bien, lo
intentaremos". Odio canalizar a Yoda aquí, pero en este caso tiene razón. No hay que intentarlo.

¿Quizás no te gusta esa idea? Quizás piense que intentarlo es algo positivo. Después de todo,
¿habría descubierto Colón América si no lo hubiera intentado?

La palabra intentar tiene muchas definiciones. La definición con la que discrepo aquí es
"aplicar un esfuerzo adicional". ¿Qué esfuerzo adicional podría aplicar Paula para tener la
demostración lista a tiempo? Si hay un esfuerzo adicional que ella podría aplicar, entonces
ella y su equipo no deben haber aplicado todo su esfuerzo antes. Debieron haber tenido
algún esfuerzo en reserva.1

1. Como Foghorn Leghorn: "Siempre mantengo mis plumas numeradas para tal emergencia".

32
Machine Translated by Google

SER UN “ JUGADOR DE EQUIPO”

La promesa de intentarlo es admitir que te has estado reprimiendo, que tienes una
reserva de esfuerzo adicional que puedes aplicar. La promesa de intentarlo es admitir
que la meta es alcanzable mediante la aplicación de este esfuerzo adicional; es más,
es un compromiso de aplicar ese esfuerzo extra para lograr el objetivo. Por lo tanto,
al prometer intentarlo, se compromete a tener éxito. Esto pone la carga sobre ti.
Si su “intento” no conduce al resultado deseado, habrá fracasado.

¿Tiene una reserva adicional de energía que ha estado reteniendo? Si aplicas estas
reservas, ¿podrás cumplir la meta? ¿O al prometer intentarlo simplemente se está
preparando para el fracaso?

Al prometer intentarlo, promete cambiar sus planes. Después de todo, los planes que
tenías eran insuficientes. Al prometer intentarlo estás diciendo que tienes un nuevo
plan. ¿Cuál es ese nuevo plan? ¿Qué cambio harás en tu comportamiento?
¿Qué cosas diferentes vas a hacer porque ahora lo estás “intentando”?

Si no tienes un nuevo plan, si no cambias tu comportamiento, si haces todo

exactamente como lo habrías hecho antes de prometer "intentar", entonces ¿qué
significa intentar?

Si no guarda algo de energía en reserva, si no tiene un nuevo plan, si no va a cambiar

su comportamiento y si tiene una confianza razonable en su estimación original,
entonces prometer intentarlo es fundamentalmente deshonesto. . Estás mintiendo. Y
probablemente lo esté haciendo para salvar las apariencias y evitar una confrontación.

El enfoque de Paula fue mucho mejor. Continuó recordándole a Mike que la

estimación del equipo era incierta. Ella siempre decía “ocho o nueve semanas”.
Hizo hincapié en la incertidumbre y nunca retrocedió. Ella nunca sugirió que podría
haber algún esfuerzo adicional, algún plan nuevo o algún cambio de comportamiento
que pudiera reducir esa incertidumbre.

Tres semanas después...

Mike: "Paula, la demostración será dentro de tres semanas y los

clientes exigen que File Upload funcione".
Paula: "Mike, esa no está en la lista de funciones que acordamos".

33
Machine Translated by Google

CAPÍTULO 2 DECIR NO

Mike: "Lo sé, pero lo exigen".

Paula: "Está bien, eso significa que el inicio de sesión único o la copia de seguridad tendrán que
ser eliminado de la demostración”.

Mike: “¡Por supuesto que no! ¡Esperan ver que esas funciones también funcionen!

Paula: “Entonces, esperan ver que todas las funciones funcionen. ¿Es eso lo que me
estás diciendo? Te dije que eso no iba a suceder”.

Mike: “Lo siento, Paula, pero el cliente no cede en esto. Ellos

Quiero verlo todo”.

Paula: “Eso no va a pasar, Mike. Simplemente no lo es”.

Mike: "Vamos Paula, ¿al menos no pueden intentarlo?"

Paula: “Mike, podría intentar levitar. Podría intentar cambiar el plomo por oro.
Podría intentar cruzar el Atlántico a nado. ¿Crees que lo lograría?

Mike: “Ahora estás siendo irrazonable. No estoy pidiendo lo imposible”.

Paula: "Sí, Mike, lo eres".

(Mike sonríe, asiente y se da vuelta para alejarse.)

Mike: “Tengo fe en ti Paula; Sé que no me decepcionarás”.

Paula: (hablando a la espalda de Mike) “Mike, estás soñando. Esto no va a terminar

bien”.

(Mike simplemente saluda sin darse la vuelta.)

AGRESIÓN PASIVA

Paula tiene que tomar una decisión interesante. Sospecha que Mike no le cuenta a Don sus
estimaciones. Podría simplemente dejar que Mike se cayera por el final del acantilado.
Podría asegurarse de tener copias de todos los memorandos apropiados archivados, de
modo que cuando ocurra el desastre pueda mostrar lo que le dijo a Mike y cuándo se lo dijo.
Esta es una agresión pasiva. Simplemente había dejado que Mike se ahorcara.

O podría intentar evitar el desastre comunicándose directamente con Don.

Esto es arriesgado, sin duda, pero también es de lo que se trata ser un jugador de equipo.
Cuando un tren de carga se acerca a ti y eres el único que puede verlo, puedes salirte
silenciosamente de la vía y ver cómo atropellan a todos los demás, o puedes gritar “¡Tren!
¡Sal de la pista!

34
Machine Translated by Google

SER UN “ JUGADOR DE EQUIPO”

Dos días después…

Paula: “Mike, ¿le has contado a Don sobre mis estimaciones? ¿Le ha dicho al
cliente que la demostración no tendrá funcionando la función de carga de archivos?

Mike: "Paula, dijiste que harías que eso funcionara para mí".

Paula: “No, Mike, no lo hice. Te dije que era imposible. Aquí tienes una copia del memorándum que
te envié después de nuestra charla.

Mike: "Sí, pero ibas a intentarlo de todos modos, ¿verdad?"

Paula: “Ya tuvimos esa conversación, Mike. ¿Recuerdas el oro y el plomo?

Mike: (suspira) “Mira, Paula, tienes que hacerlo. Sólo tienes que hacerlo. Por favor, haz lo que sea
necesario, pero sólo tienes que hacer que esto suceda por mí”.

Paula: “Mike. Estás equivocado. No tengo que hacer que esto suceda por ti.
Lo que tengo que hacer, si no lo haces, es decírselo a Don.

Mike: "Eso se me pasaría por alto, no harías eso".

Paula: “No quiero Mike, pero lo haré si me obligas”.

Mike: “Oh, Paula. . .”

Paula: “Mira, Mike, las funciones no estarán listas a tiempo para la demostración. Necesitas
meterte esto en la cabeza. Deja de intentar convencerme de que trabaje más duro. Deja
de engañarte pensando que de alguna manera voy a sacar un conejo de un sombrero.
Enfrenta el hecho de que tienes que decírselo a Don, y tienes que decírselo hoy”.

Mike: (Con los ojos muy abiertos) "¿Hoy?"

Paula: “Sí, Mike. Hoy. Porque mañana espero tener una reunión
contigo y con Don sobre qué funciones incluir en la demostración. Si esa reunión no ocurre
mañana, me veré obligado a ir yo mismo con Don. Aquí hay una copia del memorando
que explica precisamente eso”.

Mike: "¡Solo te estás cubriendo el trasero!"

Paula: “Mike, estoy tratando de cubrirnos el trasero a ambos . ¿Se imagina la debacle si el cliente
viene aquí esperando una demostración completa y no podemos entregársela?

¿Qué pasa al final con Paula y Mike? Te dejaré a ti resolver las posibilidades. La cuestión es que Paula se
ha portado de forma muy profesional. Ella ha dicho no en todos los momentos correctos y de todas las
formas correctas. Ella dijo que no cuando la empujaron.

35
Machine Translated by Google

CAPÍTULO 2 DECIR NO

para modificar sus estimaciones. Ella dijo que no cuando la manipularon, la engatusaron y la suplicaron.
Y, lo más importante, dijo no al autoengaño y la inacción de Mike. Paula jugaba para el equipo. Mike
necesitaba ayuda y ella utilizó todos los medios a su alcance para ayudarlo.

EL COSTO DE DECIR SÍ

La mayoría de las veces queremos decir que sí. De hecho, los equipos sanos se esfuerzan por encontrar
una manera de decir sí. Los gerentes y desarrolladores en equipos bien administrados negociarán entre
sí hasta llegar a un plan de acción mutuamente acordado.

Pero, como hemos visto, a veces la única manera de llegar al sí correcto es no tener miedo, así
que decir no.

Considere la siguiente historia que John Blanco publicó en su blog.2 Se reimprime

aquí con permiso. Mientras lo lees, pregúntate cuándo y cómo debería haber dicho que no.

¿ ES UN BUEN CÓDIGO IMPOSIBLE ?

Cuando llegas a la adolescencia decides que quieres ser desarrollador de software. Durante tus años de
escuela secundaria, aprendes a escribir software utilizando principios orientados a objetos.
Cuando te gradúas en la universidad, aplicas todos los principios que has aprendido en áreas como la
inteligencia artificial o los gráficos 3D.

Y cuando ingresa al circuito profesional, comienza su búsqueda interminable para escribir código
"perfecto", mantenible y de calidad comercial que resistirá la prueba del tiempo.

Calidad comercial. Eh. Eso es bastante divertido.

Me considero afortunada, me encantan los patrones de diseño. Me gusta estudiar la teoría de

la perfección de la codificación. No tengo ningún problema en iniciar una discusión de una hora
sobre por qué la elección de jerarquía de herencia de mi socio XP es incorrecta: que HAS­A es mejor
que IS­A en muchos casos. Pero algo me ha estado molestando últimamente y me pregunto algo. . .

. . . ¿Es imposible un buen código en el desarrollo de software moderno?

2. [Link]

36
Machine Translated by Google

EL COSTO DE DECIR SÍ

La propuesta de proyecto típica

Como desarrollador contratado a tiempo completo (y a tiempo parcial), paso mis días (y noches) desarrollando aplicaciones

móviles para clientes. Y lo que he aprendido a lo largo de los muchos años que llevo haciendo esto es que las demandas del trabajo

del cliente me impiden escribir las aplicaciones de calidad real que me gustaría.

Antes de comenzar, permítanme decir que no es por falta de intentos. Me encanta el tema del código limpio. No conozco a

nadie que busque ese diseño de software perfecto como yo. Es la ejecución la que me resulta más esquiva, y no por la razón que

crees.

Aquí, déjame contarte una historia.

Hacia finales del año pasado, una empresa bastante conocida presentó una RFP (Solicitud de propuesta)
para crear una aplicación para ellos. Son un gran minorista, pero por razones de anonimato, llamémoslos Gorilla
Mart. Dicen que necesitan crear una presencia en el iPhone y les gustaría tener una aplicación preparada para
ellos antes del Black Friday. ¿El truco? Ya es 1 de noviembre. Eso deja poco menos de 4 semanas para crear la
aplicación. Ah, y en este momento Apple todavía tarda dos semanas en aprobar aplicaciones. (Ah, los buenos
viejos tiempos). Entonces, espera, esta aplicación debe estar escrita en formato . . . ¡¿DOS SEMANAS?!?!

Sí. Tenemos dos semanas para escribir esta aplicación. Y, desgraciadamente, hemos ganado la licitación. (En los

negocios, la importancia del cliente es importante). Esto va a suceder.

"Pero está bien", dice el ejecutivo número 1 de Gorilla Mart. “La aplicación es sencilla. Sólo necesita mostrar a los usuarios
algunos productos de nuestro catálogo y permitirles buscar ubicaciones de tiendas. Ya lo hacemos en nuestro sitio.
También te daremos los gráficos. Probablemente puedas... ¿cuál es la palabra? Sí, ¡codificarlo!

El ejecutivo número 2 de Gorilla Mart interviene. “Y solo necesitamos un par de cupones que el usuario pueda mostrar en
la caja registradora. La aplicación será desechable. Saquémoslo y luego, para la Fase II, haremos algo más grande y
mejor desde cero”.

Y entonces está sucediendo. A pesar de años de recordatorios constantes de que cada característica que solicita un cliente siempre

será más compleja de escribir que de explicar, hágalo. Realmente crees que esta vez realmente se puede hacer en dos semanas.

¡Sí! ¡Podemos hacer esto! ¡Esta vez es diferente!

Son sólo unos pocos gráficos y una llamada de servicio para obtener la ubicación de una tienda. ¡XML! No preocuparse. Podemos

hacer esto. ¡Estoy entusiasmado! ¡Vamos!

Sólo hace falta un día para que usted y la realidad se vuelvan a conocer.

Yo: Entonces, ¿puedes darme la información que necesito para llamar al servicio web de ubicación de tu tienda?

El Cliente: ¿Qué es un servicio web?

A mí: …………

continúa

37
Machine Translated by Google

CAPÍTULO 2 DECIR NO

Y así es exactamente como sucedió. Su servicio de ubicación de tiendas, que se encuentra justo donde se supone que

debe estar en la esquina superior derecha de su sitio web, no es un servicio web. Está generado por código Java. Ix­no con la API­

ay. Y para empezar, está alojado por un socio estratégico de Gorilla Mart.

Ingrese el nefasto "tercero".

En términos de cliente, un “tercero” es similar a Angelina Jolie. A pesar de la promesa de que podrán tener una conversación

enriquecedora durante una buena comida y, con suerte, conectarse después... lo siento, no va a suceder. Tendrás que fantasear

con ello mientras te ocupas tú mismo de tus asuntos.

En mi caso, lo único que pude obtener de Gorilla Mart fue una instantánea actual de sus listados de tiendas actuales en un archivo

de Excel. Tuve que escribir el código de búsqueda de ubicación de la tienda desde cero.

El doble golpe llegó más tarde ese día: querían los datos del producto y del cupón en línea para poder cambiarlos semanalmente.

¡Ahí va la codificación! Dos semanas para escribir una aplicación para iPhone ahora se han convertido en dos semanas para

escribir una aplicación para iPhone, un backend PHP e integrarlos juntos. . . ¿Qué? ¿Quieren que yo también me ocupe del

control de calidad?

Para compensar el trabajo extra, la codificación tendrá que ser un poco más rápida. Olvídate de esa fábrica abstracta. Utilice un

bucle for grande y grueso en lugar del compuesto, ¡no hay tiempo!

Un buen código se ha vuelto imposible.

Dos semanas para completarse

Déjame decirte que dos semanas fueron bastante miserables. Primero, dos de los días fueron eliminados
debido a reuniones de todo el día para mi próximo proyecto. (Eso amplifica lo corto que iba a ser el período
de tiempo). Al final, realmente tuve ocho días para hacer las cosas. La primera semana trabajé 74 horas y
la semana siguiente. . . Dios . . . Ni siquiera lo recuerdo, ha sido erradicado de mis sinapsis.

Probablemente algo bueno.

Pasé esos ocho días escribiendo código con furia. Utilicé todas las herramientas disponibles para hacerlo: copiar y pegar

(también conocido como código reutilizable), números mágicos (evitando la duplicación de la definición de constantes y luego,

¡jadeo!, volver a escribirlas) y ¡absolutamente NINGUNA prueba unitaria! (¿Quién necesita barras rojas en un momento como

este? ¡Me desmotivaría!)

Era un código bastante malo y nunca tuve tiempo de refactorizarlo. Sin embargo, considerando el período de tiempo, en

realidad fue bastante estelar y, después de todo, era un código "desechable", ¿verdad? ¿Algo de esto te suena familiar? Bueno,

espera, se pone mejor.

Mientras estaba dando los toques finales a la aplicación (los toques finales eran escribir el código completo del servidor), comencé

a mirar el código base y me pregunté si tal vez valía la pena.

Después de todo, la aplicación estaba lista. ¡Sobreviví!

“Oye, acabamos de contratar a Bob, está muy ocupado y no pudo hacer la llamada, pero dice que deberíamos exigir a los
usuarios que proporcionen sus direcciones de correo electrónico para obtener los cupones. Él

38
Machine Translated by Google

EL COSTO DE DECIR SÍ

No ha visto la aplicación, ¡pero cree que sería una gran idea! También queremos un sistema de informes para
recibir esos correos electrónicos del servidor. Uno que sea bonito y no demasiado caro.
(Espera, la última parte fue Monty Python). Hablando de cupones, deben poder caducar después de una
cantidad de días que especifiquemos. Ah, y…”

Retrocedamos. ¿Qué sabemos sobre qué es un buen código? Un buen código debería ser extensible.
Mantenible. Debería prestarse a modificaciones. Debería leerse como prosa.
Bueno, este no era un buen código.

Otra cosa. Si quieres ser un mejor desarrollador, siempre debes tener esto inevitablemente en cuenta: el cliente
siempre ampliará el plazo. Siempre querrán más funciones. Siempre querrán un cambio, TARDE. Y aquí está la
fórmula de qué esperar:

(# de Ejecutivos)2
+ 2*# de Nuevos Ejecutivos
+ # de hijos de Bob
= DÍAS AÑADIDOS EN EL ÚLTIMO MINUTO

Ahora los ejecutivos son personas decentes. Creo. Mantienen a su familia (suponiendo que Satanás haya aprobado
que tengan una). Quieren que la aplicación tenga éxito (¡es hora de promocionar!). El problema es que
todos quieren tener derecho directo al éxito del proyecto. Cuando todo está dicho y hecho, todos quieren señalar
alguna característica o decisión de diseño que cada uno pueda considerar propia.

Entonces, volviendo a la historia, agregamos un par de días más al proyecto y completamos la función de correo
electrónico. Y luego me desplomé por el cansancio.

A los clientes nunca les importa tanto como a ti

A los clientes, a pesar de sus protestas, a pesar de su aparente urgencia, nunca les importa tanto como a usted que la
aplicación llegue a tiempo. La tarde en que di por terminada la aplicación, envié un correo electrónico con la versión
final a todas las partes interesadas, ejecutivos (¡silbido!), gerentes, etc.
“¡ESTÁ HECHO! ¡LES TRAIGO V1.0! ALABANZA TU NOMBRE”. Presioné Enviar, me recosté en mi silla y con una
sonrisa engreída comencé a fantasear cómo la compañía me subiría a sus hombros y encabezaría una
procesión por la calle 42 mientras yo era coronado como "El mejor desarrollador de todos los tiempos". Como mínimo,
mi cara estaría en toda su publicidad, ¿verdad?

Es curioso, no parecían estar de acuerdo. De hecho, no estaba seguro de lo que pensaban. No escuché nada. Ni
un pío. Resulta que la gente de Gorilla Mart estaba ansiosa y ya habían pasado al siguiente paso.

¿Crees que miento? Mira esto. Entré en la tienda de Apple sin completar la descripción de la aplicación.
Había solicitado uno a Gorilla Mart, no me habían respondido y no había tiempo para esperar. (Ver párrafo anterior).
Los escribí nuevamente. Y otra vez. Obtuve
continúa

39
Machine Translated by Google

CAPÍTULO 2 DECIR NO

algo de nuestra propia gestión al respecto. Dos veces recibí respuesta y dos veces me dijeron: "¿Qué necesitabas
otra vez?" ¡NECESITO LA DESCRIPCIÓN DE LA APLICACIÓN!

Una semana después, Apple empezó a probar la aplicación. Este suele ser un momento de alegría, pero en cambio
era un momento de temor mortal. Como era de esperar, más tarde ese mismo día la aplicación fue rechazada.
Se trataba de la excusa más triste y pobre para permitir un rechazo que pueda imaginar: "A la aplicación le falta una
descripción". Funcionalmente perfecto; sin descripción de la aplicación. Y por este motivo Gorilla Mart no tenía
lista su aplicación para el Black Friday. Estaba bastante molesto.

Había sacrificado a mi familia por un súper sprint de dos semanas, y nadie en Gorilla Mart podía molestarse en
crear una descripción de la aplicación en una semana de tiempo. Nos lo entregaron una hora después del rechazo;
aparentemente esa fue la señal para ponernos manos a la obra.

Si antes estaba molesto, me ponía furioso una semana y media después. Verás, todavía no nos habían
conseguido datos reales. Los productos y cupones del servidor eran falsos. Imaginario.
El código de cupón era 1234567890. Ya sabes, una tontería falsa. (Bolonia se escribe tontería cuando se usa en
ese contexto, por cierto).

Y fue esa fatídica mañana que revisé el Portal y ¡LA APLICACIÓN ESTABA DISPONIBLE!
¡Datos falsos y todo! Grité de horror abyecto, llamé a quien pude y grité: "¡NECESITO LOS DATOS!". y la mujer al
otro lado de la línea me preguntó si necesitaba bomberos o policía, así que colgué al 911. Pero luego llamé a Gorilla
Mart y dije: "¡NECESITO DATOS!". Y nunca olvidaré la respuesta:

Oh, hola, John. Tenemos un nuevo vicepresidente y hemos decidido no liberarlo. Sácalo de la App Store,
¿quieres?

Al final, resultó que al menos 11 personas registraron sus direcciones de correo electrónico en la base de
datos, lo que significaba que había 11 personas que potencialmente podrían entrar a un Gorilla Mart con un cupón
de iPhone falso a cuestas. Vaya, eso podría ponerse feo.

Cuando todo estuvo dicho y hecho, el cliente había dicho una cosa correctamente todo el tiempo: el código era
desechable. El único problema es que, para empezar, nunca se publicó.

Resultado ? Apresurarse para completarse, lento para comercializar

La lección de la historia es que las partes interesadas, ya sea un cliente externo o una administración interna,
han descubierto cómo lograr que los desarrolladores escriban código rápidamente. ¿Eficazmente? No.
¿Rápidamente? Sí. Así es como funciona:

• Dígale al desarrollador que la aplicación es sencilla. Esto sirve para presionar al

equipo de desarrollo en un estado de ánimo falso. También hace que los desarrolladores
comiencen a trabajar antes, por lo que...

40
Machine Translated by Google

CÓDIGO IMPOSIBLE

• Agregar funciones culpando al equipo por no reconocer su necesidad. En este caso, el

contenido codificado requeriría actualizaciones de la aplicación para cambiar.
¿Cómo podría no darme cuenta de eso? Lo hice, pero antes me habían hecho una
promesa falsa, por eso. O un cliente contratará a “un chico nuevo” que
reconoce que hay alguna omisión obvia. Un día, un cliente dirá que acaba de contratar
a Steve Jobs y ¿podemos agregar alquimia a la aplicación? Entonces ellos...
• Retrasar la fecha límite. Una y otra vez. Los desarrolladores trabajan más rápido
y más duro (y, por cierto, son más propensos a errores, pero ¿a quién le importa
eso, verdad?) cuando faltan un par de días para cumplir con la fecha límite. ¿Por
qué decirles que puedes retrasar más la fecha mientras ellos son tan productivos?
¡Aprovéchalo! Y así sigue, se suman unos días, se suma una semana, justo cuando
habías trabajado un turno de 20 horas para que todo saliera bien. Es como un burro
y una zanahoria, excepto que no te tratan tan bien como al burro.

Es un libro de jugadas brillante. ¿Puedes culparlos por pensar que funciona? Pero no ven el código espantoso. Y así sucede, una

y otra vez, a pesar de los resultados.

En una economía globalizada, donde las corporaciones están sujetas al todopoderoso dólar y el aumento del precio de las acciones

implica despidos, personal con exceso de trabajo y deslocalización, esta estrategia que les he mostrado para reducir los costos de los

desarrolladores está volviendo obsoleto el buen código. Como desarrolladores, nos preguntarán/

Nos dijeron/estafaron para que escribiéramos el doble de código en la mitad de tiempo si no tenemos cuidado.

CÓDIGO I IMPOSIBLE

En la historia, cuando John pregunta "¿Es imposible un buen código?", en realidad está
preguntando "¿Es imposible el profesionalismo?". Después de todo, no fue sólo el código el
que sufrió en su historia de disfunción. Eran su familia, su empleador, su cliente y los usuarios.
Todos perdieron3 en esta aventura. Y perdieron por falta de profesionalismo.

Entonces, ¿quién estaba actuando de manera poco profesional? John deja claro que cree que
fueron los ejecutivos de Gorilla Mart. Después de todo, su libro de jugadas era una
acusación bastante clara de su mal comportamiento. ¿Pero fue malo su comportamiento? No me parece.

3. Con la posible excepción del empleador directo de John, aunque apuesto a que ellos también perdieron.

41
Machine Translated by Google

CAPÍTULO 2 DECIR NO

La gente de Gorilla Mart quería tener la opción de tener una aplicación para iPhone el Black
Friday. Estaban dispuestos a pagar para tener esa opción. Encontraron a alguien dispuesto
a ofrecer esa opción. Entonces, ¿cómo puedes criticarlos?

Sí, es cierto, hubo algunos fallos de comunicación. Aparentemente los ejecutivos no

sabían qué era realmente un servicio web, y existían todos los problemas normales de una
parte de una gran corporación sin saber qué está haciendo otra parte. Pero todo eso debería
haberse esperado. John incluso lo admite cuando dice: “A pesar de años de constantes
recordatorios de que cada característica que solicita un cliente siempre será más compleja de
escribir que de explicar . . .”

Entonces, si el culpable no fue Gorilla Mart, ¿quién?

Quizás fue el empleador directo de John. John no dijo esto explícitamente, pero hubo una
insinuación cuando dijo, entre paréntesis: "En los negocios, la importancia del cliente
es importante". Entonces, ¿el empleador de John le hizo promesas irrazonables a Gorilla Mart?
¿Presionaron a John, directa o indirectamente, para que hiciera realidad esas promesas?
Juan no dice esto, así que sólo podemos preguntarnos.

Aun así, ¿dónde está la responsabilidad de Juan en todo esto? Le eché la culpa directamente
a John. John fue quien aceptó el plazo inicial de dos semanas, sabiendo muy bien que los
proyectos suelen ser más complejos de lo que parecen. John es quien aceptó la necesidad
de escribir el servidor PHP. John es quien aceptó el registro por correo electrónico y el
vencimiento del cupón. John es el que trabajó 20 horas al día y 90 horas a la semana. John es
quien se sustrajo de su familia y de su vida para cumplir con este plazo.

¿Y por qué Juan hizo esto? Nos dice en términos muy claros: “Presioné Enviar, me recosté
en mi silla y con una sonrisa engreída comencé a fantasear cómo la compañía me subiría a
sus hombros y encabezaría una procesión por la calle 42 mientras yo era coronado como “El
Mejor”. Desarrollador Ev­ar”. En resumen, John intentaba ser un héroe. Vio su oportunidad de
recibir elogios y la aprovechó. Se inclinó y agarró el anillo de latón.

Los profesionales suelen ser héroes, pero no porque lo intenten. Los profesionales se convierten
en héroes cuando hacen bien un trabajo, a tiempo y dentro del presupuesto. Al tratar de convertirse
en el hombre del momento, el salvador del día, John no estaba actuando como un profesional.

42
Machine Translated by Google

CÓDIGO IMPOSIBLE

John debería haber dicho no al plazo original de dos semanas. O si no, debería haber dicho
que no cuando descubrió que no había ningún servicio web. Debería haber dicho no a la
solicitud de registro por correo electrónico y vencimiento del cupón. Debería haber dicho no
a cualquier cosa que requiriera horribles horas extras y sacrificios.

Pero, sobre todo, John debería haber dicho no a su propia decisión interna de que la única
manera de terminar este trabajo a tiempo era haciendo un gran desastre. Observe lo que dijo John
sobre el buen código y las pruebas unitarias:

“Para compensar el trabajo extra, la codificación tendrá que ser un poco más rápida. Olvídate
de esa fábrica abstracta. Utilice un bucle for grande y grueso en lugar del compuesto, ¡no hay
tiempo!

Y de nuevo:

“Pasé esos ocho días escribiendo código con furia. Utilicé todas las herramientas disponibles
para hacerlo: copiar y pegar (también conocido como código reutilizable), números
mágicos (evitando la duplicación de la definición de constantes y luego, ¡jadeo!, volver a escribirlas)
y absolutamente ¡NINGUNA prueba unitaria! (¿Quién necesita barras rojas en un momento
como este? ¡Me desmotivaría!)”

Decir sí a esas decisiones fue el verdadero meollo del fracaso. John aceptó que la única manera
de tener éxito era comportarse de manera poco profesional, por lo que obtuvo la
recompensa adecuada.

Eso puede sonar duro. No está pensado de esa manera. En capítulos anteriores describí
cómo he cometido el mismo error en mi carrera, más de una vez. La tentación de ser un héroe
y “resolver el problema” es enorme. Lo que todos debemos darnos cuenta es que decir sí a
abandonar nuestras disciplinas profesionales no es la manera de resolver los problemas.
Abandonar esas disciplinas es la forma en que se crean problemas.

Con eso, finalmente puedo responder la pregunta inicial de John:

“¿Es imposible un buen código? ¿Es imposible el profesionalismo?

Respuesta: Yo digo que no.

43
Machine Translated by Google

Esta página se dejó en blanco intencionalmente.

Machine Translated by Google

3DECIR SÍ

¿Sabías que inventé el correo de voz? Es cierto. En realidad éramos tres los que
teníamos la patente del correo de voz. Ken Finder, Jerry Fitzpatrick y yo. Fue a
principios de los 80 y trabajábamos para una empresa llamada Teradyne. Nuestro
director ejecutivo nos había encargado que inventáramos un nuevo tipo de producto
e inventamos "La recepcionista electrónica", o ER para abreviar.

45
Machine Translated by Google

CAPÍTULO 3 DECIR SÍ

Todos sabéis qué es la sala de emergencias. ER es una de esas horribles máquinas que contestan el

teléfono en las empresas y te hacen todo tipo de preguntas con muerte cerebral que debes responder
presionando botones. (“Para inglés, presione 1”).

Nuestra sala de emergencias contestaría el teléfono de una empresa y le pediría que marcara el nombre
de la persona que desea. Le pedirá que pronuncie su nombre y luego llamará a la persona en cuestión.
Anunciaría la convocatoria y preguntaría si debería ser aceptada. Si es así, conectaría la llamada y la
finalizaría.

Podrías decirle a Urgencias dónde estabas. Podrías darle varios números de teléfono para probar.
Entonces, si estuviera en la oficina de otra persona, Emergencias podría encontrarlo. Si estuvieras
en casa, Emergencias podría encontrarte. Si estuvieras en una ciudad diferente, ER podría encontrarte.
Y, al final, si Emergencias no pudiera encontrarlo, necesitaría un mensaje. Ahí es donde entró el correo
de voz.

Por extraño que parezca, Teradyne no sabía cómo vender ER. El proyecto se quedó sin presupuesto
y se transformó en algo que sabíamos vender: CDS, The Craft Dispatch System, para enviar
reparadores de teléfonos a su siguiente trabajo. Y Teradyne también retiró la patente sin avisarnos. (!)
El actual titular de la patente la presentó tres meses después que nosotros. (!!)1

Mucho después de la transformación de ER en CDS, pero mucho antes de que descubriera que la
patente había sido retirada. Esperé en un árbol al director ejecutivo de la empresa. Teníamos un
gran roble afuera del frente del edificio. Subí y esperé a que llegara su Jaguar. Lo recibí en la puerta y
le pedí unos minutos. Él obedeció.

Le dije que realmente necesitábamos reiniciar el proyecto de emergencias. Le dije que estaba
seguro de que podría generar dinero. Me sorprendió diciendo: “Está bien, Bob, elabora un plan.
Muéstrame cómo puedo ganar dinero. Si lo haces, y lo creo, abriré urgencias nuevamente”.

No esperaba eso. Esperaba que dijera: “Tienes razón, Bob. Voy a empezar de nuevo ese proyecto y voy
a descubrir cómo ganar dinero en

1. No es que la patente valiera dinero para mí. Se lo vendí a Teradyne por 1 dólar, según mi empleo.
contrato (y no conseguí el dólar).

46
Machine Translated by Google

UN LENGUAJE DE COMPROMISO

él." Pero no. Me devolvió la carga. Y era una carga sobre la que sentía ambivalencia. Después
de todo, yo era un tipo de software, no un tipo de dinero. Quería trabajar en el proyecto ER,
no ser responsable de las pérdidas y ganancias. Pero no quería mostrar mi ambivalencia.
Entonces le di las gracias y salí de su oficina con estas palabras:

“Gracias Russ. Estoy comprometido. . . Supongo."

Dicho esto, permítanme presentarles a Roy Osherove, quien les dirá cuán patética fue esa declaración.

AL LENGUAJE DE COMPROMISO
Por Roy Osherove

Decir. Significar. Hacer.

Hay tres partes para hacer un compromiso.

1. Dices que lo harás.

2. Lo dices en serio .

3. Realmente lo haces .

Pero, ¿con qué frecuencia nos encontramos con otras personas (¡no nosotros mismos, por supuesto!)
que nunca llegan al final de estas tres etapas?

• Le preguntas al informático por qué la red es tan lenta y te responde: “Sí. Realmente necesitamos
conseguir algunos enrutadores nuevos”. Y sabes que nunca pasará nada en esa categoría.

• Le pides a un miembro del equipo que ejecute algunas pruebas manuales antes de verificar el código
fuente y él responde: “Claro. Espero llegar a ello al final del día”.
Y de alguna manera sientes que tendrás que preguntar mañana si realmente se realizó alguna prueba
antes del check­in.

• Su jefe entra en la habitación y murmura: "tenemos que actuar más rápido".

Y sabes que él realmente quiere decir que TÚ tienes que moverte más rápido. Él no va a hacer nada al
respecto.

47
Machine Translated by Google

CAPÍTULO 3 DECIR SÍ

Hay muy pocas personas que, cuando dicen algo, lo dicen en serio y luego lo hacen. Hay algunos que dicen
cosas y las dicen en serio , pero nunca las hacen. Y hay mucha más gente que promete cosas y ni siquiera
tiene la intención de cumplirlas. ¿Alguna vez escuchaste a alguien decir: "Hombre, realmente necesito perder
algo de peso" y sabías que no iban a hacer nada al respecto? Sucede todo el tiempo.

¿Por qué seguimos teniendo esa extraña sensación de que, la mayoría de las veces, la gente no está realmente
comprometida con hacer algo?

Peor aún, a menudo nuestra intuición puede fallarnos. A veces nos gustaría creer que alguien realmente

quiere decir lo que dice cuando en realidad no es así. Nos gustaría creerle a un desarrollador cuando
dice, presionado hasta la esquina, que puede terminar esa tarea de dos semanas en una semana, pero
no deberíamos.

En lugar de confiar en nuestras agallas, podemos usar algunos trucos relacionados con el lenguaje para intentar
descubrir si las personas realmente quieren decir lo que dicen. Y cambiando lo que decimos, podremos empezar
a encargarnos de los pasos 1 y 2 de la lista anterior por nuestra cuenta. Cuando decimos que nos
comprometeremos con algo, debemos decirlo en serio .

RECONOCIENDO EL COMPROMISO DE L AC KOF

Deberíamos mirar el lenguaje que utilizamos cuando nos comprometemos a hacer algo, como la señal
reveladora de lo que está por venir. En realidad, se trata más bien de buscar palabras concretas en lo que
decimos. Si no puede encontrar esas pequeñas palabras mágicas, es probable que no digamos lo que decimos
en serio o que no creamos que sea factible.

A continuación se muestran algunos ejemplos de palabras y frases que debe buscar y que son signos
reveladores de falta de compromiso:

• Necesidad/debería. "Necesitamos hacer esto". "Necesito perder peso". "Alguien

Deberíamos hacer que eso suceda”.

• Esperanza/deseo. "Espero terminar esto mañana". "Espero que podamos volver a encontrarnos algún
día". "Ojalá tuviera tiempo para eso". "Ojalá esta computadora fuera más rápida".

• Vamos. (no seguido de "yo...") "Nos vemos alguna vez". "Terminemos esto".

48
Machine Translated by Google

UN LENGUAJE DE COMPROMISO

Cuando empieces a buscar estas palabras, verás que empiezas a detectarlas en casi todas partes
a tu alrededor, e incluso en las cosas que les dices a los demás.

Descubrirás que tendemos a estar muy ocupados sin responsabilizarnos de las cosas.

Y eso no está bien cuando usted u otra persona confía en esas promesas como parte del trabajo. Sin
embargo, ya has dado el primer paso: empieza a reconocer la falta de compromiso a tu alrededor
y en ti.

Hemos oído cómo suena la falta de compromiso. ¿Cómo reconocemos el compromiso

real?

¿ CÓMO SUENA EL COMPROMISO ?

Lo que es común en las frases de la sección anterior es que asumen que las cosas están fuera
de “mis” manos o no asumen responsabilidad personal.
En cada uno de estos casos, las personas se comportan como si fueran víctimas de una situación
en lugar de tener el control de ella.

La verdadera verdad es que usted, personalmente, SIEMPRE tiene algo bajo su control.
control, por lo que siempre hay algo a lo que puedes comprometerte plenamente.

El ingrediente secreto para reconocer el compromiso real es buscar frases que suenen así: Lo haré. . .
por . . . (ejemplo: terminaré esto el martes).

¿Qué tiene de importante esta frase? Estás afirmando un hecho sobre algo que TÚ harás con un tiempo de
finalización claro. No estás hablando de nadie más que de ti mismo.
Estás hablando de una acción que emprenderás . Usted no “posiblemente” lo aceptará, o “podría llegar a
hacerlo”; lo lograrás .

No hay (técnicamente) salida a este compromiso verbal. Dijiste que lo harías y ahora sólo es posible
obtener un resultado binario: o lo haces o no.
Si no lo hace, la gente puede impedirle cumplir sus promesas. Te sentirás mal por no hacerlo. Te sentirás
incómodo diciéndole a alguien que no lo has hecho (si ese alguien te escuchó prometer que lo harías).

Da miedo, ¿no?

49
Machine Translated by Google

CAPÍTULO 3 DECIR SÍ

Estás asumiendo toda la responsabilidad por algo, frente a una audiencia de al menos una
persona. No eres solo tú parado frente al espejo o la pantalla de la computadora. Eres tú,
frente a otro ser humano y diciendo que lo harás. Ese es el comienzo del compromiso. Ponerse
en la situación que te obligue a hacer algo.

Ha cambiado el lenguaje que utiliza por un lenguaje de compromiso, y eso le ayudará a

superar las siguientes dos etapas: expresarlo en serio y cumplirlo.

Aquí hay una serie de razones por las que es posible que no lo digas en serio o no sigas con
algunas soluciones.

No funcionaría porque dependo de la persona X para hacer esto.

Sólo puedes comprometerte con cosas sobre las que tienes control total . Por ejemplo, si tu
objetivo es terminar un módulo que también depende de otro equipo, no puedes comprometerte
a terminar el módulo con total integración con el otro equipo. Pero puedes comprometerte
con acciones específicas que te llevarán a tu objetivo. Tú podrías:

• Siéntese durante una hora con Gary del equipo de infraestructura para comprender sus
dependencias.

• Cree una interfaz que abstraiga la dependencia de su módulo del otro

infraestructura del equipo.

• Reúnete al menos tres veces esta semana con el encargado de la construcción para asegurarte de que tu

Los cambios funcionan bien en el sistema de construcción de la empresa.

• Cree su propia compilación personal que ejecute sus pruebas de integración para el
módulo.

¿Ves la diferencia?

Si el objetivo final depende de otra persona, debes comprometerte con acciones específicas que
te acerquen al objetivo final.

50
Machine Translated by Google

UN LENGUAJE DE COMPROMISO

No funcionaría porque no sé realmente si se puede hacer.

Si no es posible hacerlo, aún puedes comprometerte con acciones que te acerquen al objetivo.
¡Descubrir si se puede hacer puede ser una de las acciones a las que comprometerse!

En lugar de comprometerte a corregir los 25 errores restantes antes del lanzamiento (lo cual
puede no ser posible), puedes comprometerte a realizar estas acciones específicas que te
acercarán a ese objetivo:

• Revise los 25 errores e intente recrearlos.

• Siéntese con el control de calidad que encontró cada error para ver una reproducción de ese error.

• Dedica todo el tiempo que tengas esta semana a intentar corregir cada error.

No funcionaría porque a veces simplemente no lo logro.

Eso sucede. Podría suceder algo inesperado, y así es la vida. Pero aún quieres estar a la altura de
las expectativas. En ese caso, es hora de cambiar las expectativas lo antes posible.

Si no puedes cumplir tu compromiso, lo más importante es levantar una señal de alerta lo antes
posible ante quien sea con quien te comprometiste.

Cuanto antes levantes la bandera a todas las partes interesadas, más probable será que
haya tiempo para que el equipo se detenga, reevalúe las acciones actuales que se están
tomando y decida si se puede hacer o cambiar algo (en términos de prioridades, por
ejemplo). Al hacer esto, su compromiso aún se puede cumplir o puede cambiar a un
compromiso diferente.

Algunos ejemplos son:

• Si programa una reunión para el mediodía en un café del centro con un colega y se queda
atascado en el tráfico, duda que podrá cumplir con su compromiso de llegar a tiempo.
Puede llamar a su colega tan pronto como se dé cuenta de que podría llegar tarde y avisarle.
Tal vez puedas encontrar un lugar más cercano para reunirte, o tal vez posponer la reunión.

51
Machine Translated by Google

CAPÍTULO 3 DECIR SÍ

• Si te comprometiste a resolver un error que creías que tenía solución y en algún momento
te das cuenta de que el error es mucho más espantoso de lo que pensabas anteriormente,
puedes levantar la bandera. Luego, el equipo puede decidir un curso de acción para
asumir ese compromiso (emparejamiento, aumentar posibles soluciones, lluvia de ideas) o
cambiar la prioridad y pasar a otro error más simple.

Un punto importante aquí es: si no le cuenta a nadie sobre el problema potencial lo

antes posible, no le está dando a nadie la oportunidad de ayudarlo a cumplir con su
compromiso.

RESUMEN
Crear un lenguaje de compromiso puede parecer un poco aterrador, pero puede ayudar a
resolver muchos de los problemas de comunicación que enfrentan los programadores hoy en
día: estimaciones, plazos y contratiempos en la comunicación cara a cara. Se le considerará
un desarrollador serio que cumple su palabra y esa es una de las mejores cosas que puede
esperar de nuestra industria.

~~~

APRENDER A DECIR “ SÍ ” "

Le pedí a Roy que contribuyera con ese artículo porque tocó una fibra sensible dentro de mí.
He estado predicando acerca de aprender a decir no durante algún tiempo. Pero es
igualmente importante aprender a decir que sí.

EL OTRO LADO DEL “INTENTAR ”

Imaginemos que Peter es responsable de algunas modificaciones en el motor de

clasificación. En privado estima que estas modificaciones le llevarán cinco o seis días. También
cree que redactar la documentación de las modificaciones le llevará algunas horas. El lunes
por la mañana, su manager, Marge, le pregunta por su estatus.

Marge: "Peter, ¿tendrás terminadas las modificaciones del motor de calificación para el viernes?"

Peter: "Creo que eso es factible".

52
Machine Translated by Google

APRENDER A DECIR “SÍ”

Marge: "¿Eso incluirá la documentación?"

Peter: "Intentaré hacerlo también".

Quizás Marge no pueda escuchar la vacilación en las declaraciones de Peter, pero ciertamente no
se está comprometiendo mucho. Marge hace preguntas que exigen respuestas booleanas, pero
las respuestas booleanas de Peter son confusas.

Observe el abuso de la palabra intentar. En el último capítulo utilizamos la definición de intento de

“esfuerzo extra”. Aquí, Peter está usando la definición de “tal vez, tal vez no”.

Sería mejor que Peter respondiera así:

Marge: "Peter, ¿tendrás terminadas las modificaciones del motor de calificación para el viernes?"

Peter: "Probablemente, pero podría ser el lunes".

Marge: "¿Eso incluirá la documentación?"

Peter: "La documentación me llevará unas horas más, por lo que es posible que sea el
lunes, pero podría ser hasta el martes".

En este caso el lenguaje de Peter es más honesto. Le está describiendo su propia

incertidumbre a Marge. Marge tal vez pueda lidiar con esa incertidumbre. Por otra parte, quizá no.

COMPROMETIRSE CON DISCIPLINA

Marge: “Peter, necesito un sí o un no definitivo. ¿Tendrá el motor de clasificación terminado

y documentado para el viernes?

Esta es una pregunta perfectamente justa que Marge haga. Tiene un horario que mantener y necesita
una respuesta binaria sobre el viernes. ¿Cómo debería responder Pedro?

Peter: “En ese caso, Marge, tendré que decir que no. Lo más pronto que pueda estar seguro
"Terminaré con las modificaciones y los documentos el martes".

Marge: "¿Te comprometes al martes?"

Peter: “Sí, lo tendré todo listo el martes”.

53
Machine Translated by Google

CAPÍTULO 3 DECIR SÍ

Pero, ¿qué pasa si Marge realmente necesita que las modificaciones y la documentación estén listas para el

viernes?

Marge: “Peter, el martes me plantea un verdadero problema. Willy, nuestro redactor técnico, estará

disponible el lunes. Tiene cinco días para terminar la guía del usuario. Si no tengo los

documentos del motor de calificación para el lunes por la mañana, nunca terminará el manual

a tiempo. ¿Puedes hacer los documentos primero?

Peter: “No, los mods tienen que ser lo primero, porque nosotros generamos los documentos.

a partir del resultado de las ejecuciones de prueba”.

Marge: "Bueno, ¿no hay alguna manera de que puedas terminar las modificaciones y el

¿Documentos antes del lunes por la mañana?

Ahora Peter tiene que tomar una decisión. Hay una buena posibilidad de que termine con las modificaciones del

motor de velocidad el viernes, e incluso podría terminar los documentos antes de irse a casa durante el fin de

semana. También podría trabajar algunas horas el sábado si las cosas demoran más de lo esperado . Entonces,

¿qué debería decirle a Marge?

Peter: "Mira Marge, hay muchas posibilidades de que pueda terminar todo el lunes por la mañana si dedico

algunas horas extra el sábado".

¿Eso resuelve el problema de Marge? No, simplemente cambia las probabilidades, y eso
es lo que Peter necesita decirle.

Marge: "¿Puedo contar el lunes por la mañana entonces?"

Peter: "Probablemente, pero no definitivamente".

Puede que eso no sea suficiente para Marge.

Marge: “Mira, Peter, realmente necesito una definición definitiva sobre esto. ¿Hay alguna manera de que

puedas comprometerte a terminar esto antes del lunes por la mañana?

Pedro podría verse tentado a romper la disciplina en este momento. Es posible que pueda terminar más rápido si no

escribe sus exámenes. Es posible que pueda terminar más rápido si no refactoriza. Es posible que pueda terminar

más rápido si no ejecuta el conjunto de regresión completo.

54
Machine Translated by Google

APRENDER A DECIR “SÍ”

Aquí es donde el profesional traza la línea. En primer lugar, Pedro simplemente se equivoca en
sus suposiciones. No terminará más rápido si no escribe sus exámenes. No terminará más rápido si
no refactoriza. No terminará más rápido si omite el conjunto de regresión completo. Años de
experiencia nos han enseñado que romper disciplinas sólo nos frena.

Pero en segundo lugar, como profesional tiene la responsabilidad de mantener ciertos

estándares. Su código necesita ser probado y es necesario realizar pruebas. Su código debe
estar limpio. Y tiene que asegurarse de no haber roto nada más en el sistema.

Peter, como profesional, ya se ha comprometido a mantener estos estándares. Todos los demás
compromisos que asuma deberían estar subordinados a ello. Por lo tanto, es necesario abortar toda

esta línea de razonamiento.

Peter: “No, Marge, realmente no hay manera de que pueda estar seguro de una fecha antes
del martes. Lo siento si eso arruina tu agenda, pero es simplemente la realidad a la
que nos enfrentamos”.

Marge: “Maldita sea. Realmente contaba con traer este antes.

¿Estás seguro?

Peter: "Estoy seguro de que podría ser hasta el martes, sí".

Marge: "Está bien, supongo que iré a hablar con Willy para ver si puede reorganizar su agenda".

En este caso Marge aceptó la respuesta de Peter y empezó a buscar otras opciones. ¿Pero
qué pasa si todas las opciones de Marge se han agotado? ¿Y si Pedro fuera la última esperanza?

Marge: “Peter, mira, sé que esto es una gran imposición, pero realmente necesito que encuentres
una manera de terminar todo esto para el lunes por la mañana. Es realmente
crítico. ¿No hay algo que puedas hacer?

Entonces ahora Peter comienza a pensar en trabajar algunas horas extras significativas, y
probablemente la mayor parte del fin de semana. Necesita ser muy honesto consigo mismo acerca
de su resistencia y reservas. Es fácil decir que harás muchas cosas los fines de semana, pero es
mucho más difícil reunir suficiente energía para hacer un trabajo de alta calidad.

55
Machine Translated by Google

CAPÍTULO 3 DECIR SÍ

Los profesionales conocen sus límites. Saben cuántas horas extras pueden aplicar
efectivamente y cuál será el costo.

En este caso, Peter se siente bastante seguro de que unas cuantas horas extra durante la
semana y algo de tiempo el fin de semana serán suficientes.

Peter: “Está bien, Marge, te diré una cosa. Llamaré a casa y limpiaré algo.
horas extras con mi familia. Si les parece bien, terminaré esta tarea el lunes
por la mañana. Incluso vendré el lunes por la mañana para asegurarme
de que todo vaya bien con Willy. Pero luego me iré a casa y no volveré hasta
el miércoles. ¿Trato?"

Esto es perfectamente justo. Peter sabe que puede hacer las modificaciones y los
documentos si trabaja horas extras. También sabe que será inútil durante un par de días

después de eso.

CONCLUSIÓN

Los profesionales no están obligados a decir sí a todo lo que se les pide.

Sin embargo, deberían trabajar duro para encontrar formas creativas de hacer posible el “sí”.
Cuando los profesionales dicen que sí, utilizan el lenguaje del compromiso para que no queden
dudas sobre lo que han prometido.

56
Machine Translated by Google

4 CODIFICACIÓN

En un libro anterior1 escribí mucho sobre la estructura y naturaleza del Código Limpio.
Este capítulo analiza el acto de codificar y el contexto que rodea ese acto.

Cuando tenía 18 años podía escribir bastante bien, pero tenía que fijarme en las teclas.
No podía escribir a ciegas. Así que una noche pasé unas cuantas horas delante de una
perforadora IBM 029 negándome a mirarme los dedos mientras escribía un programa que
había escrito en varios formularios de codificación. Examiné cada tarjeta después de
escribirla y descarté las que estaban escritas mal.

1. [Martín09]

57
Machine Translated by Google

CAPÍTULO 4 CODIFICACIÓN

Al principio escribí bastantes por error. Al final de la tarde los estaba escribiendo todos casi a la perfección.
Durante esa larga noche, me di cuenta de que escribir a ciegas tiene que ver con la confianza. Mis dedos
sabían dónde estaban las teclas, sólo tenía que ganarme la confianza de que no estaba cometiendo un
error. Una de las cosas que me ayudó con esa confianza es que podía sentir cuando estaba cometiendo
un error. Al final de la velada, si cometía un error, lo sabía casi al instante y simplemente expulsaba la tarjeta
sin mirarla.

Ser capaz de detectar tus errores es realmente importante. No sólo en mecanografiar, sino en todo.
Tener detección de errores significa que cierras muy rápidamente el ciclo de retroalimentación y aprendes
de tus errores mucho más rápidamente. He estudiado y dominado varias disciplinas desde ese día en el 029.
Descubrí que en cada caso la clave para el dominio es la confianza y el sentido del error.

Este capítulo describe mi conjunto personal de reglas y principios para la codificación. Estas reglas y principios
no se refieren a mi código en sí; se trata de mi comportamiento, estado de ánimo y actitud mientras escribo
código. Describen mi propio contexto mental, moral y emocional para escribir código. Éstas son las raíces
de mi confianza y de mi sensación de error.

Probablemente no estarás de acuerdo con todo lo que digo aquí. Después de todo, esto es algo profundamente
personal. De hecho, es posible que usted esté en total desacuerdo con algunas de mis actitudes y principios.
Está bien, no pretenden ser verdades absolutas para nadie más que para mí.
Lo que son es el enfoque de un hombre para convertirse en un codificador profesional.

Quizás, al estudiar y contemplar mi entorno de codificación personal, puedas aprender a arrebatarme la

piedra de la mano.

PREPARACIÓN

La codificación es una actividad intelectualmente desafiante y agotadora. Requiere un nivel de concentración

y enfoque que pocas otras disciplinas requieren. La razón de esto es que la codificación requiere que
usted haga malabarismos con muchos factores en competencia a la vez.

1. Primero, tu código debe funcionar. Debes entender cuál es el problema que tienes.
resolver y entender cómo resolver ese problema. Debe asegurarse de que el código que escriba sea una
representación fiel de esa solución. debes gestionar

58
Machine Translated by Google

PREPARACIÓN

cada detalle de esa solución sin dejar de ser coherente con el lenguaje, la plataforma, la
arquitectura actual y todos los defectos del sistema actual.

2. Su código debe resolver el problema que le planteó el cliente. A menudo el

Los requisitos del cliente en realidad no resuelven los problemas del cliente. Depende
de usted ver esto y negociar con el cliente para garantizar que se satisfagan sus
verdaderas necesidades.

3. Su código debe encajar bien en el sistema existente. No debería aumentar la rigidez,

fragilidad u opacidad de ese sistema. Las dependencias deben estar bien gestionadas.
En resumen, su código debe seguir principios de ingeniería sólidos.2

4. Su código debe ser legible por otros programadores. Esto no es simplemente un

Cuestión de escribir buenos comentarios. Más bien, requiere que diseñes el código de tal
manera que revele tu intención. Esto es difícil de hacer. De hecho, esto puede ser lo
más difícil que un programador pueda dominar.

Hacer malabarismos con todas estas preocupaciones es difícil. Es fisiológicamente difícil

mantener la concentración y la atención necesarias durante largos períodos de tiempo.
Agregue a esto los problemas y distracciones de trabajar en equipo, en una organización
y las preocupaciones y preocupaciones de la vida cotidiana. La conclusión es que la
posibilidad de distracción es alta.

Cuando no puedas concentrarte y concentrarte lo suficiente, el código que escribas será

incorrecto. Tendrá errores. Tendrá la estructura incorrecta. Será opaco y complicado. No
resolverá los problemas reales de los clientes. En resumen, habrá que reelaborarlo o
rehacerlo. Trabajar distraído genera desperdicio.

Si está cansado o distraído, no codifique. Sólo terminarás rehaciendo lo que hiciste. En su

lugar, encuentre una manera de eliminar las distracciones y tranquilizar su mente.

CÓDIGO DE LAS 3 A. M.

El peor código que escribí fue a las 3 am. Era el año 1988 y yo estaba trabajando en una
nueva empresa de telecomunicaciones llamada Clear Communications. Todos estábamos
dedicando muchas horas para generar "capital de esfuerzo". Por supuesto, todos
soñábamos con ser ricos.

2. [Martín03]

59
Machine Translated by Google

CAPÍTULO 4 CODIFICACIÓN

Una tarde muy tarde (o mejor dicho, una mañana muy temprano, para resolver un problema de
tiempo), hice que mi código se enviara un mensaje a sí mismo a través del sistema de envío de
eventos (a esto lo llamamos "envío de correo"). Ésta era la solución equivocada , pero a las 3 de la
madrugada parecía bastante buena. De hecho, después de 18 horas de codificación sólida (sin
mencionar las semanas de 60 a 70 horas), era todo lo que podía pensar.

Recuerdo sentirme muy bien conmigo mismo durante las largas horas que estuve trabajando.
Recuerdo sentirme dedicado. Recuerdo haber pensado que trabajar a las 3 de la madrugada es lo que
hacen los profesionales serios. ¡Qué equivocado estaba!

Ese código volvió en nuestra contra una y otra vez. Instituyó una estructura de diseño defectuosa que
todos usaban pero que constantemente tenían que solucionar. Causó todo tipo de extraños errores
de sincronización y extraños bucles de retroalimentación. Nos metíamos en bucles de correo
infinitos cuando un mensaje provocaba que se enviara otro, y luego otro, infinitamente.
Nunca tuvimos tiempo de reescribir este taco (eso creíamos), pero siempre parecíamos tener tiempo
para agregar otra verruga o parche para solucionarlo. El asunto creció y creció, rodeando ese código
de las 3 am con cada vez más equipaje y efectos secundarios. Años más tarde se había convertido
en una broma del equipo. Cada vez que estaba cansado o frustrado me decían: “¡Cuidado! ¡Bob está a
punto de enviarse un correo a sí mismo!

La moraleja de esta historia es: no escribas código cuando estés cansado. La dedicación y el
profesionalismo tienen más que ver con la disciplina que con las horas. Asegúrese de que su sueño, su
salud y su estilo de vida estén ajustados para que pueda dedicar ocho buenas horas al día.

CÓDIGO DE PREOCUPACIÓN

¿Alguna vez te has peleado mucho con tu cónyuge o amigo y luego has intentado codificar? ¿Notaste
que había un proceso en segundo plano ejecutándose en tu mente tratando de resolver, o al menos
revisar, la pelea? A veces puedes sentir el estrés de ese proceso de fondo en tu pecho o en la boca
del estómago.
Puede hacerte sentir ansioso, como cuando has tomado demasiado café o Coca­Cola Light. Es
una distracción.

Cuando estoy preocupado por una discusión con mi esposa, una crisis de un cliente o un niño enfermo,
no puedo mantener la concentración. Mi concentración flaquea. Me encuentro con los ojos en la
pantalla y los dedos en el teclado, sin hacer nada. Catatónico.

60
Machine Translated by Google

PREPARACIÓN

Paralizado. A un millón de millas de distancia, resolviendo el problema en segundo

plano en lugar de resolver el problema de codificación frente a mí.

A veces me obligo a pensar en el código. Podría obligarme a escribir una o dos líneas. Podría
esforzarme para aprobar uno o dos exámenes. Pero no puedo seguir así. Inevitablemente, me
encuentro cayendo en una insensibilidad estupefacta, sin ver nada a través de mis ojos abiertos,
revolviendo interiormente con la preocupación de fondo.

He aprendido que no es momento de codificar. Cualquier código que produzca será basura.
Entonces, en lugar de codificar, necesito resolver la preocupación.

Por supuesto, hay muchas preocupaciones que simplemente no se pueden resolver en una o dos
horas. Además, es poco probable que nuestros empleadores toleren por mucho tiempo nuestra
incapacidad para trabajar mientras resolvemos nuestros problemas personales. El truco consiste
en aprender a cerrar el proceso en segundo plano, o al menos reducir su prioridad para
que no sea una distracción continua.

Hago esto dividiendo mi tiempo. En lugar de obligarme a codificar mientras la preocupación de fondo
me molesta, dedicaré un bloque de tiempo, tal vez una hora, a trabajar en el problema que está
creando la preocupación. Si mi hijo está enfermo, llamaré a casa y me comunicaré. Si he tenido una
discusión con mi esposa, la llamaré y analizaré los problemas. Si tengo problemas de dinero, dedico
tiempo a pensar en cómo puedo afrontar los problemas financieros. Sé que no es probable
que resuelva los problemas en esta hora, pero es muy probable que pueda reducir la ansiedad y
silenciar el proceso en segundo plano.

Lo ideal sería que el tiempo dedicado a luchar con cuestiones personales fuera tiempo personal.
Sería una pena pasar una hora en la oficina de esta manera. Los desarrolladores profesionales
asignan su tiempo personal para garantizar que el tiempo que pasan en la oficina sea lo más
productivo posible. Eso significa que debes reservar específicamente tiempo en casa para calmar
tus ansiedades y no llevarlas a la oficina.

Por otro lado, si te encuentras en la oficina y las ansiedades de fondo están minando tu
productividad, entonces es mejor pasar una hora tranquilizándolas que usar la fuerza bruta
para escribir código que tendrás que desechar más tarde ( o peor, vivir con).

61
Machine Translated by Google

CAPÍTULO 4 CODIFICACIÓN

LA ZONA DE FLUJO
Se ha escrito mucho sobre el estado hiperproductivo conocido como “flujo”.
Algunos programadores la llaman "la Zona". Como se llame, probablemente estés familiarizado con él.
Es el estado de conciencia altamente enfocado y de visión de túnel en el que los programadores pueden
entrar mientras escriben código. En este estado se sienten productivos. En este estado se sienten
infalibles. Y por eso desean alcanzar ese estado y, a menudo, miden su autoestima por cuánto tiempo
pueden pasar allí.

Aquí hay una pequeña pista de alguien que ha estado de ida y vuelta: Evite la Zona.

Este estado de conciencia no es realmente hiperproductivo y ciertamente no es infalible. En realidad,

es sólo un suave estado de meditación en el que ciertas facultades racionales disminuyen en
favor de una sensación de velocidad.

Déjame ser claro sobre esto. Escribirás más código en la Zona. Si está practicando TDD, recorrerá
el bucle rojo/verde/refactor más rápidamente.
Y sentirás una leve euforia o una sensación de conquista . El problema es que pierdes parte del
panorama general mientras estás en la Zona, por lo que probablemente tomarás decisiones que
luego tendrás que retroceder y revertir. El código escrito en la Zona puede aparecer más rápido, pero
volverás a visitarlo más a menudo.

Hoy en día, cuando siento que me deslizo hacia la Zona, me alejo unos minutos.
Me aclaro la cabeza respondiendo algunos correos electrónicos o mirando algunos tweets. Si es cerca del
mediodía, haré una pausa para almorzar. Si estoy trabajando en un equipo, encontraré un compañero
de pareja.

Uno de los grandes beneficios de la programación de parejas es que es prácticamente imposible que una
pareja entre en la Zona. La Zona es un estado poco comunicativo, mientras que el emparejamiento
requiere una comunicación intensa y constante. De hecho, una de las quejas que escucho a menudo
sobre el emparejamiento es que bloquea la entrada a la Zona. ¡Bien! La Zona no es donde quieres estar.

Bueno, eso no es del todo cierto. Hay momentos en que la Zona es exactamente donde quieres estar.
Cuando estás practicando. Pero hablaremos de eso en otro capítulo.

62
Machine Translated by Google

LA ZONA DE FLUJO

MÚSICA

En Teradyne, a finales de los años 70, tenía una oficina privada. Yo era el administrador del
sistema de nuestro PDP 11/60, por lo que era uno de los pocos programadores a los que se les
permitía tener una terminal privada. Ese terminal era un VT100 que funcionaba a 9600 baudios y
estaba conectado al PDP 11 con 80 pies de cable RS232 que había tendido sobre los paneles del
techo desde mi oficina hasta la sala de computadoras.

Tenía un sistema estéreo en mi oficina. Era un tocadiscos, un amplificador y unos

altavoces de suelo viejos. Tenía una importante colección de vinilos, incluidos Led Zeppelin,
Pink Floyd y…. Bueno, ya te haces una idea.

Solía encender ese estéreo y luego escribir código. Pensé que ayudaba a mi
concentración. Pero me equivoqué.

Un día volví a un módulo que había estado editando mientras escuchaba la secuencia inicial de
The Wall. Los comentarios en ese código contenían letras de la pieza y anotaciones
editoriales sobre bombarderos en picado y bebés que lloraban.

Fue entonces cuando me di cuenta. Como lector del código, estaba aprendiendo más sobre la
colección de música del autor (yo) que sobre el problema que el código intentaba resolver.

Me di cuenta de que simplemente no codifico bien mientras escucho música. La música no me

ayuda a concentrarme. De hecho, el acto de escuchar música parece consumir algún recurso
vital que mi mente necesita para escribir código limpio y bien diseñado.

Quizás a ti no te funcione así. Quizás la música te ayude a escribir código. Conozco a mucha
gente que codifica con auriculares. Acepto que la música les pueda ayudar, pero también
sospecho que lo que realmente está pasando es que la música les está ayudando a entrar en la
Zona.

I NTERRUPCIONES

Visualícese mientras codifica en su estación de trabajo. ¿Cómo respondes cuando alguien

te hace una pregunta? ¿Les gritas? ¿Miras? ¿Tu lenguaje corporal les dice que se vayan porque
estás ocupado? En resumen, ¿eres grosero?

63
Machine Translated by Google

CAPÍTULO 4 CODIFICACIÓN

¿O dejas lo que estás haciendo y ayudas cortésmente a alguien que está estancado? ¿Los tratas como
te gustaría que te trataran a ti si estuvieras estancado?

La respuesta grosera a menudo proviene de la Zona. Es posible que le moleste que lo saquen a
rastras de la Zona, o que alguien interfiera con su intento de ingresar a la Zona. De cualquier
manera, la mala educación a menudo proviene de su relación con la Zona.

A veces, sin embargo, no es la Zona la que tiene la culpa, sino que estás tratando de entender algo
complicado que requiere concentración. Hay varias soluciones para esto.

El emparejamiento puede resultar muy útil como forma de afrontar las interrupciones. Su compañero de
pareja puede mantener a mano el contexto del problema en cuestión, mientras usted atiende una
llamada telefónica o una pregunta de un compañero de trabajo. Cuando regresas con tu compañero de
pareja, él rápidamente te ayuda a reconstruir el contexto mental que tenías antes de la interrupción.

TDD es otra gran ayuda. Si tiene una prueba reprobatoria, esa prueba contiene el contexto de dónde
se encuentra. Puede volver a él después de una interrupción y continuar haciendo pasar esa prueba
fallida.

Al final, por supuesto, habrá interrupciones que te distraigan y te hagan perder el tiempo. Cuando
sucedan, recuerde que la próxima vez puede ser usted quien necesite interrumpir a otra persona. De
modo que la actitud profesional es una buena voluntad cortés de ayudar.

ESCRIBIR EL BLOQUE DE R

A veces el código simplemente no llega. A mí me ha pasado esto y he visto que a otros les ha pasado.
Te sientas en tu estación de trabajo y no pasa nada.

A menudo encontrará otro trabajo que hacer. Leerás el correo electrónico. Leerás tweets. Revisarás
libros, horarios o documentos. Convocarás reuniones. Iniciarás conversaciones con otros. Hará
cualquier cosa para no tener que enfrentarse a esa estación de trabajo y ver cómo el código se niega
a aparecer.

64
Machine Translated by Google

BLOQUEO DEL ESCRITOR

¿Qué causa tales bloqueos? Ya hemos hablado de muchos de los factores.

Para mí, otro factor importante es el sueño. Si no duermo lo suficiente, simplemente no
puedo codificar. Otros son preocupación, miedo y depresión.

Aunque parezca mentira, existe una solución muy sencilla. Funciona casi siempre. Es fácil de
hacer y puede brindarle el impulso para escribir una gran cantidad de código.

La solución: encontrar pareja.

Es asombroso lo bien que funciona esto. Tan pronto como te sientas al lado de otra persona,
los problemas que te bloqueaban desaparecen. Hay un cambio fisiológico que se produce
cuando trabajas con alguien. No sé qué es, pero definitivamente puedo sentirlo. Hay
algún tipo de cambio químico en mi cerebro o en mi cuerpo que rompe el bloqueo y me pone
en marcha nuevamente.

Ésta no es una solución perfecta. A veces el cambio dura una o dos horas, para luego ser
seguido por un agotamiento tan severo que tengo que separarme de mi pareja y encontrar
algún hueco donde recuperarme. A veces, incluso cuando estoy sentado con alguien, no
puedo hacer más que simplemente esté de acuerdo con lo que esa persona está haciendo.
Pero para mí la reacción típica al emparejamiento es una recuperación de mi impulso.

ENTRADA CREATIVA

Hay otras cosas que hago para prevenir el bloqueo. Hace mucho tiempo aprendí que la
producción creativa depende del aporte creativo.

Leo mucho y leo todo tipo de material. Leo material sobre software, política, biología,
astronomía, física, química, matemáticas y mucho más. Sin embargo, creo que lo que mejor
estimula la producción creativa es la ciencia ficción.

Para ti, podría ser otra cosa. Quizás una buena novela de misterio, poesía o incluso una novela
romántica. Creo que el verdadero problema es que la creatividad genera creatividad.
También hay un elemento de escapismo. Las horas que paso lejos de mis problemas
habituales, mientras me estimulan activamente ideas creativas y desafiantes, dan como
resultado una presión casi irresistible para crear algo por mí mismo.

65
Machine Translated by Google

CAPÍTULO 4 CODIFICACIÓN

No todas las formas de aportación creativa funcionan para mí. Ver televisión no suele
ayudarme a crear. Ir al cine es mejor, pero sólo un poco. Escuchar música no me ayuda a
crear código, pero sí a crear presentaciones, charlas y videos. De todas las formas de
aportación creativa, nada funciona mejor para mí que la vieja ópera espacial.

DEPURACIÓN

Una de las peores sesiones de depuración de mi carrera ocurrió en 1972. Las

terminales conectadas al sistema de contabilidad de los Teamsters solían congelarse una o
dos veces al día. No había manera de forzar que esto sucediera. El error no prefirió ningún
terminal en particular ni ninguna aplicación en particular. No importaba lo que el usuario
hubiera estado haciendo antes de la congelación. En un momento la terminal estaba
funcionando bien y al minuto siguiente estaba irremediablemente congelada.

Se necesitaron semanas para diagnosticar este problema. Mientras tanto, los Teamsters
estaban cada vez más molestos. Cada vez que había un congelamiento, la persona
en esa terminal tenía que dejar de trabajar y esperar hasta poder coordinar a todos los
demás usuarios para terminar sus tareas. Luego nos llamarían y reiniciaríamos. Fue una
pesadilla.

Pasamos las primeras semanas simplemente recopilando datos entrevistando a las

personas que sufrieron los encierros. Les preguntábamos qué estaban haciendo en ese
momento y qué habían hecho anteriormente. Preguntamos a otros usuarios si notaron
algo en sus terminales en el momento de la congelación. Todas estas entrevistas
se realizaron por teléfono porque las terminales estaban ubicadas en el centro de Chicago,
mientras trabajábamos 30 millas al norte en los campos de maíz.

No teníamos registros, contadores ni depuradores. Nuestro único acceso a las partes internas
del sistema eran las luces y los interruptores de palanca en el panel frontal. Podríamos detener
la computadora y luego mirar en la memoria una palabra a la vez. Pero no pudimos
hacer esto por más de cinco minutos porque los Teamsters necesitaban una copia de
seguridad de su sistema.

Pasamos unos días escribiendo un inspector simple en tiempo real que pudiera operarse
desde el teletipo ASR­33 que servía como nuestra consola. Con esto pudimos asomarnos

66
Machine Translated by Google

DEPURACIÓN

y hurgar en la memoria mientras el sistema estaba funcionando. Agregamos mensajes de registro que
se imprimían en el teletipo en momentos críticos. Creamos contadores en memoria que contaban eventos y
recordaban el historial del estado que podíamos inspeccionar con el inspector. Y, por supuesto, todo
esto tuvo que escribirse desde cero en ensamblador y probarse por las tardes cuando el sistema no
estaba en uso.

Las terminales fueron impulsadas por interrupciones. Los caracteres que se enviaban a las terminales se
guardaban en buffers circulares. Cada vez que un puerto serie terminaba de enviar un carácter, se activaba una
interrupción y el siguiente carácter en el búfer circular estaba listo para enviar.

Finalmente descubrimos que cuando una terminal se congelaba era porque las tres variables que administraban
el búfer circular no estaban sincronizadas. No teníamos idea de por qué sucedía esto, pero al menos era una
pista. En algún lugar de los 5 KSLOC del código de supervisión había un error que manejaba mal uno de esos
punteros.

¡Este nuevo conocimiento también nos permitió descongelar terminales manualmente! Podríamos introducir
valores predeterminados en esas tres variables usando el inspector, y las terminales mágicamente
comenzarían a funcionar nuevamente. Finalmente, escribimos un pequeño truco que revisaría todos los
contadores para ver si estaban desalineados y repararlos. Al principio invocamos ese truco presionando
un interruptor especial de interrupción de usuario en el panel frontal cada vez que los Teamsters llamaban
para informar un congelamiento.
Luego simplemente ejecutamos la utilidad de reparación una vez por segundo.

Aproximadamente un mes después, la cuestión de la congelación estaba muerta, en lo que a los Teamsters
se refería. De vez en cuando, uno de sus terminales se detenía durante aproximadamente medio segundo, pero
a una velocidad base de 30 caracteres por segundo, nadie parecía darse cuenta.

Pero ¿por qué se desalineaban los contadores? Tenía diecinueve años y estaba decidido a
descubrirlo.

El código de supervisión había sido escrito por Richard, que desde entonces había ido a la universidad.
Ninguno de nosotros estaba familiarizado con ese código porque Richard se había mostrado bastante posesivo
con él. Ese código era suyo y no se nos permitió saberlo. Pero ahora Richard ya no estaba, así que saqué la
lista de varios centímetros de grosor y comencé a repasarla página por página.

67
Machine Translated by Google

CAPÍTULO 4 CODIFICACIÓN

Las colas circulares en ese sistema eran solo estructuras de datos FIFO, es decir, colas.
Los programas de aplicación empujaban caracteres en un extremo de la cola hasta que la cola
se llenaba. Los cabezales de interrupción sacaron los caracteres del otro extremo de la cola
cuando la impresora estaba lista para recibirlos. Cuando la cola estaba vacía, la impresora se
detenía. Nuestro error hizo que las aplicaciones pensaran que la cola estaba llena, pero provocó
que los cabezales de interrupción pensaran que la cola estaba vacía.

Los cabezales de interrupción se ejecutan en un "hilo" diferente al del resto del código. Por lo
tanto, los contadores y las variables que son manipulados tanto por los cabezales de interrupción
como por otro código deben protegerse de actualizaciones simultáneas. En nuestro
caso, eso significó desactivar las interrupciones alrededor de cualquier código que manipulara
esas tres variables. Cuando me senté con ese código, sabía que estaba buscando algún lugar
en el código que tocara las variables pero que no deshabilitara las interrupciones primero.

Hoy en día, por supuesto, usaríamos la gran cantidad de herramientas poderosas a nuestra
disposición para encontrar todos los lugares donde el código toca esas variables. En cuestión de
segundos conoceríamos cada línea de código que los tocara. En cuestión de minutos sabríamos
cuál no deshabilitó las interrupciones. Pero esto era 1972 y yo no tenía herramientas como esas.
Lo que tenía eran mis ojos.

Revisé minuciosamente cada página de ese código, buscando las variables. Desafortunadamente,
las variables se utilizaron en todas partes. Casi todas las páginas los tocaban de una forma u otra.
Muchas de esas referencias no desactivaban las interrupciones porque eran referencias de sólo
lectura y, por tanto, inofensivas. El problema era que en ese ensamblador en particular no
había una buena manera de saber si una referencia era de solo lectura sin seguir la lógica
del código. Cada vez que se lee una variable, es posible que luego se actualice y almacene.
Y si eso sucediera mientras las interrupciones estaban habilitadas, las variables podrían
corromperse.

Me tomó días de intenso estudio, pero al final lo encontré. Allí, en medio del código, había un
lugar donde una de las tres variables se actualizaba mientras las interrupciones estaban
habilitadas.

Hice los cálculos. La vulnerabilidad duró aproximadamente dos microsegundos. Había una docena
de terminales, todas funcionando a 30 cps, por lo que había una interrupción cada 3 ms
aproximadamente. Dado el tamaño del supervisor y la frecuencia de reloj de la CPU, esperaríamos
que esta vulnerabilidad se congelara una o dos veces al día. ¡Bingo!

68
Machine Translated by Google

MARCANDO TU MISMO

Solucioné el problema, por supuesto, pero nunca tuve el coraje de apagar el hack automático que
inspeccionaba y reparaba los contadores. Hasta el día de hoy no estoy convencido de que no hubiera
otro agujero.

TIEMPO DE DEPURACIÓN

Por alguna razón, los desarrolladores de software no consideran el tiempo de depuración como tiempo de
codificación. Piensan que el tiempo de depuración es una llamada de la naturaleza, algo que simplemente tiene
por hacer. Pero el tiempo de depuración es tan costoso para el negocio como lo es el tiempo de codificación
y, por lo tanto, cualquier cosa que podamos hacer para evitarlo o disminuirlo es bueno.

Hoy en día dedico mucho menos tiempo a depurar que hace diez años. No he medido la diferencia, pero creo
que es aproximadamente un factor de diez. Logré esta reducción verdaderamente radical en el tiempo de

depuración adoptando la práctica de Test Driven Development (TDD), que discutiremos en otro capítulo.

Ya sea que adopte TDD o alguna otra disciplina de igual eficacia,3 le corresponde a usted, como
profesional, reducir su tiempo de depuración lo más cerca posible de cero. Claramente cero es una meta
asintótica, pero no deja de ser la meta.

A los médicos no les gusta reabrir a los pacientes para arreglar algo que hicieron mal. A los abogados no les
gusta volver a juzgar casos en los que fallaron. Un médico o abogado que hiciera eso con demasiada
frecuencia no sería considerado profesional. Del mismo modo, un desarrollador de software que crea muchos
errores no actúa de forma profesional.

EMPACIÉNATE

El desarrollo de software es un maratón, no una carrera de velocidad. No puedes ganar la carrera

intentando correr lo más rápido que puedas desde el principio. Usted gana conservando sus recursos y
controlando su ritmo. Una corredora de maratón cuida su cuerpo tanto antes como durante la carrera. Los
programadores profesionales conservan su energía y creatividad con el mismo cuidado.

3. No conozco ninguna disciplina que sea tan efectiva como TDD, pero quizás tú sí.

69
Machine Translated by Google

CAPÍTULO 4 CODIFICACIÓN

SEPA CUANDO ALEJARSE

¿No puedes volver a casa hasta que resuelvas este problema? ¡Oh, sí puedes, y
probablemente deberías hacerlo! La creatividad y la inteligencia son estados mentales
fugaces. Cuando estás cansado, desaparecen. Si luego golpeas tu cerebro que no funciona
durante una hora tras otra a altas horas de la noche tratando de resolver un problema,
simplemente te cansarás más y reducirás las posibilidades de que la ducha o el auto te
ayuden a resolver el problema.

Cuando estés estancado, cuando estés cansado, desconéctate por un rato. Dale a tu
subconsciente creativo una oportunidad para resolver el problema. Hará más cosas en
menos tiempo y con menos esfuerzo si tiene cuidado de administrar sus recursos.
Controle su ritmo y el de su equipo. Conozca sus patrones de creatividad y brillantez, y
aprovéchelos en lugar de trabajar en su contra.

CONDUCIR A CASA

Un lugar en el que he solucionado varios problemas es mi coche de camino a casa desde el

trabajo. Conducir requiere muchos recursos mentales no creativos. Debes dedicar tus
ojos, manos y partes de tu mente a la tarea; por lo tanto, debes desvincularte de los problemas
en el trabajo. Hay algo en la desconexión que le permite a tu mente buscar
soluciones de una manera diferente y más creativa.

LA DUCHA
He solucionado una cantidad desmesurada de problemas en la ducha. Quizás ese chorro
de agua temprano en la mañana me despierte y me haga revisar todas las soluciones que
se le ocurrieron a mi cerebro mientras dormía.

Cuando estás trabajando en un problema, a veces te acercas tanto a él que no puedes ver
todas las opciones. Echas de menos soluciones elegantes porque la intensidad de tu
concentración suprime la parte creativa de tu mente. A veces, la mejor manera de resolver un
problema es volver a casa, cenar, mirar televisión, acostarse y luego despertarse a la
mañana siguiente y darse una ducha.

70
Machine Translated by Google

LLEGAR TARDE

LLEGAR TARDE

Llegarás tarde . Nos pasa a los mejores. Nos pasa a los más dedicados. A veces simplemente
arruinamos nuestras estimaciones y terminamos tarde.

El truco para gestionar los retrasos es la detección temprana y la transparencia. El peor de los
casos ocurre cuando continúas diciéndoles a todos, hasta el final, que llegarás a tiempo y luego
los decepcionas a todos. No hagas esto. En su lugar, mida periódicamente su progreso respecto
de su objetivo y proponga tres4
Fechas de finalización basadas en hechos: mejor caso, caso nominal y peor caso. Sea lo más
honesto posible sobre las tres fechas. ¡No incorpores esperanza en tus estimaciones!
Presente los tres números a su equipo y a las partes interesadas. Actualice estos números
diariamente.

ESPERANZA

¿Qué pasa si estos números muestran que es posible que no cumpla con una fecha límite? Por
ejemplo, digamos que hay una feria comercial en diez días y necesitamos tener nuestro producto allí.
Pero digamos también que su estimación de tres números para la función en la que está
trabajando es 12/08/20.

¡No esperes poder hacerlo todo en diez días! La esperanza es la asesina del proyecto.
La esperanza destruye horarios y arruina reputaciones. La esperanza te meterá en serios
problemas. Si la feria es en diez días y su estimación nominal es 12, no podrá asistir. Asegúrese
de que el equipo y las partes interesadas comprendan la situación y no cese hasta que
haya un plan alternativo. No dejes que nadie más tenga esperanza.

R USANDO

¿Qué pasa si su gerente lo sienta y le pide que intente cumplir con la fecha límite?
¿Qué pasa si su jefe insiste en que usted “haga lo que sea necesario”? ¡Cumpla con sus estimaciones!
Sus estimaciones originales son más precisas que cualquier cambio que realice mientras

4. Hay mucho más sobre esto en el capítulo de Estimación.

71
Machine Translated by Google

CAPÍTULO 4 CODIFICACIÓN

Tu jefe te está confrontando. Dígale a su jefe que ya ha considerado las opciones (porque las
ha hecho) y que la única forma de mejorar el cronograma es reducir el alcance. No caigas en la
tentación de apresurarte.

¡Ay del pobre desarrollador que cede ante la presión y acepta intentar cumplir con el plazo!
Ese desarrollador comenzará a tomar atajos y a trabajar horas extra con la vana esperanza de
obrar un milagro. Esta es una receta para el desastre porque le brinda a usted, a su equipo y a
sus partes interesadas falsas esperanzas. Permite que todos eviten enfrentar el problema y
retrasa las decisiones difíciles necesarias.

No hay manera de apresurarse. No puedes codificar más rápido. No puedes obligarte a

resolver los problemas más rápido. Si lo intentas, simplemente te retrasarás y crearás un
desastre que también ralentizará a todos los demás.

Por lo tanto, debes responder a tu jefe, a tu equipo y a tus partes interesadas privándolos de
esperanza.

CON EL TIEMPO

Entonces tu jefe te dice: “¿Qué pasa si trabajas dos horas más al día? ¿Qué pasa si trabajas el
sábado? Vamos, tiene que haber una manera de dedicar suficientes horas para terminar la
función a tiempo”.

Las horas extras pueden funcionar y, a veces, son necesarias. A veces puedes hacer una cita
que de otro modo sería imposible dedicando algunas jornadas de diez horas y un sábado o
dos. Pero esto es muy arriesgado. No es probable que consigas realizar un 20% más de
trabajo trabajando un 20% más de horas. Es más, las horas extras ciertamente fracasarán si se
prolongan durante más de dos o tres semanas.

Por lo tanto, no debe aceptar trabajar horas extras a menos que (1) pueda permitírselo
personalmente, (2) sea a corto plazo, dos semanas o menos, y (3) su jefe tenga un plan
alternativo en caso de que el esfuerzo de horas extras falle.

Ese último criterio es un factor decisivo. Si su jefe no puede explicarle lo que va a hacer si el
trabajo de horas extra falla, entonces no debe aceptar trabajar horas extras.

72
Machine Translated by Google

AYUDA

ENTREGA FALSA

De todos los comportamientos poco profesionales que puede tener un programador, quizás el
peor de todos es decir que ya terminaste cuando sabes que no es así. A veces esto es sólo
una mentira abierta, y eso ya es bastante malo. Pero el caso mucho más insidioso es cuando
logramos racionalizar una nueva definición de "hecho". Nos convencemos de que
hemos hecho lo suficiente y pasamos a la siguiente tarea. Racionalizamos que cualquier trabajo
que quede se puede abordar más adelante, cuando tengamos más tiempo.

Esta es una práctica contagiosa. Si un programador lo hace, otros lo verán y harán lo mismo.
Uno de ellos ampliará aún más la definición de “hecho” y todos los demás adoptarán la nueva
definición. He visto esto llevado a extremos horribles. De hecho, uno de mis clientes definió
"hecho" como "registrado". El código ni siquiera tuvo que compilarse. ¡Es muy fácil “terminarlo”
si nada tiene que funcionar!

Cuando un equipo cae en esta trampa, los directivos escuchan que todo va bien. Todos los
informes de estado muestran que todos llegan a tiempo. Es como si los ciegos hicieran un picnic
en las vías del tren: nadie ve el tren de carga de trabajos inacabados que se acerca a ellos hasta
que es demasiado tarde.

DEFINIR “D UNO ” "

Se evita el problema de la entrega falsa creando una definición independiente de "hecho". La

mejor manera de hacerlo es hacer que sus analistas y evaluadores de negocios creen
pruebas de aceptación automatizadas5 que deben aprobarse antes de que pueda decir que
ha terminado. Estas pruebas deben escribirse en un lenguaje de prueba como FitNesse,
Selenium, RobotFX, Cucumber, etc. Las pruebas deben ser comprensibles para las partes
interesadas y los empresarios, y deben realizarse con frecuencia.

AYUDA

La programación es difícil. Cuanto más joven eres, menos crees en esto. Después de todo, son
solo un montón de declaraciones if y while . Pero a medida que adquieres experiencia, comienzas
a darte cuenta de que la forma en que combinas las declaraciones if y while es fundamental.

5. Consulte el Capítulo 7, “Pruebas de aceptación”.

73
Machine Translated by Google

CAPÍTULO 4 CODIFICACIÓN

importante. No puedes simplemente juntarlos y esperar lo mejor. Más bien, hay que
dividir cuidadosamente el sistema en pequeñas unidades comprensibles que tengan lo
menos posible entre sí, y eso es difícil.

De hecho, programar es tan difícil que está más allá de la capacidad de una sola
persona para hacerlo bien. No importa cuán hábil sea usted, seguramente se
beneficiará de los pensamientos e ideas de otro programador.

AYUDAR A OTROS
Por eso, es responsabilidad de los programadores estar disponibles para ayudarse
unos a otros. Es una violación de la ética profesional recluirse en un cubículo u
oficina y rechazar las consultas de los demás. Tu trabajo no es tan importante como para
que no puedas dedicar parte de tu tiempo a ayudar a otros. De hecho, como profesional,
tiene el honor de ofrecer esa ayuda siempre que sea necesaria.

Esto no significa que no necesites un tiempo a solas. Por supuesto que sí. Pero hay que
ser justo y educado al respecto. Por ejemplo, puedes hacer saber que entre las 10 y
el mediodía no debes ser molestado, pero de 13 a 15 horas tu puerta está abierta.

Debes ser consciente del estado de tus compañeros de equipo. Si ve a alguien que
parece estar en problemas, debe ofrecerle su ayuda. Probablemente se sorprenderá
bastante del profundo efecto que puede tener su ayuda. No es que seas mucho más
inteligente que la otra persona, es sólo que una nueva perspectiva puede ser un
catalizador profundo para resolver problemas.

Cuando ayudes a alguien, siéntate y escribe código juntos. Planee pasar la mayor parte
de una hora o más. Puede que le lleve menos que eso, pero no querrá que parezca que
tiene prisa. Resígnate a la tarea y ponle un esfuerzo sólido. Probablemente terminará
habiendo aprendido más de lo que dio.

SER AYUDADO
Cuando alguien se ofrezca a ayudarte, sé amable. Acepta la ayuda con gratitud
y entrégate a esa ayuda. No protejas tu césped. no empujes

74
Machine Translated by Google

AYUDA

la ayuda de distancia porque estás bajo presión. Dale treinta minutos más o menos. Si en ese momento
la persona realmente no está ayudando mucho, discúlpese cortésmente y finalice la sesión
agradeciéndole. Recuerde, así como está obligado por honor a ofrecer ayuda, está obligado a
aceptarla.

Aprenda a pedir ayuda. Cuando esté estancado, confundido o simplemente no pueda entender un
problema, pida ayuda a alguien. Si está sentado en una sala de equipo, puede simplemente sentarse y
decir: "Necesito ayuda". De lo contrario, utilice Yammer, Twitter, correo electrónico o el teléfono de su
escritorio. Llame para pedir ayuda. Nuevamente, se trata de una cuestión de ética profesional. No
es profesional quedarse estancado cuando se puede acceder fácilmente a la ayuda.

A estas alturas quizás estés esperando que estalle en un coro de Kumbaya mientras los conejitos
peludos saltan sobre los lomos de los unicornios y todos volamos felices sobre arcoíris de
esperanza y cambio. No, no del todo. Verá, los programadores tienden a ser introvertidos arrogantes
y ensimismados. No entramos en este negocio porque nos guste la gente. La mayoría de nosotros
nos dedicamos a la programación porque preferimos centrarnos profundamente en minucias estériles,
hacer malabarismos con muchos conceptos simultáneamente y, en general, demostrarnos a nosotros
mismos que tenemos cerebros del tamaño de un planeta, todo ello sin tener que interactuar con
las complicadas complejidades de otros. gente.

Sí, este es un estereotipo. Sí, es una generalización con muchas excepciones. Pero la realidad es
que los programadores no tienden a ser colaboradores.6 Y, sin embargo, la colaboración es fundamental
para una programación eficaz. Por lo tanto, dado que para muchos de nosotros la colaboración no es
un instinto, necesitamos disciplinas que nos impulsen a colaborar.

MENTORÍA

Tengo un capítulo completo sobre este tema más adelante en el libro. Por ahora permítanme simplemente
decir que la formación de programadores menos experimentados es responsabilidad de aquellos que
tienen más experiencia. Los cursos de formación no son suficientes. Los libros no son suficientes.
Nada puede llevar a un joven desarrollador de software a un alto rendimiento más rápido

6. Esto es mucho más cierto en el caso de los hombres que de las mujeres. Tuve una conversación maravillosa con @desi (Desi McAdam,

fundadora de DevChix) sobre lo que motiva a las mujeres programadoras. Le dije que cuando hacía funcionar un programa, era como

matar a la gran bestia. Me dijo que para ella y otras mujeres con las que había hablado, el acto de escribir código era un acto de fomento

de la creación.

75
Machine Translated by Google

CAPÍTULO 4 CODIFICACIÓN

que su propio impulso y una tutoría eficaz por parte de sus superiores. Por lo tanto, una
vez más, es una cuestión de ética profesional que los programadores senior dediquen tiempo
a tomar a los programadores más jóvenes bajo su protección y asesorarlos. Del mismo
modo, los programadores más jóvenes tienen el deber profesional de buscar ese tipo de
tutoría en sus mayores.

BIBLIOGRAFÍA

[Martin09]: Robert C. Martin, Clean Code, Upper Saddle River, Nueva Jersey: Prentice
Salón, 2009.

[Martin03]: Robert C. Martin, Desarrollo de software ágil: principios, patrones y prácticas,

Upper Saddle River, Nueva Jersey: Prentice Hall, 2003.

76
Machine Translated by Google

DESARROLLO
5 PRUEBA IMPULSADA

Han pasado más de diez años desde que Test Driven Development (TDD) hizo su debut en la industria.
Surgió como parte de la ola de Programación Extrema (XP), pero desde entonces ha sido adoptado por
Scrum y prácticamente por todos los demás métodos ágiles.
Incluso los equipos no ágiles practican TDD.

Cuando, en 1998, oí hablar por primera vez de la “Programación de prueba primero”, me sentí
escéptico. ¿Quién no lo sería? ¿Escribe tus pruebas unitarias primero? ¿Quién haría una tontería como esa?

77
Machine Translated by Google

CAPITULO 5 DESARROLLO IMPULSADO POR PRUEBAS

Pero para entonces ya llevaba treinta años siendo programador profesional y había visto las
cosas ir y venir en la industria. Sabía que no debía descartar nada de plano, especialmente
cuando alguien como Kent Beck lo dice.

Así que en 1999 viajé a Medford, Oregón, para reunirme con Kent y aprender de él la
disciplina. ¡Toda la experiencia fue impactante!

Kent y yo nos sentamos en su oficina y comenzamos a codificar un pequeño problema sencillo

en Java. Sólo quería escribir la tontería. Pero Kent se resistió y me guió paso a paso a través
del proceso. Primero escribió una pequeña parte de una prueba unitaria, apenas suficiente
para calificar como código. Luego escribió el código suficiente para compilar esa prueba.
Luego escribió un poco más de prueba y luego más código.

El tiempo del ciclo estaba completamente fuera de mi experiencia. Estaba acostumbrado

a escribir código durante casi una hora antes de intentar compilarlo o ejecutarlo. Pero Kent
literalmente ejecutaba su código cada treinta segundos aproximadamente. ¡Me quedé estupefacto!

Es más, ¡reconocí el tiempo del ciclo! Era el tipo de tiempo de ciclo que había usado años
antes cuando era niño1 programando juegos en lenguajes interpretados como Basic o Logo. En
esos lenguajes no hay tiempo de compilación, por lo que simplemente agrega una línea de
código y luego ejecuta. Das la vuelta al ciclo muy rápidamente. Y por eso, puedes ser muy
productivo en esos idiomas.

Pero en la programación real ese tipo de tiempo de ciclo era absurdo. En verdad
Para programar, tenías que dedicar mucho tiempo a escribir código y luego mucho más
tiempo a compilarlo. Y luego aún más tiempo para depurarlo. Yo era programador de C++,
¡maldita sea! Y en C++ teníamos tiempos de compilación y vinculación que tomaban
minutos, a veces horas. Los tiempos de ciclo de treinta segundos eran inimaginables.

Sin embargo, ahí estaba Kent, cocinando en este programa Java en ciclos de treinta
segundos y sin ningún indicio de que disminuiría la velocidad en el corto plazo. Entonces,
mientras estaba sentado en la oficina de Kent, me di cuenta de que usando esta simple
disciplina podría codificar en lenguajes reales con el tiempo de ciclo de Logo. ¡Me enganché!

1. Desde mi punto de vista, en el momento en que un niño es cualquier persona menor de 35 años. Durante mis veintes pasé una cantidad significativa

No puedo dedicar mucho tiempo a escribir pequeños juegos tontos en idiomas interpretados. Escribí juegos de guerra espacial, juegos de aventuras,

juegos de carreras de caballos, juegos de serpientes, juegos de apuestas, lo que sea.

78
Machine Translated by Google

LAS TRES LEYES DEL TDD

EL JURADO ESTÁ S I N

Desde aquellos días he aprendido que TDD es mucho más que un simple truco para acortar el
tiempo de mi ciclo. La disciplina tiene todo un repertorio de beneficios que describiré en los siguientes
párrafos.

Pero primero necesito decir esto:

• ¡ El jurado está listo!

• Se acabó la polémica.
• GOTO es perjudicial.

• Y TDD funciona.

Sí, se han escrito muchos blogs y artículos controvertidos sobre TDD a lo largo de los años y todavía
los hay. Al principio fueron intentos serios de crítica y comprensión. Hoy en día, sin embargo, son sólo
peroratas. La conclusión es que TDD funciona y todos deben superarlo.

Sé que esto suena estridente y unilateral, pero dado el historial, no creo que los cirujanos deban
defender el lavado de manos, y no creo que los programadores deban defender TDD.

¿Cómo puedes considerarte un profesional si no sabes que todo tu código funciona? ¿Cómo puedes
saber que todo tu código funciona si no lo pruebas cada vez que realizas un cambio? ¿Cómo puedes
probarlo cada vez que haces un cambio si no tienes pruebas unitarias automatizadas con muy
alta cobertura? ¿Cómo se pueden obtener pruebas unitarias automatizadas con una cobertura muy alta
sin practicar TDD?

Esta última frase requiere cierta elaboración. ¿Qué es exactamente TDD?

LAS TRES LEYES DEL TDD

1. No se le permite escribir ningún código de producción hasta que primero haya escrito una prueba
unitaria fallida.
2. No se le permite escribir más pruebas unitarias de las suficientes para fallar, y

no compilar está fallando.

79
Machine Translated by Google

CAPITULO 5 DESARROLLO IMPULSADO POR PRUEBAS

3. No se le permite escribir más código de producción que sea suficiente para aprobar
la prueba unitaria actualmente fallida.

Estas tres leyes te encierran en un ciclo que dura, quizás, treinta segundos. Empiece por escribir una
pequeña parte de una prueba unitaria. Pero dentro de unos segundos debes mencionar el nombre de
alguna clase o función que aún no has escrito, lo que provoca que la prueba unitaria no se pueda
compilar. Por lo tanto, debe escribir un código de producción que haga que la prueba se compile. Pero no
puedes escribir más que eso, así que empiezas a escribir más código de prueba unitaria.

Vueltas y vueltas en el ciclo que vas. Agregando un poco al código de prueba. Agregando un poco al código de
producción. Los dos flujos de código crecen simultáneamente hasta convertirse en componentes
complementarios. Las pruebas se ajustan al código de producción como un anticuerpo se ajusta a un antígeno.

LA LETANÍA DE BENEFICIOS

Certeza

Si adopta TDD como disciplina profesional, escribirá docenas de pruebas cada día, cientos de pruebas
cada semana y miles de pruebas cada año.
Y tendrá todas esas pruebas a mano y las ejecutará cada vez que realice algún cambio en el código.

2
Soy el autor principal y mantenedor de FitNesse, una herramienta de prueba de
aceptación basada en Java. Al momento de escribir este artículo, FitNesse tiene 64.000 líneas de código, de
las cuales 28.000 están contenidas en poco más de 2.200 pruebas unitarias individuales. Estas pruebas
cubren al menos el 90% del código de producción3 y tardan unos 90 segundos en ejecutarse.

Cada vez que hago un cambio en cualquier parte de FitNesse, simplemente ejecuto las pruebas unitarias. Si se
aprueban, estoy casi seguro de que el cambio que hice no rompió nada.
¿Qué tan seguro es “casi seguro”? ¡Lo suficientemente seguro como para enviar!

El proceso de control de calidad para FitNesse es el comando: liberación de hormigas. Ese comando
construye FitNesse desde cero y luego ejecuta todas las pruebas unitarias y de aceptación.
Si todas esas pruebas pasan, lo envío.

2. [Link]
3. El noventa por ciento es un mínimo. En realidad, el número es mayor que eso. La cantidad exacta es difícil de calcular
porque las herramientas de cobertura no pueden ver el código que se ejecuta en procesos externos o en bloques catch.

80
Machine Translated by Google

LAS TRES LEYES DEL TDD

Tasa de inyección de defectos

Ahora bien, FitNesse no es una aplicación de misión crítica. Si hay un error, nadie muere y
nadie pierde millones de dólares. Así que puedo permitirme el lujo de realizar envíos
basándome únicamente en aprobar las pruebas. Por otro lado, FitNesse tiene miles de usuarios
y, a pesar de la adición de 20.000 nuevas líneas de código el año pasado, mi lista de errores
sólo tiene 17 errores (muchos de los cuales son de naturaleza cosmética). Entonces sé que mi
tasa de inyección de defectos es muy baja.

Este no es un efecto aislado. Ha habido varios informes4 y estudios5 que describen una
reducción significativa de defectos. Desde IBM hasta Microsoft, desde Sabre hasta Symantec,
empresa tras empresa y equipo tras equipo han experimentado reducciones de defectos de 2, 5 e
incluso 10 veces. Son números que ningún profesional debería ignorar.

Coraje

¿Por qué no arreglas el código incorrecto cuando lo ves? Su primera reacción al ver una función
desordenada es "Esto es un desastre, hay que limpiarlo". Tu segunda reacción es "¡No lo voy a
tocar!" ¿Por qué? Porque sabes que si lo tocas corres el riesgo de romperlo; y si lo rompes, se
vuelve tuyo.

Pero, ¿y si pudieras estar seguro de que tu limpieza no rompió nada? ¿Qué pasaría si tuvieras
el tipo de certeza que acabo de mencionar? ¿Qué pasaría si pudiera hacer clic en un botón y
saber en 90 segundos que sus cambios no han alterado nada y solo han hecho algo bueno?

Este es uno de los beneficios más poderosos de TDD. Cuando tienes un conjunto de pruebas
en las que confías, pierdes todo miedo a realizar cambios. Cuando vea un código incorrecto,
simplemente límpielo en el acto. El código se convierte en arcilla que puedes esculpir con
seguridad en estructuras simples y agradables.

Cuando los programadores pierden el miedo a limpiar, ¡limpian! Y el código limpio es más
fácil de entender, de cambiar y de ampliar. Los defectos se convierten

4. [Link]
5. [Maximilien], [George2003], [Janzen2005], [Nagappan2008]

81
Machine Translated by Google

CAPITULO 5 DESARROLLO IMPULSADO POR PRUEBAS

incluso menos probable porque el código se vuelve más simple. Y la base del código mejora
constantemente en lugar de la descomposición normal a la que nuestra industria se ha acostumbrado.

¿Qué programador profesional permitiría que continuara la descomposición?

Documentación

¿Ha utilizado alguna vez un marco de terceros? A menudo, el tercero le enviará un

manual con un formato agradable y escrito por redactores de tecnología. El manual
típico emplea 27 fotografías brillantes en color de ocho por diez con círculos y flechas y
un párrafo en la parte posterior de cada una que explica cómo configurar,
implementar, manipular y utilizar ese marco. En la parte posterior, en el apéndice,
suele haber una pequeña y fea sección que contiene todos los ejemplos de código.

¿Dónde está el primer lugar al que vas en ese manual? Si eres programador, vas a los
ejemplos de código. Vas al código porque sabes que el código te dirá la verdad. Las
27 fotografías brillantes en color de ocho por diez con círculos y flechas y un párrafo
en la parte posterior pueden ser bonitas, pero si quieres saber cómo usar el código,
necesitas leer el código.

Cada una de las pruebas unitarias que escribe cuando sigue las tres leyes es un
ejemplo, escrito en código, que describe cómo se debe usar el sistema. Si sigue las
tres leyes, habrá una prueba unitaria que describe cómo crear cada objeto en el sistema,
todas las formas en que se pueden crear esos objetos. Habrá una prueba unitaria que
describe cómo llamar a cada función en el sistema de todas las formas en que esas
funciones puedan llamarse de manera significativa. Para cualquier cosa que necesites
saber hacer, habrá una prueba unitaria que lo describe detalladamente.

Las pruebas unitarias son documentos. Describen el diseño de nivel más bajo del
sistema. Son inequívocos, precisos, escritos en un lenguaje que el público
entiende y son tan formales que ejecutan. Son el mejor tipo de documentación de
bajo nivel que puede existir. ¿Qué profesional no facilitaría dicha documentación?

Diseño

Cuando sigues las tres leyes y escribes tus pruebas primero, te enfrentas a un dilema.
A menudo sabes exactamente qué código quieres escribir, pero los tres

82
Machine Translated by Google

LO QUE NO ES TDD

¡Las leyes te dicen que escribas una prueba unitaria que falla porque ese código no existe!
Esto significa que debes probar el código que estás a punto de escribir.

El problema con probar el código es que hay que aislar ese código. A menudo es difícil
probar una función si esa función llama a otras funciones. Para escribir esa prueba tienes
que encontrar alguna manera de desacoplar la función de todas las demás. En otras
palabras, la necesidad de realizar la prueba primero te obliga a pensar en cosas buenas.
diseño.

Si no escribe sus pruebas primero, no habrá fuerza que le impida acoplar las funciones en una
masa no comprobable. Si escribe sus pruebas más tarde, es posible que pueda probar las
entradas y salidas de la masa total, pero probablemente será bastante difícil probar las
funciones individuales.

Por lo tanto, seguir las tres leyes y escribir las pruebas primero crea una fuerza que lo impulsa
a lograr un mejor diseño desacoplado. ¿Qué profesional no emplearía herramientas que
lo impulsaran hacia mejores diseños?

"Pero puedo escribir mis pruebas más tarde", dices. No, no puedes. No precisamente. Oh,
puedes escribir algunas pruebas más tarde. Incluso puedes acercarte a una cobertura alta más
adelante si tienes cuidado al medirla. Pero las pruebas que usted escribe después del hecho son
defensa. Las pruebas que escribes primero son ofensivas. Las pruebas posteriores las escribe
alguien que ya conoce el código y sabe cómo se resolvió el problema. Simplemente no hay
forma de que esas pruebas puedan ser tan incisivas como las pruebas escritas primero.

LA OPCIÓN PROFESIONAL

El resultado de todo esto es que TDD es la opción profesional. Es una disciplina que mejora
la certeza, el coraje, la reducción de defectos, la documentación y el diseño.
Con todo esto a su favor, podría considerarse poco profesional no utilizarlo.

LO QUE NO ES TDD
A pesar de todos sus puntos positivos, TDD no es una religión ni una fórmula mágica. Seguir las
tres leyes no garantiza ninguno de estos beneficios. Aún puedes escribir código incorrecto
incluso si escribes tus pruebas primero. De hecho, puedes escribir malas pruebas.

83
Machine Translated by Google

CAPITULO 5 DESARROLLO IMPULSADO POR PRUEBAS

Del mismo modo, hay ocasiones en las que seguir las tres leyes resulta
sencillamente poco práctico o inapropiado. Estas situaciones son raras, pero
existen. Ningún desarrollador profesional debería seguir una disciplina cuando esa
disciplina hace más daño que bien.

BIBLIOGRAFÍA

[Maximilien]: E. Michael Maximilien, Laurie Williams, “Evaluación del desarrollo basado

en pruebas en IBM”, [Link]
MAXIMILIEN_WILLIAMS.PDF

[George2003]: B. George y L. Williams, “Una investigación inicial de pruebas­

Desarrollo impulsado en la industria”, [Link]
Artículos/[Link]

[Janzen2005]: D. Janzen y H. Saiedian, “Conceptos de desarrollo basado en

pruebas, taxonomía y dirección futura”, IEEE Computer, volumen 38,
número 9, págs.

[Nagappan2008]: Nachiappan Nagappan, E. Michael Maximilien, Thirumalesh Bhat y

Laurie Williams, “Realizando la mejora de la calidad a través del desarrollo
impulsado por pruebas: resultados y experiencias de cuatro equipos industriales”.
Springer Science + Business Media, LLC 2008: [Link]
com/en­us/projects/esm/nagappan_tdd.pdf

84
Machine Translated by Google

6PRACTICAR

Todos los profesionales practican su arte realizando ejercicios de perfeccionamiento de habilidades.

Los músicos ensayan escalas. Los jugadores de fútbol corren sobre neumáticos. Los médicos practican
suturas y técnicas quirúrgicas. Los abogados practican argumentos. Los soldados ensayan misiones.
Cuando el desempeño importa, los profesionales practican. Este capítulo trata sobre las formas en que
los programadores pueden practicar su arte.

85
Machine Translated by Google

CAPÍTULO 6 PRACTICAR

ALGUNAS PRACTICAS DE BAC KG RO UNDON

La práctica no es un concepto nuevo en el desarrollo de software, pero no lo

reconocimos como práctica hasta poco después del cambio de milenio. Quizás la primera
instancia formal de un programa de práctica se imprimió en la página 6 de [K&R­C].

principal()
{
printf("hola mundo\n");
}

¿Quién de nosotros no ha escrito ese programa de una forma u otra? Lo usamos como una forma
de probar un nuevo entorno o un nuevo lenguaje. Escribir y ejecutar ese programa es prueba de
que podemos escribir y ejecutar cualquier programa.

Cuando era mucho más joven, uno de los primeros programas que escribía en una
computadora nueva fue SQINT, los cuadrados de números enteros. Lo escribí en
ensamblador, BASIC, FORTRAN, COBOL y muchísimos otros lenguajes. Nuevamente, era una
forma de demostrar que podía hacer que la computadora hiciera lo que yo quería que hiciera.

A principios de los años 80, las computadoras personales comenzaron a aparecer en los
grandes almacenes. Cada vez que pasaba por uno, como un VIC­20 o un Commodore­64, o un
TRS­80, escribía un pequeño programa que imprimía una secuencia infinita de caracteres '\' y '/'
en la pantalla. Los patrones que produjo este programa eran agradables a la vista y parecían
mucho más complejos que el pequeño programa que los generó.

Aunque estos pequeños programas eran ciertamente programas de práctica, los programadores
en general no practicaban. Francamente, esa idea nunca se nos ocurrió.
Estábamos demasiado ocupados escribiendo código para pensar en practicar nuestras
habilidades. Y además, ¿cuál hubiera sido el punto? Durante esos años la programación no
requería reacciones rápidas ni dedos ágiles. No utilizamos editores de pantalla hasta finales
de los años 70. Pasamos gran parte de nuestro tiempo esperando compilaciones o depurando
largos y horribles tramos de código. Todavía no habíamos inventado los ciclos cortos de TDD,
por lo que no necesitábamos el ajuste que la práctica podía aportar.

86
Machine Translated by Google

ALGUNOS ANTECEDENTES SOBRE LA PRÁCTICA

VEINTIDÓS CERO

Pero las cosas han cambiado desde los primeros días de la programación. Algunas cosas han cambiado
mucho . Otras cosas no han cambiado mucho en absoluto.

Una de las primeras máquinas para las que escribí programas fue una PDP­8/I. Esta máquina tenía un
tiempo de ciclo de 1,5 microsegundos. Tenía 4.096 palabras de 12 bits en la memoria central.
Tenía el tamaño de un frigorífico y consumía una cantidad importante de energía eléctrica. Tenía una
unidad de disco que podía almacenar 32 KB de palabras de 12 bits y le hablábamos con un teletipo
de 10 caracteres por segundo. Pensamos que este era un poderoso
máquina, y la usamos para hacer milagros.

Acabo de comprar una nueva computadora portátil Macbook Pro. Tiene un procesador de doble
núcleo a 2,8 GHz, 8 GB de RAM, un SSD de 512 GB y una pantalla LED de 17 pulgadas 1920 ´ 1200.
Lo llevo en mi mochila. Se sienta en mi regazo. Consume menos de 85 vatios.

Mi computadora portátil es ocho mil veces más rápida, tiene dos millones de veces más memoria,
tiene dieciséis millones de veces más almacenamiento fuera de línea, requiere el 1% de la energía,
ocupa el 1% del espacio y cuesta una vigésima quinta parte del precio del PDP. ­8/I. Hagamos los cálculos:

8.000 ´ 2.000.000 ´ 16.000.000 ´ 100 ´ 100 ´ 25 = 6,4 ´ 1022

Este número es grande. ¡Estamos hablando de 22 órdenes de magnitud! Ésa es la cantidad de angstroms
que hay entre aquí y Alfa Centauri. Esa es la cantidad de electrones que hay en un dólar de plata. Esa es la
masa de la Tierra en unidades de Michael Moore. Este es un número muy, muy grande. Y está en mi

regazo, ¡y probablemente también en el tuyo!

¿Y qué hago con este aumento de potencia de 22 factores de diez? Estoy haciendo más o menos lo
que estaba haciendo con ese PDP­8/I. Estoy escribiendo sentencias if , bucles while y
asignaciones.

Oh, tengo mejores herramientas para escribir esas declaraciones. Y tengo mejores idiomas para
escribir esas declaraciones. Pero la naturaleza de las declaraciones no ha cambiado en todo ese
tiempo. El código de 2010 sería reconocible para un programador de la década de 1960. La arcilla
que manipulamos no ha cambiado mucho en esas cuatro décadas.

87
Machine Translated by Google

CAPÍTULO 6 PRACTICAR

TIEMPO DE RESPUESTA

Pero la forma en que trabajamos ha cambiado dramáticamente. En los años 60 podía esperar uno o dos
días para ver los resultados de una compilación. A finales de los años 70, un programa de 50.000 líneas
podía tardar 45 minutos en compilarse. Incluso en los años 90, los largos tiempos de construcción
eran la norma.

Los programadores de hoy no esperan por las compilaciones.1 Los programadores de hoy tienen un
poder tan inmenso bajo sus dedos que pueden girar alrededor del ciclo de refactorización rojo­verde en
segundos.

Por ejemplo, trabajo en un proyecto Java de 64.000 líneas llamado FitNesse. Una compilación completa,
incluidas todas las pruebas unitarias y de integración, se ejecuta en menos de 4 minutos. Si esas pruebas
pasan, estoy listo para enviar el producto. Por lo tanto, todo el proceso de control de calidad, desde el
código fuente hasta la implementación, requiere menos de 4 minutos. Las compilaciones casi no toman
ningún tiempo mensurable. Las pruebas parciales requieren segundos. ¡Así que puedo literalmente dar
vueltas alrededor del ciclo de compilación/prueba diez veces por minuto!

No siempre es prudente ir tan rápido. A menudo es mejor frenar y simplemente pensar. 2

Pero hay otras ocasiones en las que girar ese bucle lo más rápido posible es muy productivo.

Hacer cualquier cosa rápidamente requiere práctica. Girar rápidamente el ciclo de código/prueba requiere
que usted tome decisiones muy rápidas. Tomar decisiones rápidamente significa ser capaz de reconocer
una gran cantidad de situaciones y problemas y simplemente saber qué hacer para abordarlos.

Consideremos dos artistas marciales en combate. Cada uno debe reconocer lo que el otro está intentando
y responder adecuadamente en milisegundos. En una situación de combate no puedes darte el lujo de
congelar el tiempo, estudiar las posiciones y deliberar sobre la respuesta adecuada. En una situación de
combate simplemente hay que reaccionar. De hecho, es su cuerpo el que reacciona mientras su mente trabaja
en una estrategia de nivel superior.

1. El hecho de que algunos programadores esperen las compilaciones es trágico e indica descuido. En el mundo de hoy
Los tiempos de construcción deben medirse en segundos, no en minutos y, ciertamente, no en horas.
2. Esta es una técnica que Rich Hickey llama HDD o desarrollo impulsado por hamacas.

88
Machine Translated by Google

EL DOJO DE CODIFICACIÓN

Cuando estás dando vueltas alrededor del ciclo de código/prueba varias veces por minuto, es
tu cuerpo el que sabe qué teclas presionar. Una parte primordial de tu mente reconoce la
situación y reacciona en milisegundos con la solución adecuada mientras tu mente está libre
para concentrarse en el problema de nivel superior.

Tanto en el caso de las artes marciales como en el de la programación, la velocidad

depende de la práctica. Y en ambos casos la práctica es similar. Elegimos un repertorio de
pares problema/solución y los ejecutamos una y otra vez hasta que los conocemos bien.

Pensemos en un guitarrista como Carlos Santana. La música en su cabeza simplemente

sale de sus dedos. No se centra en la posición de los dedos ni en la técnica de punteo. Su
mente es libre de planificar melodías y armonías de nivel superior mientras su cuerpo
traduce esos planes en movimientos de los dedos de nivel inferior.

Pero para lograr ese tipo de facilidad de juego se requiere práctica. Los músicos practican
escalas, estudios y riffs una y otra vez hasta que los conocen bien.

THE CODING D OJO

Desde 2001 he estado realizando una demostración de TDD a la que llamo The Bowling 3. Es
Juego. un pequeño y encantador ejercicio que dura unos treinta minutos. experimenta

conflicto en el diseño, llega a un clímax y termina con una sorpresa. Escribí un capítulo
completo sobre este ejemplo en [PPP2003].

A lo largo de los años realicé esta demostración cientos, tal vez miles, de veces. ¡Me volví
muy bueno en eso! Podría hacerlo mientras duermo. Minimizé las pulsaciones de teclas, ajusté
los nombres de las variables y modifiqué la estructura del algoritmo hasta que quedó perfecto.
Aunque no lo sabía en ese momento, este fue mi primer kata.

En 2005 asistí a la Conferencia XP2005 en Sheffield, Inglaterra. Asistí a una sesión llamada
Coding Dojo dirigida por Laurent Bossavit y Emmanuel Gaillot. Hicieron que todos
abrieran sus computadoras portátiles y codificaran junto con ellos mientras

3. Este se ha convertido en un kata muy popular y una búsqueda en Google encontrará muchos ejemplos del mismo. el original es
aquí: [Link]

89
Machine Translated by Google

CAPÍTULO 6 PRACTICAR

Usó TDD para escribir El juego de la vida de Conway. Lo llamaron “Kata” y le atribuyeron la
idea original al “Pragmático” Dave Thomas4.5

Desde entonces, muchos programadores han adoptado una metáfora de las artes marciales
para sus sesiones de práctica. El nombre Coding Dojo6 parece haberse quedado. A veces,
un grupo de programadores se reúne y practica juntos como lo hacen los artistas marciales.
En otras ocasiones, los programadores practicarán solos, como lo hacen los artistas marciales.

Hace aproximadamente un año estaba enseñando a un grupo de desarrolladores en Omaha.

En el almuerzo me invitaron a unirme a su Coding Dojo. Vi como veinte desarrolladores abrían
sus computadoras portátiles y, pulsación de tecla, seguían al líder que estaba haciendo The
Bowling Game Kata.

Hay varios tipos de actividades que se llevan a cabo en un dojo. Aquí hay algunos:

KATA
En artes marciales, un kata es un conjunto preciso de movimientos coreografiados que simulan
un lado de un combate. La meta a la que se llega asintóticamente es la perfección.
El artista se esfuerza por enseñar a su cuerpo a realizar cada movimiento a la perfección y a
ensamblar esos movimientos en una representación fluida. Los katas bien ejecutados son
hermosos de ver.

Por muy hermosos que sean, el propósito de aprender un kata no es realizarlo en el escenario.
El objetivo es entrenar tu mente y tu cuerpo para reaccionar en una situación de combate
particular. El objetivo es hacer que los movimientos perfeccionados sean automáticos e
instintivos para que estén ahí cuando los necesites.

Un kata de programación es un conjunto preciso de pulsaciones de teclas y movimientos del

mouse coreografiados que simula la resolución de algún problema de programación. En
realidad, no estás resolviendo el problema porque ya conoces la solución.
Más bien, estás practicando los movimientos y decisiones involucrados en la resolución del
problema.

4. Usamos el prefijo "Pragmático" para desambiguarlo del "Gran" Dave Thomas de OTI.
5. [Link]
6. [Link]

90
Machine Translated by Google

EL DOJO DE CODIFICACIÓN

La asíntota de la perfección vuelve a ser el objetivo. Repites el ejercicio una y otra vez para
entrenar tu cerebro y tus dedos sobre cómo moverse y reaccionar. A medida que practique,
podrá descubrir sutiles mejoras y eficiencias en sus movimientos o en la solución misma.

Practicar un conjunto de katas es una buena manera de aprender teclas de acceso rápido y
modismos de navegación. También es una buena forma de aprender disciplinas como TDD y CI.
Pero lo más importante es que es una buena manera de introducir pares comunes de problemas/
soluciones en su subconsciente, para que simplemente sepa cómo resolverlos cuando los
enfrente en la programación real.

Como cualquier artista marcial, un programador debe conocer varios kata diferentes y
practicarlos regularmente para que no se desvanezcan de la memoria. Muchos kata están
registrados en [Link] Otros se pueden encontrar en http://
[Link]. Algunos de mis favoritos son:

• El juego de bolos: [Link]

JuegoKata

• Factores primos: [Link]

kata

• Ajuste de palabras: [Link]

[Link]

Para un verdadero desafío, intenta aprender un kata tan bien que puedas ponerle música.
Hacer esto bien es difícil.7

WASA
Cuando estudiaba jujitsu, gran parte de nuestro tiempo en el dojo lo pasábamos en parejas
practicando nuestro wasa. Wasa es muy parecido a un kata de dos hombres. Las rutinas se
memorizan y reproducen con precisión. Un socio desempeña el papel de agresor y el otro es el de
defensor. Los movimientos se repiten una y otra vez mientras los practicantes intercambian roles.

7. [Link]

91
Machine Translated by Google

CAPÍTULO 6 PRACTICAR

Los programadores pueden practicar de manera similar usando un juego conocido como
pong. ping­ 8 Los dos compañeros eligen un kata o un problema simple. Un programador
escribe una prueba unitaria y luego el otro debe hacerla pasar. Luego invierten los roles.

Si los socios eligen un kata estándar, entonces se conoce el resultado y los

programadores practican y critican las técnicas de teclado y mouse de cada uno, y
qué tan bien han memorizado el kata. Por otro lado, si los compañeros eligen un nuevo
problema para resolver, entonces el juego puede volverse un poco más interesante. El
programador que escribe una prueba tiene un control excesivo sobre cómo se resolverá el
problema. También tiene un poder significativo para establecer restricciones. Por ejemplo,
si los programadores optan por implementar un algoritmo de clasificación, el redactor
de la prueba puede imponer fácilmente limitaciones de velocidad y espacio de memoria que
desafiarán a su compañero. Esto puede hacer que el juego sea bastante competitivo. . . y
divertido.

RANGORI
Randori es un combate de forma libre. En nuestro dojo de jujitsu, establecíamos una
variedad de escenarios de combate y luego los representamos. A veces a una persona se le
decía que se defendiera, mientras que el resto de nosotros lo atacaba en secuencia. A
veces enfrentábamos a dos o más atacantes contra un solo defensor (normalmente el sensei,
que casi siempre ganaba). A veces hacíamos dos contra dos, y así sucesivamente.

El combate simulado no se adapta bien a la programación; sin embargo, hay un juego que se
juega en muchos dojos de codificación llamado randori. Es muy parecido al wasa de dos
hombres en el que los socios resuelven un problema. Sin embargo, se juega con mucha
gente y las reglas tienen un giro. Con la pantalla proyectada en la pared, una persona
escribe un test y luego se sienta. La siguiente persona hace pasar el examen y luego escribe
el siguiente examen. Esto se puede hacer en secuencia alrededor de la mesa, o las personas
pueden simplemente formar fila cuando se sientan conmovidas. En cualquier caso, estos
ejercicios pueden ser muy divertidos .

8. [Link]

92
Machine Translated by Google

AMPLIAR TU EXPERIENCIA

Es sorprendente cuánto se puede aprender de estas sesiones. Puede obtener una inmensa visión de la
forma en que otras personas resuelven problemas. Estos conocimientos sólo pueden servir para ampliar su
propio enfoque y mejorar sus habilidades.

AMPLIAR SU EXPERIENCIA
Los programadores profesionales a menudo adolecen de una falta de diversidad en los tipos de
problemas que resuelven. Los empleadores a menudo imponen un único idioma, plataforma y dominio en el
que deben trabajar sus programadores. Sin una influencia ampliadora, esto puede conducir a una reducción
muy poco saludable de su currículum y su forma de pensar. No es raro que estos programadores no estén
preparados para los cambios que periódicamente azotan la industria.

FUENTE ABIERTA

Una forma de mantenerse a la vanguardia es hacer lo que hacen los abogados y médicos: realizar algún trabajo
gratuito contribuyendo a un proyecto de código abierto. Hay muchos de ellos por ahí y probablemente no haya
mejor manera de aumentar su repertorio de habilidades que trabajar en algo que a otra persona le importe.

Entonces, si eres programador de Java, contribuye a un proyecto Rails. Si escribe mucho C++ para su
empleador, busque un proyecto de Python y contribuya a él.

ÉTICA PRÁCTICA

Los programadores profesionales practican en su propio tiempo. No es trabajo de su empleador ayudarlo a

mantener sus habilidades actualizadas. No es trabajo de su empleador ayudarlo a mantener su currículum
actualizado. Los pacientes no pagan a los médicos para que practiquen las suturas.
Los aficionados al fútbol (normalmente) no pagan para ver a los jugadores correr sobre neumáticos. Los
asistentes a los conciertos no pagan para escuchar a los músicos tocar escalas. Y los empleadores de
programadores no tienen que pagarle por su tiempo de práctica.

Dado que su tiempo de práctica es su propio tiempo, no es necesario que utilice los mismos idiomas o
plataformas que utiliza con su empleador. Elija el idioma que desee y mantenga afiladas sus habilidades
políglotas. Si trabaja en una tienda .NET, practique un poco de Java o Ruby durante el almuerzo o en casa.

93
Machine Translated by Google

CAPÍTULO 6 PRACTICAR

CONCLUSIÓN

De una forma u otra, todos los profesionales ejercen. Lo hacen porque les
importa hacer el mejor trabajo posible. Es más, practican en su propio tiempo
porque se dan cuenta de que es su responsabilidad (y no la de su empleador)
mantener sus habilidades en forma. Practicar es lo que haces cuando no lo estás
recibiendo un pago. Lo haces para que te paguen , y bien.

BIBLIOGRAFÍA

[K&R­C]: Brian W. Kernighan y Dennis M. Ritchie, El lenguaje de programación

C, Upper Saddle River, Nueva Jersey: Prentice Hall, 1975.

[PPP2003]: Robert C. Martin, Desarrollo de software ágil: principios, patrones y

prácticas, Upper Saddle River, Nueva Jersey: Prentice Hall, 2003.

94
Machine Translated by Google

7PRUEBAS DE ACEPTACIÓN

El papel del desarrollador profesional es tanto de comunicación como de desarrollo.

Recuerde que la entrada y salida de basura también se aplica a los programadores, por
lo que los programadores profesionales tienen cuidado de asegurarse de que su
comunicación con otros miembros del equipo y con la empresa sea precisa y saludable.

REQUISITOS DE COMUNICACIÓN
Uno de los problemas de comunicación más comunes entre los programadores y las
empresas son los requisitos. Los empresarios declaran lo que creen que necesitan y
luego los programadores construyen lo que creen que describe el negocio.
Al menos así es como se supone que funciona. En realidad, la comunicación de
requisitos es extremadamente difícil y el proceso está plagado de errores.

95
Machine Translated by Google

CAPÍTULO 7 PRUEBAS DE ACEPTACIÓN

En 1979, mientras trabajaba en Teradyne, recibí la visita de Tom, el gerente de instalación

y servicio de campo. Me pidió que le mostrara cómo utilizar el editor de texto ED­402 para
crear un sistema sencillo de incidencias.

ED­402 era un editor propietario escrito para la computadora M365, que era el clon PDP­8
de Teradyne. Como editor de texto era muy poderoso. Tenía un lenguaje de secuencias de
comandos incorporado que usábamos para todo tipo de aplicaciones de texto simples.

Tom no era programador. Pero la aplicación que tenía en mente era simple, así que pensó
que yo podría enseñarle rápidamente y luego él mismo podría escribir la aplicación. En mi
ingenuidad pensé lo mismo. Después de todo, el lenguaje de programación era poco más que
un lenguaje macro para los comandos de edición, con decisiones y construcciones de
bucles muy rudimentarias.

Así que nos sentamos juntos y le pregunté qué quería que hiciera su aplicación.
Comenzó con la pantalla de entrada inicial. Le mostré cómo crear un archivo de texto que
contuviera las declaraciones del script y cómo escribir la representación simbólica
de los comandos de edición en ese script. Pero cuando lo miré a los ojos, no había nada
que me devolviera la mirada. Mi explicación simplemente no tenía ningún sentido para él.

Esta fue la primera vez que me encontré con esto. Para mí era muy sencillo representar
simbólicamente los comandos del editor. Por ejemplo, para representar un comando control­B
(el comando que coloca el cursor al principio de la línea actual), simplemente escribe ^B en
el archivo de script. Pero esto no tenía sentido para Tom. No podía dar el salto de editar un
archivo a editar un archivo que editaba un archivo.

Tom no era tonto. Creo que simplemente se dio cuenta de que esto iba a ser mucho más
complicado de lo que pensaba inicialmente, y no quería invertir el tiempo y la energía mental
necesarios para aprender algo tan horriblemente complicado como usar un editor para
comandar a un editor.

Poco a poco me encontré implementando esta aplicación mientras él estaba sentado y

observaba. En los primeros veinte minutos quedó claro que su énfasis había cambiado de
aprender a hacerlo él mismo a asegurarse de que lo que yo hacía era lo que él quería.

96
Machine Translated by Google

REQUISITOS DE COMUNICACIÓN

Nos llevó un día entero. Él describiría una característica y yo la implementaría mientras él

observaba. El tiempo del ciclo fue de cinco minutos o menos, por lo que no había motivo
para que se levantara y hiciera nada más. Me pedía que hiciera X y en cinco minutos ya
tenía X funcionando.

A menudo dibujaba lo que quería en un trozo de papel. Algunas de las cosas que quería
eran difíciles de hacer en ED­402, así que propondría algo más. Eventualmente
acordaríamos algo que funcionaría y luego yo lo haría funcionar.

Pero luego lo intentábamos y él cambiaba de opinión. Decía algo como: “Sí, eso simplemente
no tiene la fluidez que estoy buscando. Intentémoslo de otra manera”.

Hora tras hora jugueteamos, pinchamos y le dimos forma a esa aplicación.

Probamos una cosa, luego otra y luego otra. Me quedó muy claro que él era el escultor y yo
era la herramienta que él manejaba.

Al final, consiguió la aplicación que buscaba, pero no tenía idea de cómo crear la
siguiente. Yo, por otro lado, aprendí una poderosa lección sobre cómo los clientes
realmente descubren lo que necesitan. Aprendí que su visión de las características no suele
sobrevivir al contacto real con el
computadora.

PRECISIÓN PREMATURA

Tanto las empresas como los programadores se ven tentados a caer en la trampa de la
precisión prematura. Los empresarios quieren saber exactamente qué obtendrán antes de
autorizar un proyecto. Los desarrolladores quieren saber exactamente qué se supone que
deben entregar antes de estimar el proyecto. Ambas partes quieren una precisión que
simplemente no se puede lograr y, a menudo, están dispuestas a gastar una fortuna tratando de lograrla.

El principio de incertidumbre

El problema es que las cosas parecen diferentes en el papel que en un sistema en

funcionamiento. Cuando la empresa realmente ve lo que especificaron ejecutándose en un
sistema, se dan cuenta de que no era lo que querían en absoluto. Una vez que ven que el
requisito realmente se está ejecutando, tienen una mejor idea de lo que realmente
quieren y, por lo general, no es lo que ven.

97
Machine Translated by Google

CAPÍTULO 7 PRUEBAS DE ACEPTACIÓN

Hay en juego una especie de efecto del observador, o principio de incertidumbre. Cuando le
demuestra una función a la empresa, les brinda más información de la que tenían antes, y esa nueva
información afecta la forma en que ven todo el sistema.

Al final, cuanto más precisos sean sus requisitos, menos relevantes se volverán a medida que se
implemente el sistema.

Ansiedad de estimación

Los desarrolladores también pueden quedar atrapados en la trampa de la precisión. Saben que
deben estimar el sistema y a menudo piensan que esto requiere precisión. No es así.

En primer lugar, incluso con información perfecta, sus estimaciones tendrán una variación enorme.
En segundo lugar, el principio de incertidumbre convierte la precisión temprana en hachís.
Los requisitos cambiarán haciendo que esa precisión sea discutible.

Los desarrolladores profesionales comprenden que las estimaciones pueden y deben realizarse
basándose en requisitos de baja precisión y reconocen que esas estimaciones son estimaciones.
Para reforzar esto, los desarrolladores profesionales siempre incluyen barras de error con sus
estimaciones para que la empresa comprenda la incertidumbre. (Consulte el Capítulo 10,
“Estimación”).

AMBIGÜEDAD ÚLTIMA

La solución a la precisión prematura es posponer la precisión el mayor tiempo posible.

Los desarrolladores profesionales no desarrollan un requisito hasta que están a punto de
desarrollarlo. Sin embargo, eso puede conducir a otro mal: la ambigüedad tardía.

A menudo las partes interesadas no están de acuerdo. Cuando lo hagan, puede que les resulte más fácil redactar palabras.

sortear el desacuerdo en lugar de resolverlo. Encontrarán alguna manera de formular el requisito con
el que todos estén de acuerdo, sin llegar a resolver la disputa. Una vez escuché a Tom
DeMarco decir: “Una ambigüedad en un documento de requisitos representa una discusión
entre las partes interesadas”.1

Por supuesto, no hace falta una discusión o un desacuerdo para crear ambigüedad.
A veces las partes interesadas simplemente suponen que sus lectores saben lo que quieren decir.

1. XP Immersion 3, mayo de 2000. [Link]

98
Machine Translated by Google

REQUISITOS DE COMUNICACIÓN

Puede que les resulte perfectamente claro en su contexto, pero signifique algo
completamente diferente para el programador que lo lea. Este tipo de ambigüedad
contextual también puede ocurrir cuando los clientes y los programadores hablan cara a cara.

Sam (parte interesada): "Está bien, ahora es necesario realizar una copia de seguridad de estos archivos de registro".

Paula: "Está bien, ¿con qué frecuencia?"

Sam: "Diariamente".

Paula: “Correcto. ¿Y dónde quieres que se guarde?

Sam: "¿Qué quieres decir?"

Paula: "¿Quieres que lo guarde en un subdirectorio en particular?"

Sam: "Sí, eso sería bueno".

Paula: “¿Cómo lo llamaremos?”

Sam: "¿Qué tal 'copia de seguridad'?"

Paula: “Claro, eso estaría bien. Entonces escribiremos el archivo de registro en la copia de seguridad.

directorio todos los días. ¿A qué hora?"

Sam: "Todos los días".

Paula: “No, quiero decir ¿a qué hora del día quieres que se escriba?”

Sam: "En cualquier momento".

Paula: “¿Mediodía?”

Sam: “No, no durante el horario comercial. Medianoche sería mejor”.

Paula: "Está bien, medianoche entonces".

Sam: "¡Genial, gracias!"

Paula: “Siempre es un placer”.

Más tarde, Paula le cuenta a su compañero de equipo Peter sobre la tarea.

Paula: “OK, necesitamos copiar el archivo de registro en un subdirectorio llamado

copia de seguridad todas las noches a medianoche”.

Peter: "Está bien, ¿qué nombre de archivo deberíamos usar?"

Paula: "[Link] debería hacerlo".

Pedro: "Lo tienes".

99
Machine Translated by Google

CAPÍTULO 7 PRUEBAS DE ACEPTACIÓN

En otra oficina, Sam está hablando por teléfono con su cliente.

Sam: "Sí, sí, los archivos de registro se guardarán".

Carl: “Está bien, es vital que nunca perdamos ningún registro. Necesitamos regresar
"Revise todos esos archivos de registro, incluso meses o años después, cada vez que
haya una interrupción, un evento o una disputa".

Sam: “No te preocupes, acabo de hablar con Paula. Ella guardará los registros en un directorio
llamado backup todas las noches a medianoche”.

Carl: "Está bien, eso suena bien".

Supongo que has detectado la ambigüedad. El cliente espera que se guarden todos los archivos de registro
y Paula simplemente pensó que quería guardar el archivo de registro de anoche. Cuando el cliente busca
copias de seguridad de archivos de registro de meses, simplemente encontrará las de anoche.

En este caso, tanto Paula como Sam dejaron caer la pelota. Es responsabilidad de los desarrolladores
profesionales (y de las partes interesadas) asegurarse de que se elimine toda ambigüedad de los
requisitos.

Esto es difícil y sólo hay una forma de hacerlo.

PRUEBAS DE ACEPTACIÓN

El término prueba de aceptación está sobrecargado y usado en exceso. Algunas personas suponen que
estas son las pruebas que los usuarios ejecutan antes de aceptar una versión. Otras personas piensan
que se trata de pruebas de control de calidad. En este capítulo definiremos las pruebas de aceptación
como pruebas escritas mediante la colaboración de las partes interesadas y los programadores para definir
cuándo se cumple un requisito.

LA DEFINICIÓN DE “D ONE”
"
Una de las ambigüedades más comunes a las que nos enfrentamos como profesionales del software es
la ambigüedad de "hecho". Cuando un desarrollador dice que ha terminado una tarea, ¿qué significa? ¿El
desarrollador ha terminado en el sentido de que está listo para implementar la función con total
confianza? ¿O quiere decir que está listo para el control de calidad? O tal vez ya terminó de escribirlo y
lo ejecutó una vez, pero aún no lo ha probado.

100
Machine Translated by Google

PRUEBAS DE ACEPTACIÓN

He trabajado con equipos que tenían una definición diferente de las palabras "hecho" y
"completo". Un equipo en particular utilizó los términos "hecho" y "hecho­hecho".

Los desarrolladores profesionales tienen una única definición de hecho: hecho significa hecho.

Listo significa que todo el código está escrito, todas las pruebas pasan, el control de calidad y las partes interesadas

lo han aceptado. Hecho.

Pero, ¿cómo se puede alcanzar este nivel de finalización y aun así avanzar rápidamente de una iteración a otra?

Usted crea un conjunto de pruebas automatizadas que, cuando pasan, cumplen con todos los criterios anteriores.

Cuando pasen las pruebas de aceptación de su función, habrá terminado.

Los desarrolladores profesionales llevan la definición de sus requisitos hasta las pruebas de aceptación automatizadas.

Trabajan con las partes interesadas y el control de calidad para garantizar que estas pruebas automatizadas

sean una especificación completa.

Sam: "Está bien, ahora es necesario hacer una copia de seguridad de estos archivos de registro".

Paula: "Está bien, ¿con qué frecuencia?"

Sam: "Diariamente".

Paula: “Correcto. ¿Y dónde quieres que se guarde?

Sam: "¿Qué quieres decir?"

Paula: "¿Quieres que lo guarde en un subdirectorio en particular?"

Sam: "Sí, eso sería bueno".

Paula: “¿Cómo lo llamaremos?”

Sam: "¿Qué tal una 'copia de seguridad'"?

Tom (probador): “Espera, la copia de seguridad es un nombre demasiado común. ¿Qué estás almacenando

realmente en este directorio?

Sam: "Las copias de seguridad".

Tom: "¿Copias de seguridad de qué?"

Sam: "Los archivos de registro".

Paula: "Pero solo hay un archivo de registro".

Sam: “No, hay muchos. Uno para cada día”.

Tom: "¿Quiere decir que hay un archivo de registro activo y muchas copias de seguridad de

archivos de registro?"

101
Machine Translated by Google

CAPÍTULO 7 PRUEBAS DE ACEPTACIÓN

Sam: "Por supuesto".

paula: “¡ay! Pensé que sólo querías una copia de seguridad temporal”.

Sam: "No, el cliente quiere conservarlos todos para siempre".

Paula: “Esa es nueva para mí. Está bien, me alegro de haberlo aclarado”.

Tom: "Entonces, el nombre del subdirectorio debería decirnos exactamente qué contiene".

Sam: "Tiene todos los registros antiguos inactivos".

Tom: "Así que llamémoslo old_inactive_logs".

Sam: "Genial".

Tom: "Entonces, ¿cuándo se crea este directorio?"

Sam: "¿Eh?"

Paula: “Deberíamos crear el directorio cuando se inicia el sistema, pero sólo si

el directorio aún no existe”.

Tom: “Está bien, ahí está nuestra primera prueba. Necesitaré iniciar el sistema y ver si se
crea el directorio old_inactive_logs . Luego agregaré un archivo a ese directorio.
Luego cerraré, comenzaré de nuevo y me aseguraré de que tanto el directorio
como el archivo sigan allí”.

Paula: “Esa prueba te va a llevar mucho tiempo hacerla. El inicio del sistema ya dura 20
segundos y va en aumento. Además, realmente no quiero tener que construir todo
el sistema cada vez que ejecuto las pruebas de aceptación”.

Tom: "¿Qué sugieres?"

Paula: “Crearemos una clase SystemStarter . El programa principal cargará este iniciador
con un grupo de objetos StartupCommand , que seguirán el patrón Command.
Luego, durante el inicio del sistema, SystemStarter
simplemente le indicará a todos los objetos StartupCommand que se ejecuten.
Uno de esos derivados de StartupCommand creará los old_inactive_logs
directorio, pero sólo si aún no existe”.
Tom: “Oh, está bien, entonces todo lo que necesito probar es ese derivado de StartupCommand .

Puedo escribir una prueba sencilla de FitNesse para eso”.

Tom va al tablero.
“La primera parte se verá así”:

dado el comando LogFileDirectoryStartupCommand

dado que el directorio old_inactive_logs no existe

102
Machine Translated by Google

PRUEBAS DE ACEPTACIÓN

cuando se ejecuta el comando

entonces el directorio old_inactive_logs debería existir
y debería estar vacío

“La segunda parte quedará así”:

dado el comando LogFileDirectoryStartupCommand

dado que el directorio old_inactive_logs existe
y que contiene un archivo llamado x
Cuando se ejecuta el comando
Entonces el directorio old_inactive_logs aún debería existir
y aún debería contener un archivo llamado x

Paula: "Sí, eso debería cubrirlo".

Sam: "Vaya, ¿es todo eso realmente necesario?"

Paula: “Sam, ¿cuál de estas dos afirmaciones no es lo suficientemente importante como para
¿especificar?"

Sam: "Solo quiero decir que parece mucho trabajo pensar y escribir todas estas pruebas".

Tom: “Lo es, pero no requiere más trabajo que escribir un plan de prueba manual. Y supone
mucho más trabajo ejecutar repetidamente una prueba manual”.

COMUNICACIÓN

El propósito de las pruebas de aceptación es la comunicación, la claridad y la precisión. Al

aceptarlos, los desarrolladores, las partes interesadas y los evaluadores comprenden cuál es el plan para
el comportamiento del sistema. Lograr este tipo de claridad es responsabilidad de todas las partes. Los
desarrolladores profesionales asumen la responsabilidad de trabajar con las partes interesadas y los
evaluadores para garantizar que todas las partes sepan lo que está a punto de construirse.

UNA UTOMACIÓN

Las pruebas de aceptación siempre deben estar automatizadas. Existe un lugar para las pruebas
manuales en otras partes del ciclo de vida del software, pero este tipo de pruebas nunca deberían ser
manuales. La razón es simple: el costo.

Considere la imagen de la Figura 7­1. Las manos que ves allí pertenecen al director de control de
calidad de una gran empresa de Internet. El documento que sostiene es la tabla de

103
Machine Translated by Google

CAPÍTULO 7 PRUEBAS DE ACEPTACIÓN

contenidos para su plan de prueba manual . Tiene un ejército de probadores manuales en

ubicaciones costa afuera que ejecutan este plan una vez cada seis semanas. Le cuesta más de
un millón de dólares cada vez. Me lo está guardando porque acaba de regresar de una reunión
en la que su jefe le ha dicho que necesitan recortar su presupuesto en un 50%. Su pregunta
para mí es: "¿Qué mitad de estas pruebas no debo realizar?"

Figura 7­1 Plan de prueba manual

Llamar a esto un desastre sería quedarse muy corto. El costo de ejecutar el plan de prueba
manual es tan enorme que han decidido sacrificarlo y simplemente vivir con el hecho de
que no sabrán si la mitad de su producto funciona.

Los desarrolladores profesionales no permiten que suceda este tipo de situaciones. El costo
de automatizar las pruebas de aceptación es tan pequeño en comparación con el costo de
ejecutar planes de prueba manuales que no tiene sentido económico escribir scripts para que los
ejecuten humanos. Los desarrolladores profesionales asumen la responsabilidad de garantizar
que las pruebas de aceptación estén automatizadas.

104
Machine Translated by Google

PRUEBAS DE ACEPTACIÓN

Existen muchas herramientas comerciales y de código abierto que facilitan la automatización de las pruebas de

aceptación. FitNesse, Cucumber, cuke4duke, robot framework y Selenium, solo por mencionar algunos.

Todas estas herramientas le permiten especificar pruebas automatizadas en una forma que los no programadores

puedan leer, comprender e incluso crear.

TRABAJO EXTRA

El punto de vista de Sam sobre el trabajo es comprensible. Parece mucho trabajo extra escribir pruebas de

aceptación como esta . Pero en la Figura 7­1 podemos ver que en realidad no es trabajo extra en absoluto.

Escribir estas pruebas es simplemente el trabajo de especificar el sistema. Especificar a este nivel de detalle es la

única forma en que nosotros, como programadores, podemos saber qué significa "hecho". Especificar a este nivel de

detalle es la única manera en que las partes interesadas pueden garantizar que el sistema por el que están

pagando realmente hace lo que necesitan. Y especificar a este nivel de detalle es la única forma de automatizar con

éxito las pruebas. Así que no consideres estas pruebas como un trabajo extra. Considérelos como un enorme
ahorro de tiempo y dinero. Estas pruebas evitarán que implementes el sistema incorrecto y te permitirán saber

cuándo has terminado.

QUIÉN ESCRIBE LAS PRUEBAS DE ACEPTACIÓN , ¿Y CUÁNDO ?

En un mundo ideal, las partes interesadas y el control de calidad colaborarían para redactar estas pruebas y

los desarrolladores las revisarían para verificar su coherencia. En el mundo real, las partes interesadas rara

vez tienen el tiempo o la inclinación para profundizar en el nivel de detalle requerido. Por eso, a menudo delegan la

responsabilidad a analistas de negocios, control de calidad o incluso desarrolladores. Si resulta que los

desarrolladores deben escribir estas pruebas, entonces tenga cuidado de que el desarrollador que escribe la prueba

no sea el mismo que el desarrollador que implementa la característica probada.

Normalmente, los analistas de negocios escriben las versiones de las pruebas del “camino feliz”, porque esas

pruebas describen las características que tienen valor comercial. El control de calidad normalmente escribe las

pruebas del “camino infeliz”, las condiciones límite, las excepciones y los casos extremos.

Esto se debe a que el trabajo del control de calidad es ayudar a pensar en lo que puede salir mal.

Siguiendo el principio de "precisión tardía", las pruebas de aceptación deben redactarse lo más tarde posible,

normalmente unos días antes de que se implemente la función. En proyectos ágiles, las pruebas se escriben

después de que se hayan seleccionado las funciones para la siguiente iteración o sprint.

105
Machine Translated by Google

CAPÍTULO 7 PRUEBAS DE ACEPTACIÓN

Las primeras pruebas de aceptación deberían estar listas el primer día de la iteración.
Se deben completar más cada día hasta el punto medio de la iteración, cuando todos deberían
estar listos. Si todas las pruebas de aceptación no están listas en el punto medio de la iteración,
entonces algunos desarrolladores tendrán que colaborar para finalizarlas. Si esto sucede con
frecuencia, entonces se deben agregar más BA y/o QA al equipo.

EL PAPEL DEL DESARROLLADOR

El trabajo de implementación de una característica comienza cuando las pruebas de aceptación

para esa característica están listas. Los desarrolladores ejecutan las pruebas de aceptación
de la nueva función y ven cómo fallan. Luego trabajan para conectar la prueba de aceptación al
sistema y luego comienzan a hacer que la prueba pase implementando la característica
deseada.

Paula: “Peter, ¿me echarías una mano con esta historia?”

Peter: “Claro, Paula, ¿qué onda?”

Paula: “Aquí está la prueba de aceptación. Como puedes ver, está fallando”.

dado el comando LogFileDirectoryStartupCommand

dado que el directorio old_inactive_logs no existe
cuando se ejecuta el comando
entonces el directorio old_inactive_logs debería existir
y debería estar vacío

Peter: “Sí, todo rojo. Ninguno de los escenarios está escrito. Déjame escribir el
el primero”.

|escenario|dado el comando _|cmd|

|crear comando|@cmd|

Paula: "¿Tenemos ya una operación createCommand ?"

Peter: "Sí, está en CommandUtilitiesFixture que escribí la semana pasada".

Paula: "Está bien, hagamos la prueba ahora".

Peter: (realiza la prueba). "Sí, la primera línea es verde, pasemos a la siguiente".

No te preocupes demasiado por los escenarios y los accesorios. Estas son sólo algunas de las
tuberías que debe escribir para conectar las pruebas al sistema que se está probando.

106
Machine Translated by Google

PRUEBAS DE ACEPTACIÓN

Baste decir que todas las herramientas proporcionan alguna forma de utilizar la coincidencia de
patrones para reconocer y analizar las declaraciones de la prueba, y luego llamar funciones que
alimentan los datos de la prueba al sistema que se está probando. La cantidad de esfuerzo es
pequeña y los escenarios y accesorios se pueden reutilizar en muchas pruebas diferentes.

El punto de todo esto es que es trabajo del desarrollador conectar las pruebas de aceptación al
sistema y luego hacer que esas pruebas pasen.

PRUEBA DE NEGOCIACIÓN Y AGRESIÓN PASIVA

Los autores de pruebas son humanos y cometen errores. A veces, las pruebas tal como están
escritas no tienen mucho sentido una vez que comienzas a implementarlas. Quizás
sean demasiado complicados. Podrían resultar incómodos. Podrían contener suposiciones tontas.
O tal vez simplemente estén equivocados. Esto puede resultar muy frustrante si usted es el
desarrollador que tiene que aprobar la prueba.

Como desarrollador profesional, es su trabajo negociar con el autor de la prueba para obtener una mejor
prueba. Lo que nunca debes hacer es tomar la opción pasivo­agresiva y decirte a ti mismo: "Bueno, eso
es lo que dice la prueba, así que eso es lo que voy a hacer".

Recuerde, como profesional, es su trabajo ayudar a su equipo a crear el mejor software posible.
Eso significa que todos deben estar atentos a los errores y deslices y trabajar juntos para corregirlos.

Paula: "Tom, esta prueba no está del todo bien".

asegúrese de que la operación posterior finalice en 2 segundos.

Tom: “Me parece bien. Nuestro requisito es que los usuarios no deben tener
esperar más de dos segundos. ¿Cuál es el problema?

Paula: “El problema es que esa garantía sólo la podemos dar de manera estadística.
sentido."

Tom: “¿Eh? Eso suena a palabras de comadreja. El requisito son dos.

artículos de segunda clase."

Paula: "Correcto, y podemos lograrlo el 99,5% de las veces".

Tom: "Paula, ese no es el requisito".

Paula: “Pero es la realidad. No hay manera de que pueda hacer la garantía de otra manera”.

107
Machine Translated by Google

CAPÍTULO 7 PRUEBAS DE ACEPTACIÓN

Tom: "Sam va a tener un ataque".

Paula: “No, la verdad es que ya hablé con él del tema. Está bien siempre que la experiencia normal
del usuario sea de dos segundos o menos”.

Tom: “Está bien, entonces, ¿cómo escribo esta prueba? No puedo decir simplemente que la
operación posterior suele terminar en dos segundos”.

Paula: “Lo dices estadísticamente”.

Tom: “¿Quieres decir que quieres que realice mil operaciones posteriores y me asegure de que no
más de cinco sean más de dos segundos? Eso es absurdo”.

Paula: “No, eso tomaría casi una hora para ejecutarse. ¿Qué tal
¿este?"

ejecutar 15 transacciones posteriores y acumular tiempos.

asegúrese de que la puntuación Z durante 2 segundos sea al menos 2,57

Tom: "Vaya, ¿qué es una puntuación Z?"

Paula: “Sólo un poco de estadística. Toma, ¿qué tal esto?

ejecutar 15 transacciones posteriores y acumular tiempos.

asegúrese de que las probabilidades sean del 99,5% de que el tiempo sea inferior a 2 segundos.

Tom: "Sí, es legible, más o menos, pero ¿puedo confiar en las matemáticas detrás de la
¿Escenas?

Paula: “Me aseguraré de mostrar todos los cálculos intermedios en la prueba.

informe para que puedas comprobar los cálculos si tienes alguna duda”.

Tom: "Está bien, eso funciona para mí".

PRUEBAS DE ACEPTACIÓN Y PRUEBAS UNIDADES

Las pruebas de aceptación no son pruebas unitarias . Las pruebas unitarias son escritas por programadores para

programadores. Son documentos de diseño formales que describen la estructura y el comportamiento del
nivel más bajo del código. La audiencia son programadores, no empresas.

Las pruebas de aceptación las escribe la empresa para la empresa (incluso cuando usted, el desarrollador,
termina escribiéndolas). Son documentos de requisitos formales que especifican cómo debe comportarse el
sistema desde el punto de vista del negocio. La audiencia es la empresa y los programadores.

108
Machine Translated by Google

PRUEBAS DE ACEPTACIÓN

Puede resultar tentador intentar eliminar el “trabajo extra” suponiendo que los dos tipos de pruebas son
redundantes. Si bien es cierto que las pruebas unitarias y de aceptación a menudo prueban lo mismo, no
son redundantes en absoluto.

En primer lugar, aunque pueden probar las mismas cosas, lo hacen a través de mecanismos y vías
diferentes. Las pruebas unitarias profundizan en las entrañas del sistema al realizar llamadas a métodos
en clases particulares. Las pruebas de aceptación invocan el sistema mucho más lejos, en el nivel de API
o, a veces, incluso de UI. Entonces, las vías de ejecución que toman estas pruebas son muy diferentes.

Pero la verdadera razón por la que estas pruebas no son redundantes es que su función principal no es
realizar pruebas. El hecho de que sean pruebas es incidental. Las pruebas unitarias y las pruebas de
aceptación son primero los documentos y luego las pruebas. Su objetivo principal es documentar formalmente
el diseño, estructura y comportamiento del sistema. El hecho de que verifiquen automáticamente el diseño,
la estructura y el comportamiento que especifican es tremendamente útil, pero la especificación es
su verdadero propósito.

GUI S Y OTRAS COMPLICACIONES

Es difícil especificar las GUI desde el principio. Se puede hacer, pero rara vez se hace bien. La razón es
que la estética es subjetiva y por tanto volátil. La gente quiere jugar con las GUI. Quieren masajearlos y
manipularlos. Quieren probar diferentes fuentes, colores, diseños de página y flujos de trabajo. Las GUI
están en constante cambio.

Esto dificulta la redacción de pruebas de aceptación para GUI. El truco consiste en diseñar el sistema
de modo que pueda tratar la GUI como si fuera una API en lugar de un conjunto de botones, controles
deslizantes, cuadrículas y menús. Esto puede sonar extraño, pero en realidad es simplemente un buen
diseño.

Existe un principio de diseño llamado Principio de Responsabilidad Única (SRP). Este principio establece
que se deben separar aquellas cosas que cambian por diferentes razones y agrupar aquellas que cambian
por las mismas razones.
Las GUI no son una excepción.

El diseño, el formato y el flujo de trabajo de la GUI cambiarán por razones estéticas y de eficiencia,
pero la capacidad subyacente de la GUI seguirá siendo la misma.

109
Machine Translated by Google

CAPÍTULO 7 PRUEBAS DE ACEPTACIÓN

a pesar de estos cambios. Por lo tanto, al escribir pruebas de aceptación para una GUI se
aprovechan las abstracciones subyacentes que no cambian con mucha frecuencia.

Por ejemplo, puede haber varios botones en una página. En lugar de crear pruebas que
hagan clic en esos botones según sus posiciones en la página, es posible que pueda
hacer clic en ellos según sus nombres. Mejor aún, quizás cada uno de ellos tenga una
identificación única que puedas usar. Es mucho mejor escribir una prueba que
seleccione el botón cuyo ID es ok_button que seleccionar el botón en la columna 3 de la
fila 4 de la cuadrícula de control.

Pruebas a través de la interfaz adecuada

Mejor aún es escribir pruebas que invoquen las características del sistema subyacente a
través de una API real en lugar de a través de la GUI. Esta API debe ser la misma API utilizada
por la GUI. Esto no es nada nuevo. Los expertos en diseño nos han estado diciendo durante
décadas que separemos nuestras GUI de nuestras reglas comerciales.

Probar a través de la GUI siempre es problemático a menos que esté probando solo la GUI.
La razón es que es probable que la GUI cambie, lo que hace que las pruebas sean muy frágiles.
Cuando cada cambio de GUI rompa mil pruebas, comenzará a desechar las pruebas o dejará
de cambiar la GUI. Ninguna de esas son buenas opciones. Así que escriba sus pruebas de
reglas comerciales para pasar por una API justo debajo de la GUI.

Algunas pruebas de aceptación especifican el comportamiento de la propia GUI. Estas pruebas

deben pasar por la GUI. Sin embargo, estas pruebas no prueban reglas comerciales y, por lo
tanto, no requieren que las reglas comerciales estén conectadas a la GUI. Por lo tanto, es
una buena idea desacoplar la GUI y las reglas comerciales y reemplazar las reglas comerciales
con códigos auxiliares mientras se prueba la propia GUI.

Mantenga las pruebas de GUI al mínimo. Son frágiles porque la GUI es volátil.
Cuantas más pruebas de GUI tenga, es menos probable que las conserve.

INTEGRACIÓN CONTINUA

Asegúrese de que todas sus pruebas unitarias y pruebas de aceptación se ejecuten varias
veces al día en un sistema de integración continua . Este sistema debe ser activado por su

110
Machine Translated by Google

CONCLUSIÓN

Sistema de control de código fuente. Cada vez que alguien confirma un módulo, el sistema CI
debe iniciar una compilación y luego ejecutar todas las pruebas en el sistema. Los resultados de
esa ejecución deben enviarse por correo electrónico a todos los miembros del equipo.

Detener las prensas

Es muy importante mantener las pruebas de CI funcionando en todo momento. Nunca deberían fallar.
Si fallan, entonces todo el equipo debería dejar lo que están haciendo y concentrarse en lograr que las
pruebas fallidas pasen nuevamente. Una falla en el sistema CI debe verse como una
emergencia, un evento de "detener las imprentas".

He consultado a equipos que no tomaron en serio las pruebas fallidas. Estaban “demasiado
ocupados” para arreglar las pruebas rotas, por lo que las dejaron a un lado y prometieron arreglarlas
más tarde. En un caso, el equipo eliminó las pruebas fallidas de la compilación porque era muy
inconveniente verlas fallar. Más tarde, después de entregarlo al cliente, se dieron cuenta de que
se habían olvidado de volver a colocar esas pruebas en la compilación. Se enteraron de esto porque un
cliente enojado los llamó con informes de errores.

CONCLUSIÓN

La comunicación sobre los detalles es difícil. Esto es especialmente cierto para los programadores y
las partes interesadas que se comunican sobre los detalles de una aplicación. Es demasiado fácil
para cada parte agitar la mano y asumir que la otra parte comprende. Con demasiada
frecuencia ambas partes coinciden en que entienden y se van con ideas completamente diferentes.

La única forma que conozco de eliminar eficazmente los errores de comunicación entre programadores
y partes interesadas es escribir pruebas de aceptación automatizadas. Estas pruebas son tan
formales que se ejecutan. Son completamente inequívocos y no pueden desincronizarse con la
aplicación. Son el documento de requisitos perfecto.

111
Machine Translated by Google

Esta página se dejó en blanco intencionalmente.

Machine Translated by Google

8 ESTRATEGIAS DE PRUEBA

Los desarrolladores profesionales prueban su código. Pero las pruebas no son simplemente una
cuestión de escribir unas cuantas pruebas unitarias o unas cuantas pruebas de aceptación. Escribir
estas pruebas es algo bueno, pero está lejos de ser suficiente. Lo que todo equipo de desarrollo
profesional necesita es una buena estrategia de prueba.

En 1989, estaba trabajando en Rational en el primer lanzamiento de Rose. Aproximadamente cada mes,
nuestro gerente de control de calidad convocaba un día de "búsqueda de errores". Todos los miembros
del equipo, desde programadores hasta gerentes, secretarias y administradores de bases de datos, se
sentaban con Rose y trataban de hacerlo fracasar. Se concedieron premios a distintos tipos de

113
Machine Translated by Google

CAPÍTULO 8 ESTRATEGIAS DE PRUEBA

insectos. La persona que encuentre un insecto que se estrelle podría ganar una cena para dos. La
persona que encuentre más errores podría ganar un fin de semana en Monterrey.

QA NO DEBE ENCONTRAR NADA

He dicho esto antes y lo diré de nuevo. A pesar de que su empresa puede tener un grupo de control
de calidad independiente para probar el software, el objetivo del grupo de desarrollo debe ser que el
control de calidad no encuentre nada malo.

Por supuesto, no es probable que este objetivo se logre constantemente. Después de todo, cuando
tienes un grupo de personas inteligentes comprometidas y decididas a encontrar todas las arrugas
y deficiencias de un producto, es probable que encuentren algunas. Aún así, cada vez que el control de
calidad encuentra algo, el equipo de desarrollo debería reaccionar con horror. Deberían preguntarse
cómo ocurrió y tomar medidas para prevenirlo en el futuro.

QA SOY PARTE DEL EQUIPO

La sección anterior podría haber hecho parecer que la garantía de calidad y el desarrollo están en
desacuerdo, que su relación es contradictoria. Ésta no es la intención.
Más bien, el control de calidad y el desarrollo deberían trabajar juntos para garantizar la calidad del
sistema. El mejor papel para la parte de control de calidad del equipo es actuar como
especificadores y caracterizadores.

Control de calidad como especificadores

La función del control de calidad debería ser trabajar con las empresas para crear pruebas de aceptación
automatizadas que se conviertan en el verdadero documento de especificaciones y requisitos para
el sistema. Iteración tras iteración, recopilan los requisitos del negocio y los traducen en pruebas que
describen a los desarrolladores cómo debe comportarse el sistema (consulte el Capítulo 7,
“Pruebas de aceptación”). En general, la empresa escribe las pruebas de camino feliz, mientras que el
control de calidad escribe las pruebas de esquina, límite y camino infeliz.

Control de calidad como caracterizadores

La otra función del control de calidad es utilizar la disciplina de las pruebas exploratorias1
para caracterizar el verdadero comportamiento del sistema en ejecución e informar ese comportamiento.

1. [Link]

114
Machine Translated by Google

LA PIRÁMIDE DE AUTOMATIZACIÓN DE PRUEBAS

Volver al desarrollo y los negocios. En esta función, el control de calidad no interpreta los
requisitos. Más bien, están identificando los comportamientos reales del sistema.

LA PIRÁMIDE DE AUTOMATIZACIÓN DE PRUEBAS

Los desarrolladores profesionales emplean la disciplina de desarrollo basado en pruebas para

crear pruebas unitarias. Los equipos de desarrollo profesional utilizan pruebas de aceptación para
especificar su sistema y la integración continua (Capítulo 7, página 110) para evitar la regresión.
Pero estas pruebas son sólo una parte de la historia. Por muy bueno que sea tener un conjunto de
pruebas unitarias y de aceptación, también necesitamos pruebas de nivel superior para garantizar
que el control de calidad no encuentre nada. La Figura 8­1 muestra la pirámide de automatización de pruebas,2
una representación gráfica de los tipos de pruebas que necesita una organización de desarrollo
profesional.

5%

METRO

Exploratorio

Pruebas del sistema

10% interfaz gráfica de usuario

Pruebas de integración
20% API

Pruebas de componentes
50% API

Pruebas unitarias

100% Unidad X

Figura 8­1 La pirámide de automatización de pruebas

2. [COHN09] págs. 311–312

115
Machine Translated by Google

CAPÍTULO 8 ESTRATEGIAS DE PRUEBA

PRUEBAS UNIDADES

En la base de la pirámide se encuentran las pruebas unitarias. Estas pruebas están

escritas por programadores, para programadores, en el lenguaje de programación del sistema.
La intención de estas pruebas es especificar el sistema en el nivel más bajo. Los desarrolladores
escriben estas pruebas antes de escribir el código de producción como una forma de especificar
lo que están a punto de escribir. Se ejecutan como parte de la integración continua para
garantizar que se mantenga la intención de los programadores.

Las pruebas unitarias proporcionan una cobertura tan cercana al 100% como sea práctico.
En general, este número debería rondar los 90. Y debería ser una cobertura verdadera en
lugar de pruebas falsas que ejecutan código sin afirmar su comportamiento.

PRUEBAS DE COMPONENTES

Estas son algunas de las pruebas de aceptación mencionadas en el capítulo anterior.

Generalmente están escritos contra componentes individuales del sistema. Los componentes
del sistema encapsulan las reglas de negocio, por lo que las pruebas de esos componentes son
las pruebas de aceptación de esas reglas de negocio.

Como se muestra en la Figura 8­2, una prueba de componente envuelve un componente. Pasa
datos de entrada al componente y recopila datos de salida del mismo. Prueba que la
salida coincide con la entrada. Cualquier otro componente del sistema se desacopla de la
prueba utilizando técnicas apropiadas de simulación y duplicación de pruebas.

Componente
aceptación
prueba
de

Figura 8­2 Prueba de aceptación de componentes

116
Machine Translated by Google

LA PIRÁMIDE DE AUTOMATIZACIÓN DE PRUEBAS

Las pruebas de los componentes las redactan QA y Business con la ayuda del desarrollo. Están
compuestos en un entorno de prueba de componentes como FitNesse, JBehave o Cucumber. (Los
componentes de la GUI se prueban con entornos de prueba de GUI como Selenium o Watir). La
intención es que la empresa pueda leer e interpretar estas pruebas, si no crearlas.

Las pruebas de componentes cubren aproximadamente la mitad del sistema. Se dirigen más hacia
situaciones de camino feliz y casos muy obvios de esquina, límite y camino alternativo. La gran
mayoría de los casos de caminos infelices están cubiertos por pruebas unitarias y no tienen sentido
al nivel de las pruebas de componentes.

PRUEBAS DE INTEGRACIÓN

Estas pruebas sólo tienen significado para sistemas más grandes que tienen muchos componentes.
Como se muestra en la Figura 8­3, estas pruebas ensamblan grupos de componentes y prueban
qué tan bien se comunican entre sí. Los demás componentes del sistema se desacoplan, como
es habitual, con simulacros y dobles de prueba adecuados.

Las pruebas de integración son pruebas de coreografía . No ponen a prueba las reglas comerciales.
Más bien, prueban qué tan bien baila el conjunto de componentes. Son pruebas de plomería
que aseguran que los componentes estén conectados correctamente y puedan comunicarse
claramente entre sí.

Componente

Componente
Componente
integración
Prueba
de

Componente

Figura 8­3 Prueba de integración

117
Machine Translated by Google

CAPÍTULO 8 ESTRATEGIAS DE PRUEBA

Las pruebas de integración suelen ser escritas por los arquitectos del sistema o diseñadores
principales del sistema. Las pruebas garantizan que la estructura arquitectónica del sistema
sea sólida. Es en este nivel donde podríamos ver pruebas de rendimiento y rendimiento.

Las pruebas de integración suelen escribirse en el mismo lenguaje y entorno que las pruebas
de componentes. Por lo general, no se ejecutan como parte del conjunto de integración continua
porque suelen tener tiempos de ejecución más prolongados. En cambio, estas pruebas se
realizan periódicamente (cada noche, semanalmente, etc.) según lo consideren
necesario sus autores.

PRUEBAS DEL SISTEMA

Estas son pruebas automatizadas que se ejecutan en todo el sistema integrado.

Son las pruebas de integración definitivas. No prueban las reglas comerciales directamente.
Más bien, prueban que el sistema se haya conectado correctamente y que sus partes
interoperen según el plan. Esperaríamos ver pruebas de rendimiento y rendimiento
en esta suite.

Estas pruebas están escritas por los arquitectos del sistema y los líderes técnicos.
Normalmente están escritos en el mismo lenguaje y entorno que las pruebas de integración
para la interfaz de usuario. Se ejecutan con relativa poca frecuencia dependiendo de su
duración, pero cuanto más frecuentemente mejor.

Las pruebas del sistema cubren quizás el 10% del sistema. Esto se debe a que su intención no
es garantizar el comportamiento correcto del sistema, sino la construcción correcta del
sistema. El comportamiento correcto del código y los componentes subyacentes ya ha sido
determinado por las capas inferiores de la pirámide.

PRUEBAS DE EXPLORACIÓN MANUAL

Aquí es donde los humanos ponen las manos en los teclados y los ojos en las pantallas.
Estas pruebas no están automatizadas ni programadas. La intención de estas pruebas es
explorar el sistema en busca de comportamientos inesperados y al mismo tiempo confirmar los
comportamientos esperados. Con ese fin necesitamos cerebros humanos, con
creatividad humana, que trabajen para investigar y explorar el sistema. Crear un plan de
prueba escrito para este tipo de pruebas frustra el propósito.

118
Machine Translated by Google

BIBLIOGRAFÍA

Algunos equipos tendrán especialistas para hacer este trabajo. Otros equipos simplemente
declararán uno o dos días de “búsqueda de errores” en los que tantas personas como sea
posible, incluidos gerentes, secretarias, programadores, evaluadores y redactores de
tecnología, “golpee” el sistema para ver si pueden hacerlo fallar.

El objetivo no es la cobertura. No vamos a probar todas las reglas comerciales ni todas las vías de
ejecución con estas pruebas. Más bien, el objetivo es garantizar que el sistema se comporte
bien bajo operación humana y encontrar creativamente tantas “peculiaridades” como sea
posible.

CONCLUSIÓN

TDD es una disciplina poderosa y las pruebas de aceptación son formas valiosas de expresar y
hacer cumplir los requisitos. Pero son sólo una parte de una estrategia de prueba total. Para
cumplir el objetivo de que “el control de calidad no debería encontrar nada”, los equipos de
desarrollo deben trabajar mano a mano con el control de calidad para crear una jerarquía de
pruebas exploratorias, de unidad, de componente y de sistema. Estas pruebas deben realizarse
con la mayor frecuencia posible para proporcionar la máxima retroalimentación y garantizar que
el sistema permanezca continuamente limpio.

BIBLIOGRAFÍA

[COHN09]: Mike Cohn, Triunfando con Agile, Boston, MA: Addison­Wesley,

2009.

119
Machine Translated by Google

Esta página se dejó en blanco intencionalmente.

Machine Translated by Google

9 GESTIÓN DEL TIEMPO

Ocho horas es un período de tiempo notablemente corto. Son sólo 480 minutos o
28.800 segundos. Como profesional, usted espera utilizar esos preciosos
segundos de la manera más eficiente y efectiva posible. ¿Qué estrategia puedes
utilizar para asegurarte de no perder el poco tiempo que tienes? ¿Cómo puedes
gestionar eficazmente tu tiempo?

En 1986 vivía en Little Sandhurst, Surrey, Inglaterra. Dirigía un departamento

de desarrollo de software de 15 personas para Teradyne en Bracknell. Mi

121
Machine Translated by Google

CAPÍTULO 9 GESTIÓN DEL TIEMPO

Los días fueron agitados con llamadas telefónicas, reuniones improvisadas, problemas con el
servicio de campo e interrupciones. Así que para poder realizar cualquier trabajo tuve que adoptar
algunas disciplinas de gestión del tiempo bastante drásticas.

• Me despertaba a las cinco de la mañana y iba en bicicleta a la oficina en Bracknell a las seis de la
_1
mañana. Eso me dio 2­ Horas de tranquilidad antes del caos del día.
2
comenzó.

• Al llegar escribía un horario en mi pizarra. dividí el tiempo en

Incrementos de 15 minutos y complete la actividad en la que trabajaría durante ese
bloque de tiempo.

• Llené completamente las primeras 3 horas de ese horario. A partir de las 9 am comencé a dejar un
intervalo de 15 minutos por hora; de esa manera podría colocar rápidamente la mayoría de las
interrupciones en uno de esos espacios abiertos y continuar trabajando.

• Dejé el tiempo después del almuerzo sin programar porque sabía que para entonces se
habría desatado el infierno y tendría que estar en modo reactivo por el resto del día.
Durante esos raros períodos de la tarde en los que el caos no se entrometía, simplemente
trabajaba en lo más importante hasta que lo hacía.

Este plan no siempre tuvo éxito. Despertarme a las 5 de la mañana no siempre era factible y, a veces, el
caos irrumpía en todas mis cuidadosas estrategias y consumía mi día. Pero en general pude mantener
la cabeza fuera del agua.

REUNIONES
Las reuniones cuestan alrededor de $200 por hora por asistente. Esto tiene en cuenta salarios,
beneficios, costos de instalaciones, etc. La próxima vez que estés en una reunión, calcula el
costo. Puede que te sorprendas.

Hay dos verdades sobre las reuniones.

1. Las reuniones son necesarias.

2. Las reuniones son una gran pérdida de tiempo.

A menudo estas dos verdades describen igualmente el mismo encuentro. Algunos de los asistentes
pueden encontrarlos invaluables; otros pueden encontrarlos redundantes o inútiles.

122
Machine Translated by Google

REUNIONES

Los profesionales son conscientes del elevado coste de las reuniones. También son
conscientes de que su propio tiempo es precioso; tienen código que escribir y horarios que cumplir.
Por lo tanto, se resisten activamente a asistir a reuniones que no tienen un beneficio inmediato
y significativo.

DECLINANTE

No es necesario que asista a todas las reuniones a las que esté invitado. De hecho, no es
profesional asistir a demasiadas reuniones. Necesitas usar tu tiempo sabiamente. Así que tenga
mucho cuidado con las reuniones a las que asiste y a cuáles rechaza cortésmente.

La persona que lo invita a una reunión no es responsable de administrar su tiempo. Sólo

tú puedes hacer eso. Por lo tanto, cuando reciba una invitación a una reunión, no la acepte
a menos que sea una reunión en la que su participación sea inmediata y significativamente
necesaria para el trabajo que está haciendo ahora.

A veces la reunión será sobre algo que le interesa, pero que no es inmediatamente
necesario. Tendrás que elegir si puedes permitirte el tiempo. Tenga cuidado: puede que haya
más que suficientes reuniones de este tipo para consumir sus días.

A veces, la reunión tratará sobre algo en lo que usted puede contribuir pero que no es
inmediatamente significativo para lo que está haciendo actualmente. Tendrá que elegir si la
pérdida de su proyecto vale el beneficio para el de ellos. Esto puede parecer cínico, pero su
responsabilidad es ante todo con sus proyectos. Aún así, a menudo es bueno que un equipo
ayude a otro, por lo que es posible que desees discutir tu participación con tu
equipo y tu gerente.

A veces, su presencia en la reunión será solicitada por alguien con autoridad, como
un ingeniero de alto nivel en otro proyecto o el gerente de un proyecto diferente. Tendrás que
elegir si esa autoridad supera tu horario de trabajo. Nuevamente, su equipo y su supervisor
pueden ayudarlo a tomar esa decisión.

Uno de los deberes más importantes de su gerente es mantenerlo fuera de las reuniones.
Un buen gerente estará más que dispuesto a defender su decisión de rechazar la asistencia
porque ese gerente está tan preocupado por su tiempo como usted.

123
Machine Translated by Google

CAPÍTULO 9 GESTIÓN DEL TIEMPO

PARTIDA
Las reuniones no siempre salen según lo planeado. A veces te encuentras sentado en una reunión
que habrías rechazado si hubieras sabido más. A veces se añaden nuevos temas o el motivo
favorito de alguien domina la discusión. A lo largo de los años, he desarrollado una regla simple:
cuando la reunión se vuelve aburrida, vete.

Nuevamente, tienes la obligación de administrar bien tu tiempo. Si se encuentra atrapado en una

reunión en la que no es un buen uso de su tiempo, debe encontrar una manera de salir cortésmente
de esa reunión.

Está claro que no deberías salir furioso de una reunión exclamando: “¡Esto es aburrido!”.
No hay necesidad de ser grosero. Podrás simplemente preguntar, en el momento oportuno, si aún es
necesaria tu presencia. Puede explicar que no puede permitirse mucho más tiempo y preguntar si
hay alguna manera de acelerar la discusión o cambiar la agenda.

Lo importante que debe comprender es que permanecer en una reunión que se ha convertido en una
pérdida de tiempo para usted y en la que ya no puede contribuir significativamente no es profesional.
Usted tiene la obligación de gastar sabiamente el tiempo y el dinero de su empleador, por lo que no
es poco profesional elegir el momento adecuado para negociar su salida.

TIENEN UNA GENDA Y UNA META

La razón por la que estamos dispuestos a soportar el costo de las reuniones es que a veces
necesitamos que los participantes estén juntos en una sala para ayudar a lograr un objetivo
específico. Para utilizar sabiamente el tiempo de los participantes, la reunión debe tener una agenda
clara, con tiempos para cada tema y un objetivo establecido.

Si le piden que asista a una reunión, asegúrese de saber qué discusiones hay sobre la mesa, cuánto
tiempo se les asigna y qué objetivo se debe lograr. Si no puede obtener una respuesta clara sobre
estas cosas, rechace cortésmente asistir.

Si va a una reunión y descubre que la agenda ha sido secuestrada o abandonada, debe solicitar
que se presente el nuevo tema y se siga la agenda. Si esto no sucede, debes irte cortésmente
cuando sea posible.

124
Machine Translated by Google

REUNIONES

REUNIONES DE PERMANENTE

Estas reuniones son parte del cañón Agile. Su nombre proviene del hecho de que se espera que
los participantes permanezcan de pie mientras la reunión está en sesión. Cada participante toma su
turno para responder tres preguntas:

1. ¿Qué hice ayer?

2. ¿Qué voy a hacer hoy?

3. ¿Qué hay en mi camino?

Eso es todo. Cada pregunta no debe requerir más de veinte segundos, por lo que cada
participante no debe requerir más de un minuto. Incluso en un grupo de diez personas, esta
reunión debería terminar mucho antes de que transcurran diez minutos.

ITE R ATI EN REUNIONES DE PLANIFICACIÓN

Estas son las reuniones más difíciles del canon Agile para hacerlo bien. Si se hacen mal,
requieren demasiado tiempo. Se necesita habilidad para que estas reuniones salgan bien, una
habilidad que vale la pena aprender.

Las reuniones de planificación de iteraciones están destinadas a seleccionar los elementos del
trabajo pendiente que se ejecutarán en la siguiente iteración. Las estimaciones ya deberían estar
hechas para los artículos candidatos. La evaluación del valor del negocio ya debería estar hecha.
En organizaciones realmente buenas, las pruebas de aceptación/componentes ya estarán escritas,
o al menos esbozadas.

La reunión debe desarrollarse rápidamente, discutiendo brevemente cada elemento de la lista de

candidatos y luego seleccionándolo o rechazándolo. No se deben dedicar más de cinco o diez
minutos a un tema determinado. Si se necesita una discusión más larga, se debe programar para
otro momento con un subconjunto del equipo.

Mi regla general es que la reunión no debería durar más del 5% del tiempo total de la iteración.
Entonces, para una iteración de una semana (cuarenta horas), la reunión debería finalizar en
dos horas.

125
Machine Translated by Google

CAPÍTULO 9 GESTIÓN DEL TIEMPO

ITE R ATI EN RESTROSPECTIVA Y DEMOSTRACIÓN

Estas reuniones se llevan a cabo al final de cada iteración. Los miembros del equipo
discuten qué salió bien y qué salió mal. Las partes interesadas ven una demostración de las
nuevas funciones. Se puede abusar mucho de estas reuniones y pueden consumir mucho
tiempo, así que prográmelas 45 minutos antes de terminar el último día de la iteración. No
asigne más de 20 minutos a la retrospectiva y 25 minutos a la demostración.
Recuerde, solo han pasado una o dos semanas, por lo que no debería haber mucho
de qué hablar.

AR GUME NT S / DESACUERDOS

Kent Beck me dijo una vez algo profundo: "Cualquier discusión que no pueda resolverse
en cinco minutos no puede resolverse discutiendo". La razón por la que se prolonga tanto es que
no hay pruebas claras que respalden a ninguna de las partes. El argumento es
probablemente religioso, más que fáctico.

Los desacuerdos técnicos tienden a dispararse hasta la estratosfera. Cada partido tiene todo
tipo de justificaciones para su postura pero rara vez datos. Sin datos, cualquier argumento que
no logre un acuerdo en unos pocos minutos (entre cinco y treinta) simplemente nunca lo
logrará. Lo único que queda es ir a buscar algunos datos.

Algunas personas intentarán ganar una discusión con la fuerza de su carácter. Podrían gritar,
encararse o actuar de manera condescendiente. No importa; La fuerza de voluntad no resuelve
los desacuerdos por mucho tiempo. Los datos sí.

Algunas personas serán pasivo­agresivas. Aceptarán simplemente poner fin a la discusión y

luego sabotearán el resultado negándose a participar en la solución. Se dirán a sí mismos: "Así
es como lo querían y ahora obtendrán lo que querían". Este es probablemente el peor tipo de
comportamiento poco profesional que existe. Nunca, jamás hagas esto. Si estás de acuerdo,
entonces debes participar .

¿Cómo se obtienen los datos que necesita para resolver un desacuerdo? A veces puedes
realizar experimentos o realizar alguna simulación o modelado. Pero a veces la mejor
alternativa es simplemente lanzar una moneda al aire para elegir uno de los dos caminos en cuestión.

126
Machine Translated by Google

ENFOQUE­MANÁ

Si las cosas salen bien, entonces ese camino era viable. Si te metes en problemas, puedes dar
marcha atrás y seguir el otro camino. Sería prudente acordar un momento y un conjunto de
criterios para ayudar a determinar cuándo se debe abandonar el camino elegido.

Tenga cuidado con las reuniones que en realidad son sólo un lugar para expresar un desacuerdo
y obtener apoyo para un lado o el otro. Y evite aquellos en los que sólo uno de los argumentadores
esté presentando.

Si realmente es necesario resolver una discusión, pida a cada uno de los argumentantes que
presente su caso al equipo en cinco minutos o menos. Luego haga que el equipo vote. Toda

la reunión durará menos de quince minutos.

ENFOQUE ­ MANÁ

Perdónenme si esta sección parece oler a metafísica New Age, o quizás a Dragones y Mazmorras.
Es sólo que así es como pienso sobre este tema.

La programación es un ejercicio intelectual que requiere largos períodos de concentración

y atención. La concentración es un recurso escaso, como el maná.1 Después de haber gastado
su maná de concentración, debe recargarse realizando actividades sin concentración durante una
hora o más.

No sé qué es este maná focalizado, pero tengo la sensación de que es una sustancia física (o
posiblemente su falta) que afecta la alteridad y la atención. Sea lo que sea, puedes sentir cuando
está ahí y puedes sentir cuando se ha ido.
Los desarrolladores profesionales aprenden a gestionar su tiempo para aprovechar su maná de
concentración. Escribimos código cuando nuestro maná de enfoque es alto; y hacemos otras
cosas menos productivas cuando no lo es.

Focus­manna también es un recurso en descomposición. Si no lo usas cuando está allí, es probable

que lo pierdas. Ésa es una de las razones por las que las reuniones pueden ser tan

1. El maná es un bien común en los juegos de rol y fantasía como Dungeons & Dragons. Cada jugador tiene una cierta
cantidad de maná, que es una sustancia mágica que se gasta cada vez que un jugador lanza un hechizo mágico.
Cuanto más potente es el hechizo, más maná de ese jugador se consume. Manna se recarga a un ritmo diario lento y
fijo. Por lo tanto, es fácil usarlo todo en unas pocas sesiones de lanzamiento de hechizos.

127
Machine Translated by Google

CAPÍTULO 9 GESTIÓN DEL TIEMPO

devastador. Si gastas todo tu maná de concentración en una reunión, no te quedará nada para
codificar.

Las preocupaciones y las distracciones también consumen maná de concentración. La pelea

que tuviste con tu cónyuge anoche, la abolladura que hiciste en el guardabarros esta mañana o la
factura que olvidaste pagar la semana pasada te quitarán el maná de concentración rápidamente.

DORMIR

No puedo enfatizar esto lo suficiente. Tengo más maná concentrado después de una buena
noche de sueño. Siete horas de sueño a menudo me darán ocho horas completas de maná
concentrado. Los desarrolladores profesionales gestionan su horario de sueño para asegurarse
de haber recargado su maná de concentración cuando llegan a trabajar por la mañana.

CAFEÍNA

No hay duda de que algunos de nosotros podemos hacer un uso más eficiente de nuestro

maná concentrado consumiendo cantidades moderadas de cafeína. Pero ten cuidado. La

cafeína también provoca un extraño "nerviosismo" en la concentración. Demasiado puede desviar
tu atención en direcciones muy extrañas. Un subidón de cafeína realmente fuerte puede hacerte
perder un día entero concentrándote en todas las cosas equivocadas.

El uso y la tolerancia a la cafeína es algo personal. Mi preferencia personal es una sola taza
de café fuerte por la mañana y una Coca­Cola light con el almuerzo.
A veces duplico esta dosis, pero rara vez hago más que eso.

RECARGAR

Focus­manna se puede recargar parcialmente desenfocando. Una buena caminata larga, una
conversación con amigos, un momento de simplemente mirar por la ventana pueden ayudar a
recuperar el maná de concentración.

Algunas personas meditan. Otras personas toman una siesta reparadora. Otros escucharán un
podcast o hojearán una revista.

128
Machine Translated by Google

ENFOQUE­MANÁ

He descubierto que una vez que se acaba el maná, no puedes forzar el enfoque. Aún
puedes escribir código, pero es casi seguro que tendrás que reescribirlo al día siguiente o vivir
con una masa podrida durante semanas o meses. Por eso es mejor tomarse treinta o
incluso sesenta minutos para desenfocarse.

ENFOQUE MUSCULAR

Hay algo peculiar en realizar disciplinas físicas como las artes marciales, el tai­chi o el yoga.
Aunque estas actividades requieren una concentración significativa, es un tipo de enfoque
diferente al de la codificación. No es intelectual, es músculo. Y de alguna manera la
concentración muscular ayuda a recargar la concentración mental. Sin embargo, es más que
una simple recarga. Encuentro que un régimen regular de concentración muscular aumenta
mi capacidad de concentración mental.

La forma que elegí de concentración física es andar en bicicleta. Viajo durante una o dos
horas, a veces recorriendo veinte o treinta millas. Viajo por un sendero paralelo al río Des Plaines,
por lo que no tengo que lidiar con autos.

Mientras viajo escucho podcasts sobre astronomía o política. A veces simplemente escucho
mi música favorita. Y a veces simplemente apago los auriculares y escucho la naturaleza.

Algunas personas se toman el tiempo para trabajar con las manos. Quizás les guste la
carpintería, la construcción de maquetas o la jardinería. Cualquiera que sea la actividad,
hay algo en las actividades que se centran en los músculos que mejora la capacidad de
trabajar con la mente.

ENTRADA VERSUS SALIDA

Otra cosa que encuentro esencial para concentrarme es equilibrar mi producción

con la información adecuada. Escribir software es un ejercicio creativo . Considero que soy
más creativo cuando estoy expuesto a la creatividad de otras personas. Entonces leí mucha
ciencia ficción. La creatividad de esos autores de alguna manera estimula mi propia
creatividad para el software.

129
Machine Translated by Google

CAPÍTULO 9 GESTIÓN DEL TIEMPO

CAJA DE TIEMPO Y TOMATES

Una forma muy eficaz que he utilizado para gestionar mi tiempo y mi concentración es utilizar
la conocida Técnica Pomodoro,2 también conocida como tomates. La idea básica es muy
simple. Se configura un cronómetro de cocina estándar (tradicionalmente con forma de
tomate) durante 25 minutos. Mientras el cronómetro corre, no dejas que nada interfiera con
lo que estás haciendo. Si suena el teléfono, contesta y pregunta cortésmente si puedes volver
a llamar en 25 minutos. Si alguien se acerca para hacerle una pregunta, pregúntele
cortésmente si puede responderle en un plazo de 25 minutos. Independientemente de la
interrupción, simplemente la pospone hasta que suene el cronómetro. Después de todo, ¡pocas
interrupciones son tan terriblemente urgentes que no pueden esperar 25 minutos!

Cuando suena el temporizador del tomate, dejas de hacer lo que estás haciendo
inmediatamente. Te ocupas de las interrupciones que se produjeron durante el tomate. Luego
te tomas un descanso de unos cinco minutos. Luego configuras el cronómetro durante otros 25
minutos y comienzas con el siguiente tomate. Cada cuarto tomate se toma un descanso
más largo de unos 30 minutos.

Hay bastante escrito sobre esta técnica y te insto a que lo leas.

Sin embargo, la descripción anterior debería proporcionarle la esencia de la técnica.

Con esta técnica, su tiempo se divide en tiempo con tomate y sin tomate.
La época del tomate es productiva. Es con los tomates donde se hace el verdadero trabajo.
El tiempo fuera de los tomates son distracciones, reuniones, descansos u otro tiempo que no
dedica a trabajar en sus tareas.

¿Cuántos tomates puedes hacer en un día? En un buen día, puedes conseguir 12 o incluso 14
tomates. En un mal día, es posible que sólo puedas hacer dos o tres.
Si los cuentas y los registras, obtendrás una idea bastante rápida de cuánto de tu día dedicas a
ser productivo y cuánto dedicas a lidiar con "cosas".

Algunas personas se sienten tan cómodas con la técnica que estiman sus tareas con los tomates
y luego miden su velocidad semanal con los tomates. Pero esto es sólo la guinda del pastel. El
verdadero beneficio de la Técnica Pomodoro es esa ventana de 25 minutos de tiempo
productivo que defiendes agresivamente contra todas las interrupciones.

2. [Link]

130
Machine Translated by Google

CALLEJONES CIEGOS

AVO I BAILE

A veces tu corazón simplemente no está en tu trabajo. Puede ser que lo que hay que hacer sea
aterrador, incómodo o aburrido. Tal vez pienses que te obligará a una confrontación o te llevará a una
madriguera de ratas de la que no podrás escapar. O tal vez simplemente no quieras hacerlo.

PRIORIDAD I NVERSIÓN

Cualquiera sea el motivo, encontrará formas de evitar hacer el trabajo real. Te convences de que hay
otra cosa más urgente y, en su lugar, lo haces. Esto se llama inversión de prioridad. Aumenta la
prioridad de una tarea para poder posponer la tarea que tiene la verdadera prioridad. Las inversiones
de prioridad son una mentira que nos decimos a nosotros mismos.
No podemos afrontar lo que hay que hacer, por lo que nos convencemos de que otra tarea es más
importante. Sabemos que no lo es, pero nos mentimos a nosotros mismos.

En realidad, no nos estamos mintiendo a nosotros mismos. Lo que realmente estamos haciendo es
prepararnos para la mentira que diremos cuando alguien nos pregunte qué estamos haciendo y por
qué lo hacemos. Estamos construyendo una defensa para protegernos del juicio de los demás.

Claramente se trata de un comportamiento poco profesional. Los profesionales evalúan la

prioridad de cada tarea, sin tener en cuenta sus miedos y deseos personales, y ejecutan esas tareas
en orden de prioridad.

CALLEJONES CIEGOS

Los callejones sin salida son una realidad para todos los artesanos del software. A veces tomarás
una decisión y recorrerás un camino técnico que no lleva a ninguna parte.
Cuanto más confiado estés en tu decisión, más tiempo vagarás por el desierto. Si has
arriesgado tu reputación profesional, vagarás para siempre.

La prudencia y la experiencia te ayudarán a evitar ciertos callejones sin salida, pero nunca los
evitarás todos. Entonces, la verdadera habilidad que necesitas es darte cuenta rápidamente cuando
estás en uno y tener el coraje para echarte atrás. A esto a veces se le llama La regla de los hoyos:
cuando estés en uno, deja de cavar.

131
Machine Translated by Google

CAPÍTULO 9 GESTIÓN DEL TIEMPO

Los profesionales evitan concentrarse tanto en una idea que no puedan abandonarla y darle la
vuelta. Mantienen la mente abierta a otras ideas para que, cuando lleguen a un callejón sin salida,
todavía tengan otras opciones.

MARISCOS , BOGS , MPS de SWA , Y OTROS LÍOS

Peores que los callejones sin salida son los desastres. Los desordenes te frenan, pero no te detienen.
Los líos impiden tu progreso, pero aún puedes progresar mediante pura fuerza bruta. Los líos son
peores que los callejones sin salida porque siempre puedes ver el camino a seguir y siempre parece
más corto que el camino de regreso (pero no lo es).

He visto productos arruinados y empresas destruidas por problemas de software. He visto cómo la
productividad de los equipos disminuye desde el jitterbug hasta el canto fúnebre en tan solo unos
meses. Nada tiene un efecto negativo más profundo o duradero en la productividad de un equipo
de software que un desastre. Nada.

El problema es que empezar un lío, como ir por un callejón sin salida, es inevitable. La
experiencia y la prudencia pueden ayudarte a evitarlos, pero eventualmente tomarás una
decisión que te llevará al lío.

La progresión de semejante desastre es insidiosa. Creas una solución a un problema simple,

teniendo cuidado de mantener el código simple y limpio. A medida que el problema crece en alcance y
complejidad, amplía esa base de código, manteniéndola lo más limpia posible. En algún momento,
se da cuenta de que tomó una decisión de diseño incorrecta cuando comenzó y que su código no se
adapta bien en la dirección en la que se mueven los requisitos.

¡Este es el punto de inflexión! Aún puedes regresar y arreglar el diseño. Pero también puedes seguir
adelante. Volver atrás parece caro porque tendrás que reelaborar el código existente, pero volver
nunca será más fácil que ahora. Si sigues adelante, conducirás al sistema a un pantano del que
quizá nunca salga.
escapar.

132
Machine Translated by Google

CONCLUSIÓN

Los profesionales temen los líos mucho más que los callejones sin salida. Siempre
están atentos a los desastres que empiezan a crecer sin límites y harán todo el esfuerzo
necesario para escapar de ellos lo antes y más rápido posible.

Avanzar a través de un pantano, cuando sabes que es un pantano, es el peor tipo de

inversión de prioridad. Al seguir adelante, se está mintiendo a sí mismo, mintiendo a su
equipo, mintiendo a su empresa y mintiendo a sus clientes. Les estás diciendo que todo
estará bien, cuando en realidad te diriges a una perdición compartida.

CONCLUSIÓN

Los profesionales del software son diligentes en la gestión de su tiempo y su

concentración. Entienden las tentaciones de la inversión de prioridades y luchan
contra ella como una cuestión de honor. Mantienen abiertas sus opciones manteniendo
la mente abierta a soluciones alternativas. Nunca se entregan tanto a una solución
como para no poder abandonarla. Y siempre están atentos a la suciedad creciente y
la limpian tan pronto como la detectan. No hay espectáculo más triste que el de un
equipo de desarrolladores de software atravesando infructuosamente un pantano cada vez más profu

133
Machine Translated by Google

Esta página se dejó en blanco intencionalmente.

Machine Translated by Google

10 ESTIMACIÓN

La estimación es una de las actividades más simples, pero más aterradoras, a las que se
enfrentan los profesionales del software. Gran parte del valor empresarial depende de ello.
Gran parte de nuestra reputación depende de ello. Gran parte de nuestra angustia y fracaso
son causados por ello. Es la principal brecha que se ha abierto entre los empresarios y los desarrolladores.
Es la fuente de casi toda la desconfianza que rige esa relación.

135
Machine Translated by Google

CAPÍTULO 10 ESTIMACIÓN

En 1978, fui el desarrollador principal de un programa Z­80 integrado de 32K escrito en lenguaje
ensamblador. El programa se grabó en 32 chips EEprom 1K ´ 8. Estos 32 chips se insertaron
en tres placas, cada una de las cuales contenía 12 chips.

Teníamos cientos de dispositivos en el campo, instalados en centrales telefónicas en todo

Estados Unidos. Cada vez que solucionábamos un error o añadíamos una función, teníamos
que enviar técnicos de servicio de campo a cada una de esas unidades y pedirles que
reemplazaran los 32 chips.

Esto fue una pesadilla. Las fichas y los tableros eran frágiles. Las clavijas de las virutas podrían
doblarse y romperse. La flexión constante de las placas podría dañar las uniones de soldadura.
El riesgo de rotura y error era enorme. El coste para la empresa era demasiado alto.

Mi jefe, Ken Finder, vino a verme y me pidió que solucionara este problema. Lo que quería era una
manera de hacer un cambio en un chip que no requiriera el cambio de todos los demás chips.
Si ha leído mis libros o ha escuchado mis charlas, sabrá que hablo mucho sobre la capacidad de
implementación independiente. Aquí es donde aprendí esa lección por primera vez.

Nuestro problema era que el software era un ejecutable vinculado único. Si se agregaba una
nueva línea de código al programa, todas las direcciones de las siguientes líneas de código
cambiaban. Dado que cada chip simplemente contenía 1K del espacio de direcciones, el contenido
de prácticamente todos los chips cambiaría.

La solución fue bastante simple. Cada chip tuvo que ser desacoplado de todos los demás.
Cada uno tuvo que convertirse en una unidad de compilación independiente que pudiera grabarse
independientemente de todos los demás.

Así que medí los tamaños de todas las funciones de la aplicación y escribí un programa sencillo
que las encajaba, como un rompecabezas, en cada uno de los chips, dejando unos 100 bytes
de espacio para la expansión. Al comienzo de cada chip pongo una tabla de punteros a todas las
funciones de ese chip. Durante el arranque, estos punteros se movieron a la RAM. Todo el
código del sistema se cambió para que las funciones se llamaran sólo a través de estos vectores
RAM y nunca directamente.

136
Machine Translated by Google

ESTIMACIÓN

Sí, lo tienes. Los chips eran objetos, con vtables. Todas las funciones se desplegaron polimórficamente.
Y sí, así es como aprendí algunos de los principios del OOD, mucho antes de saber qué era un objeto.

Los beneficios fueron enormes. No sólo podríamos implementar chips individuales, sino que también
podríamos crear parches en el campo moviendo funciones a la RAM y redirigiendo los vectores. Esto
facilitó mucho la depuración de campo y la aplicación de parches en caliente.

Pero estoy divagando. Cuando Ken vino a verme y me pidió que solucionara este problema, sugirió
algo sobre punteros a funciones. Pasé uno o dos días formalizando la idea y luego le presenté un
plan detallado. Me preguntó cuánto tiempo tardaría y le respondí que me llevaría alrededor de un mes.

Fueron necesarios tres meses.

Sólo he estado borracho dos veces en mi vida, y sólo una vez realmente borracho. Fue en la fiesta de Navidad
de Teradyne en 1978. Yo tenía 26 años.

La fiesta se celebró en la oficina de Teradyne, que era en su mayor parte un espacio de laboratorio abierto.
Todos llegaron temprano y luego hubo una gran tormenta de nieve que impidió que la banda y el proveedor de
catering llegaran. Afortunadamente había mucho alcohol.

No recuerdo mucho de esa noche. Y lo que sí recuerdo desearía no haberlo hecho.

Pero compartiré un momento conmovedor con ustedes.

Estaba sentada en el suelo con las piernas cruzadas con Ken (mi jefe, que en ese momento tenía 29 años
y no estaba borracho) llorando por cuánto tiempo me estaba llevando el trabajo de vectorización. El alcohol
había liberado mis miedos e inseguridades reprimidos sobre mi estimación. No creo que mi cabeza estuviera
en su regazo, pero mi memoria no es muy clara sobre ese tipo de detalles.

Recuerdo haberle preguntado si estaba enojado conmigo y si pensaba que me estaba tomando demasiado
tiempo. Aunque la noche fue borrosa, su respuesta se mantuvo clara durante las décadas siguientes. Él
dijo: “Sí, creo que te ha tomado mucho tiempo, pero puedo ver que estás trabajando duro en ello y haciendo
buenos progresos. Es algo que realmente necesitamos. Así que no, no estoy enojado”.

137
Machine Translated by Google

CAPÍTULO 10 ESTIMACIÓN

¿ QUÉ SAN ESTIMO COMO ?

El problema es que vemos las estimaciones de diferentes maneras. A las empresas les gusta ver las
estimaciones como compromisos. A los desarrolladores les gusta ver las estimaciones como conjeturas.
La diferencia es profunda.

UN COMPROMISO

Un compromiso es algo que debes lograr. Si te comprometes a terminar algo en una fecha
determinada, entonces simplemente tienes que hacerlo antes de esa fecha. Si eso significa que tienes
que trabajar 12 horas al día, los fines de semana, saltándote las vacaciones familiares, que así sea. Has hecho
el compromiso y tienes que honrarlo.

Los profesionales no asumen compromisos a menos que sepan que pueden lograrlos.
Es realmente tan simple como eso. Si te piden que te comprometas con algo que no estás seguro de poder
hacer, entonces estás obligado a rechazarlo. Si le piden que se comprometa con una fecha que sabe que
puede lograr, pero que requeriría muchas horas de trabajo, fines de semana y saltarse vacaciones
familiares, entonces la elección es suya; pero será mejor que estés dispuesto a hacer lo que sea necesario.

El compromiso se trata de certeza. Otras personas aceptarán tus compromisos y harán planes basados en
ellos. El costo de incumplir esos compromisos, para ellos y para su reputación, es enorme. Incumplir un
compromiso es un acto de deshonestidad apenas menos oneroso que una mentira abierta.

UNA ESTIMACIÓN

Una estimación es una suposición. No se implica ningún compromiso. No se hace ninguna promesa.
Faltar un presupuesto no es de ninguna manera deshonroso. La razón por la que hacemos
estimaciones es porque no sabemos cuánto tiempo llevará algo.

Desafortunadamente, la mayoría de los desarrolladores de software son pésimos estimadores. Esto no se debe
a que exista alguna habilidad secreta para estimar: no la hay. La razón por la que a menudo somos tan malos
estimando es porque no entendemos la verdadera naturaleza de una estimación.

Una estimación no es un número. Una estimación es una distribución. Considerar:

138
Machine Translated by Google

¿QUÉ ES UNA ESTIMACIÓN ?

Mike: "¿Cuál es tu estimación para completar la tarea Frazzle?"

Pedro: “Tres días”.

¿Peter realmente terminará en tres días? Es posible, pero ¿qué probabilidad hay?
La respuesta es: no tenemos idea. ¿Qué quiso decir Peter y qué aprendió Mike? Si Mike
regresa en tres días, ¿debería sorprenderse si Peter no ha terminado? ¿Por qué lo estaría? Peter
no se ha comprometido. Peter no le ha dicho qué tan probable es tres días versus cuatro días o
cinco días.

¿Qué habría pasado si Mike le hubiera preguntado a Peter qué tan probable era su estimación de
tres días?

Mike: “¿Qué posibilidades hay de que termines en tres días?

Peter: "Es bastante probable".

Mike: "¿Puedes ponerle un número?"

Peter: "Cincuenta o sesenta por ciento".

Mike: "Así que es muy probable que te lleve cuatro días".

Peter: “Sí, de hecho puede que me lleve cinco o seis, aunque lo dudo”.

Mike: "¿Cuánto lo dudas?"

Pedro: "Oh, no lo sé... Estoy noventa y cinco por ciento seguro de que
terminaré antes de que pasen seis días”.

Mike: "¿Quieres decir que podrían ser siete días?"

Peter: “Bueno, sólo si todo sale mal. Diablos, si todo va

mal, podría tardar diez o incluso once días. Pero no es muy probable que tantas
cosas salgan mal”.

Ahora estamos empezando a centrarnos en la verdad. La estimación de Peter es una

distribución de probabilidad. En su mente, Peter ve la probabilidad de finalización como se
muestra en la Figura 10­1.

Puedes ver por qué Peter dio la estimación original de tres días. Es la barra más alta del gráfico.
Entonces, en opinión de Peter, es la duración más probable para la tarea.
Pero Mike ve las cosas de otra manera. Mira la cola derecha del gráfico y le preocupa que Peter
pueda tardar once días en terminar.

139
Machine Translated by Google

CAPÍTULO 10 ESTIMACIÓN

50%

45%

40%

35%

30%

25%

20%

15%

10%

5%

0%
2 3 4 5 6 7 8 9 10 11

Figura 10­1 Distribución de probabilidad

¿Mike debería preocuparse por esto? ¡Por supuesto! Murphy1 se saldrá con la suya con Peter, por lo que
algunas cosas probablemente saldrán mal.

CUMPLÍ COMPROMISOS

Ahora Mike tiene un problema. No está seguro del tiempo que le tomará a Peter realizar la tarea. Para
minimizar esa incertidumbre, puede pedirle a Peter un compromiso. Esto es algo que Pedro no
está en condiciones de dar.

Mike: "Peter, ¿puedes darme una fecha concreta en la que terminarás?"

Pedro: “No, Mike. Como dije, probablemente estará hecho en tres, tal vez cuatro,
días."

Mike: "¿Podemos decir cuatro entonces?"

Peter: “No, podrían ser cinco o seis”.

Hasta ahora, todos se están comportando de manera justa. Mike ha pedido un compromiso y Peter se ha
negado cuidadosamente a dárselo. Entonces Mike intenta una táctica diferente:

1. La ley de Murphy sostiene que si algo puede salir mal, saldrá mal.

140
Machine Translated by Google

IMPERTINENTE

Mike: "Está bien, Peter, pero ¿puedes intentar que no dure más de seis días?"

La súplica de Mike parece bastante inocente y Mike ciertamente no tiene malas intenciones.
Pero, ¿qué es exactamente lo que Mike le pide a Peter que haga? ¿Qué significa "intentar"?

Hablamos de esto antes, en el Capítulo 2. La palabra intentar es un término complejo. Si Peter acepta
"intentar", entonces se compromete a seis días. No hay otra manera de interpretarlo. Aceptar intentarlo
es aceptar tener éxito.

¿Qué otra interpretación podría haber? ¿Qué es, precisamente, lo que Pedro va a hacer para
“intentar”? ¿Va a trabajar más de ocho horas? Eso está claramente implícito. ¿Va a trabajar los fines
de semana? Sí, eso también está implícito. ¿Se saltará las vacaciones familiares? Sí, eso también
es parte de la implicación. Todas esas cosas son parte de "intentar". Si Peter no hace esas cosas,
entonces Mike podría acusarlo de no esforzarse lo suficiente.

Los profesionales distinguen claramente entre estimaciones y compromisos.

No se comprometen a menos que sepan con certeza que tendrán éxito. Tienen cuidado de no
asumir ningún compromiso implícito . Comunican la distribución de probabilidad de sus estimaciones
lo más claramente posible, de modo que los gerentes puedan hacer planes apropiados.

IMPERTINENTE

En 1957, se creó la Técnica de Revisión y Evaluación de Programas (PERT) para apoyar el

proyecto del submarino Polaris de la Marina de los EE. UU. Uno de los elementos del PERT es la
forma en que se calculan las estimaciones. El esquema proporciona una manera muy simple, pero
muy efectiva, de convertir estimaciones en distribuciones de probabilidad adecuadas para los administradores.

Cuando estimas una tarea, proporcionas tres números. Esto se llama análisis trivariado:

• O: Estimación Optimista. Esta cifra es tremendamente optimista. Sólo podrías realizar la tarea tan
rápido si absolutamente todo saliera bien. De hecho, para que las matemáticas funcionen, este
número debe tener mucho menos que un

141
Machine Translated by Google

CAPÍTULO 10 ESTIMACIÓN

1% de probabilidad de que ocurra.2 En el caso de Peter, esto sería 1 día, como se muestra en
la Figura 10­1.

• N: Estimación Nominal. Esta es la estimación con mayores posibilidades de éxito.

Si tuviera que dibujar un gráfico de barras, sería la barra más alta, como se muestra en
la Figura 10­1. Son 3 días.

• P: Estimación Pesimista. Una vez más esto es tremendamente pesimista. debería

incluyen todo excepto huracanes, guerras nucleares, agujeros negros perdidos y otras
catástrofes. Nuevamente, las matemáticas solo funcionan si este número tiene mucho menos
del 1% de posibilidades de éxito. En el caso de Peter, este número está fuera del gráfico de

la derecha. Entonces 12 días.

Dadas estas tres estimaciones, podemos describir la distribución de probabilidad de la siguiente

manera:

O + 4N + P
•µ=
6

μ es la duración esperada de la tarea. En el caso de Peter es (1+12+12)/6, o aproximadamente

4,2 días. Para la mayoría de las tareas, este será un número algo pesimista porque la cola
derecha de la distribución es más larga que la cola izquierda.3

P­O
•s=
6

s es la desviación estándar4 de la distribución de probabilidad de la tarea. Es una medida de

cuán incierta es la tarea. Cuando este número es grande, la incertidumbre también
lo es. Para Peter, este número es (12 – 1)/6, o aproximadamente 1,8 días.

Dada la estimación de Peter de 4,2/1,8, Mike entiende que esta tarea probablemente se realizará
en cinco días, pero también podría tardar 6 o incluso 9 días en completarse.

2. El número exacto para una distribución normal es 1:769, o 0,13%, o 3 sigma. Las probabilidades son de una entre mil.
probablemente seguro.

3. PERT supone que esto se aproxima a una distribución beta. Esto tiene sentido ya que la duración mínima
para una tarea suele ser mucho más seguro que el máximo. [McConnell2006] Figura 1­3.

4. Si no sabes qué es una desviación estándar, deberías buscar un buen resumen de probabilidad y estadística.
tics. El concepto no es difícil de entender y le resultará muy útil.

142
Machine Translated by Google

IMPERTINENTE

Pero Mike no se limita a realizar una tarea. Está gestionando un proyecto de muchas tareas.
Peter tiene tres de esas tareas en las que debe trabajar en secuencia. Peter ha
estimado estas tareas como se muestra en la Tabla 10­1.

Tabla 10­1 Tareas de Peter

Tarea Optimista Nominal Pesimista µ σ

Alfa 1 3 12 4.2 1.8

Beta 1 1.5 14 3.5 2.2
Gama 3 6.25 11 6.5 1.3

¿Qué pasa con esa tarea “beta”? Parece que Peter tiene bastante confianza en ello,
pero es posible que algo salga mal y lo descarrile significativamente.
¿Cómo debería interpretar eso Mike? ¿Cuánto tiempo debería planear Mike para que
Peter complete las tres tareas?

Resulta que, con unos pocos cálculos simples, Mike puede combinar todas las tareas
de Peter y generar una distribución de probabilidad para todo el conjunto de tareas. Las
matemáticas son bastante sencillas:
•
µ secuencia = ∑μtarea

Para cualquier secuencia de tareas, la duración esperada de esa secuencia es la suma simple
de todas las duraciones esperadas de las tareas en esa secuencia. Entonces, si Peter tiene tres
tareas que completar y sus estimaciones son 4,2/1,8, 3,5/2,2 y 6,5/1,3, entonces Peter
probablemente terminará con las tres en aproximadamente 14 días: 4,2 + 3,5 + 6,5.

2
•
secuencia σ = ∑ σtarea

La desviación estándar de la secuencia es la raíz cuadrada de la suma de los cuadrados

de las desviaciones estándar de las tareas. Entonces, la desviación estándar para las tres
tareas de Peter es aproximadamente 3.

2
+ +1,32 )
(1,8 2,2
2 1/2 =

+
(3,24 2,48 +
1,69)
1/2 =

9,77 1/2 = 3,13

143
Machine Translated by Google

CAPÍTULO 10 ESTIMACIÓN

Esto le dice a Mike que las tareas de Peter probablemente tomarán 14 días, pero muy bien podrían
tomar 17 días (1s) y posiblemente incluso 20 días (2s). Incluso podría llevar más tiempo,
pero es bastante improbable.

Mire nuevamente la tabla de estimaciones. ¿Puedes sentir la presión de realizar las tres tareas
en cinco días? Después de todo, las estimaciones en el mejor de los casos son 1, 1 y 3. Incluso las
estimaciones nominales sólo suman 10 días. ¿Cómo llegamos hasta 14 días, con una posibilidad
de 17 o 20? La respuesta es que la incertidumbre en esas tareas se agrava de una manera que
añade realismo al plan.

Si es un programador con más de unos pocos años de experiencia, probablemente haya visto
proyectos que se estimaron de manera optimista y que tardaron entre tres y cinco veces más
de lo esperado. El sencillo esquema PERT que se acaba de mostrar es una forma razonable de
ayudar a evitar el establecimiento de expectativas optimistas. Los profesionales del software son
muy cuidadosos a la hora de establecer expectativas razonables a pesar de la presión de intentar ir rápido.

ESTIMACIÓN DE TAREAS

Mike y Peter estaban cometiendo un terrible error. Mike le preguntaba a Peter cuánto tiempo le
llevaría realizar sus tareas. Peter dio respuestas trivariadas honestas, pero ¿qué pasa con las
opiniones de sus compañeros de equipo? ¿Podrían tener una idea diferente?

El recurso de estimación más importante que tienes son las personas que te rodean.
Pueden ver cosas que tú no ves. Pueden ayudarle a estimar sus tareas con mayor precisión de la
que puede estimar por su cuenta.

DELPHI DE BANDA ANCHA

En la década de 1970, Barry Boehm nos presentó una técnica de estimación llamada “delphi
de banda ancha”. 5 Ha habido muchas variaciones a lo largo de los años. Algunas son formales,
otras informales; pero todos tienen una cosa en común: el consenso.

La estrategia es simple. Un equipo de personas se reúne, discute una tarea, estima la tarea e
itera la discusión y la estimación hasta llegar a un acuerdo.

5. [Boehm81]

144
Machine Translated by Google

ESTIMACIÓN DE TAREAS

El enfoque original esbozado por Boehm implicó varias reuniones y documentos que implican
demasiada ceremonia y gastos generales para mi gusto. Prefiero enfoques simples y con pocos gastos
generales, como los siguientes.

dedos voladores

Todos se sientan alrededor de una mesa. Las tareas se discuten una a la vez. Para cada
tarea hay una discusión sobre lo que implica, qué podría confundirla o complicarla y
cómo podría implementarse. Luego, los participantes ponen sus manos debajo de la
mesa y levantan de 0 a 5 dedos según cuánto tiempo creen que les llevará la tarea. El
moderador cuenta 1­2­3 y todos los participantes muestran la mano a la vez.

Si todos están de acuerdo, pasan a la siguiente tarea. De lo contrario, continúan la discusión para
determinar por qué no están de acuerdo. Lo repiten hasta que están de acuerdo.

El acuerdo no tiene por qué ser absoluto. Mientras las estimaciones sean cercanas, es suficiente. Entonces,
por ejemplo, un poco de 3 y 4 es un acuerdo. Sin embargo, si todos levantan 4 dedos excepto una persona
que levanta 1 dedo, entonces tienen algo de qué hablar.

La cuantía del presupuesto se decide al inicio de la reunión. Podría ser el número de días para una tarea, o
podría ser alguna escala más interesante, como “dedos multiplicados por tres” o “dedos al cuadrado”.

La simultaneidad de visualización de los dedos es importante. No queremos que la gente cambie sus
estimaciones basándose en lo que ven hacer otras personas.

Planificación del póquer

En 2002, James Grenning escribió un artículo encantador6 que describía “Planificación del póquer”.
Esta variación de Delphi de banda ancha se ha vuelto tan popular que varias compañías diferentes han
utilizado la idea para realizar obsequios de marketing en forma de planificación de mazos de cartas
de póquer.7 Incluso existe un sitio web llamado planificació[Link] que puede utilizar para planificar el
póquer en la Red con equipos distribuidos.

6. [Grenning2002]
7. [Link]

145
Machine Translated by Google

CAPÍTULO 10 ESTIMACIÓN

La idea es muy simple. Para cada miembro del equipo de estimación, reparta una mano de cartas
con diferentes números. Los números del 0 al 5 funcionan bien y hacen que este sistema sea
lógicamente equivalente a dedos voladores.

Elija una tarea y discútala. En algún momento, el moderador pide a todos que elijan una tarjeta.
Los miembros del equipo sacan una tarjeta que coincide con su estimación y la sostienen con el
reverso hacia afuera para que nadie más pueda ver el valor de la tarjeta. Luego el moderador les
dice a todos que muestren sus cartas.

El resto es como dedos voladores. Si hay acuerdo, se acepta el presupuesto. De lo contrario,

las cartas se devuelven a la mano y los jugadores continúan discutiendo la tarea.

Se ha dedicado mucha “ciencia” a elegir los valores correctos de las cartas para una mano.
Algunas personas han llegado a utilizar cartas basadas en una serie de Fibonacci.
Otros han incluido tarjetas para el infinito y el signo de interrogación. Personalmente, creo que
cinco cartas etiquetadas con 0, 1, 3, 5, 10 son suficientes.

Estimación de afinidad

Hace varios años, Lowell Lindstrom me mostró una variación particularmente única de Delphi de
banda ancha. He tenido bastante suerte con este enfoque con varios clientes y equipos.

Todas las tareas están escritas en tarjetas, sin que se muestren estimaciones. El equipo
de estimación se para alrededor de una mesa o una pared con las tarjetas distribuidas al
azar. Los miembros del equipo no hablan, simplemente empiezan a clasificar las tarjetas entre
sí. Las tareas que tardan más se mueven hacia la derecha. Las tareas más pequeñas se mueven
hacia la izquierda.

Cualquier miembro del equipo puede mover cualquier carta en cualquier momento, incluso si ya
ha sido movida por otro miembro. Cualquier carta movida más de h veces se deja a un lado para
su discusión.

Con el tiempo, la clasificación silenciosa se desvanece y puede comenzar la discusión. Se exploran

los desacuerdos sobre el orden de las tarjetas. Es posible que haya algunas sesiones de diseño
rápidas o algunos marcos de alambre dibujados a mano para ayudar a lograr un consenso.

146
Machine Translated by Google

CONCLUSIÓN

El siguiente paso es dibujar líneas entre las tarjetas que representan los tamaños de los cubos.
Estos depósitos pueden estar en días, semanas o puntos. Cinco cubos en una secuencia de
Fibonacci (1, 2, 3, 5, 8) es tradicional.

Estimaciones trivariadas

Estas técnicas Delphi de banda ancha son buenas para elegir una estimación nominal única
para una tarea. Pero como dijimos anteriormente, la mayoría de las veces queremos tres
estimaciones para poder crear una distribución de probabilidad. Los valores optimistas y
pesimistas para cada tarea se pueden generar muy rápidamente utilizando cualquiera de las
variantes de Delphi de banda ancha. Por ejemplo, si está utilizando el póquer de planificación,
simplemente le pide al equipo que muestre las cartas para su estimación pesimista y luego tome la
más alta. Haga lo mismo con la estimación optimista y tome la más baja.

LA LEY DE LOS GRANDES NÚMEROS

Las estimaciones están plagadas de errores. Por eso se llaman estimaciones. Una forma de gestionar
el error es aprovechar la Ley de los Grandes Números.8 Una implicación de esta ley es que si se
divide una tarea grande en muchas tareas más pequeñas y se estiman de forma independiente, la
suma de las estimaciones de las tareas pequeñas será ser más preciso que una sola estimación
de la tarea más grande. La razón de este aumento en la precisión es que los errores en las tareas
pequeñas tienden a integrarse.

Francamente, esto es optimista. Los errores en las estimaciones tienden a subestimar y no a

sobreestimar, por lo que la integración no es perfecta. Dicho esto, dividir las tareas
grandes en pequeñas y estimar las pequeñas de forma independiente sigue siendo una buena
técnica. Algunos de los errores se integran y dividir las tareas es una buena manera de
comprenderlas mejor y descubrir sorpresas.

CONCLUSIÓN

Los desarrolladores de software profesionales saben cómo proporcionar a la empresa

estimaciones prácticas que la empresa puede utilizar con fines de planificación. No hacen promesas
que no puedan cumplir ni compromisos que no están seguros de poder cumplir.

8. [Link]

147
Machine Translated by Google

CAPÍTULO 10 ESTIMACIÓN

Cuando los profesionales se comprometen, proporcionan cifras concretas y luego formulan

esas cifras. Sin embargo, en la mayoría de los casos los profesionales no asumen dichos
compromisos. Más bien, proporcionan estimaciones probabilísticas que describen el tiempo
esperado de finalización y la variación probable.

Los desarrolladores profesionales trabajan con los demás miembros de su equipo para lograr
un consenso sobre las estimaciones que se entregan a la dirección.

Las técnicas descritas en este capítulo son ejemplos de algunas de las diferentes formas en
que los desarrolladores profesionales crean estimaciones prácticas. Éstas no son las únicas
técnicas de este tipo y no son necesariamente las mejores. Son simplemente
técnicas que he descubierto que funcionan bien para mí.

BIBLIOGRAFÍA

[McConnell2006]: Steve McConnell, Estimación de software: desmitificando al negro

Arte, Redmond, WA: Microsoft Press, 2006.

[Boehm81]: Barry W. Boehm, Economía de la ingeniería de software, Upper Saddle River,

Nueva Jersey: Prentice Hall, 1981.

[Grenning2002]: James Grenning, “Planificación del póquer o cómo evitar la parálisis del
análisis durante la planificación del lanzamiento”, abril de 2002, [Link]
net/papers/14­papers/44­planing­[Link]

148
Machine Translated by Google

11PRESIÓN

Imagine que está teniendo una experiencia extracorporal, observándose a sí mismo en una
mesa de operaciones mientras un cirujano le realiza una cirugía a corazón abierto. Ese cirujano
está tratando de salvarle la vida, pero el tiempo es limitado, por lo que está operando dentro de
una fecha límite, una fecha límite literal .

149
Machine Translated by Google

CAPÍTULO 11 PRESIÓN

¿Cómo quieres que se comporte ese doctor? ¿Quieres que parezca tranquilo y sereno?
¿Quieres que dé órdenes claras y precisas a su personal de apoyo?
¿Quieres que siga su formación y se adhiera a sus disciplinas?

¿O quieres que sude y maldiga? ¿Quieres que golpee y arroje instrumentos? ¿Quiere que
culpe a la dirección por expectativas poco realistas y se queje continuamente del tiempo?
¿Quieres que se comporte como un profesional o como un desarrollador típico?

El desarrollador profesional se muestra tranquilo y decidido bajo presión. A medida que la

presión crece, se apega a sus entrenamientos y disciplinas, sabiendo que son la mejor manera
de cumplir con los plazos y compromisos que lo apremian.

En 1988 trabajaba en Clear Communications. Esta fue una nueva empresa que nunca llegó a
ponerse en marcha. Quemamos nuestra primera ronda de financiación y luego tuvimos que
optar por una segunda y luego por una tercera.

La visión inicial del producto sonaba bien, pero la arquitectura del producto nunca parecía
concretarse. Al principio el producto era tanto software como hardware. Luego pasó
a ser sólo software. La plataforma de software cambió de PC a Sparcstations. Los clientes
cambiaron de gama alta a gama baja.
Con el tiempo, incluso la intención original del producto se desvió cuando la empresa intentó
encontrar algo que generara ingresos. En los casi cuatro años que pasé allí, no creo que la
empresa haya obtenido ni un centavo de ingresos.

No hace falta decir que nosotros, los desarrolladores de software, estábamos bajo una
presión significativa. Hubo bastantes noches muy largas, e incluso fines de semana más
largos en la oficina de la terminal. Las funciones se escribieron en C y tenían 3.000 líneas
de longitud. Hubo discusiones con gritos y insultos. Hubo intrigas y subterfugios. Había
puños atravesando las paredes, bolígrafos arrojados furiosamente contra las pizarras,
caricaturas de colegas molestos grabadas en las paredes con las puntas de los lápices, y
había un suministro interminable de ira y estrés.

Los plazos fueron determinados por los acontecimientos. Las funciones debían prepararse para ferias
comerciales o demostraciones de clientes. Cualquier cosa que un cliente pidiera, por tonta que fuera, la
tendríamos lista para la siguiente demostración. El tiempo siempre fue demasiado corto. El trabajo
siempre quedó atrás. Los horarios siempre eran abrumadores.

150
Machine Translated by Google

EVITANDO LA PRESIÓN

Si trabajaras 80 horas a la semana, podrías ser un héroe. Si resolvieran un poco de

desorden para una demostración para un cliente, podrían ser un héroe. Si lo hicieras lo
suficiente, podrías ser ascendido. Si no lo hacías, te podrían despedir. Era una empresa
nueva: todo se trataba de “participar en el esfuerzo”. Y en 1988, con casi 20 años de
experiencia a mis espaldas, lo compré.

Yo era el gerente de desarrollo y les decía a los programadores que trabajaban para
mí que tenían que trabajar más y más rápido. Yo era uno de los chicos de 80 horas,
escribiendo funciones C de 3000 líneas a las 2 am mientras mis hijos dormían en casa
sin su padre en casa. Yo fui quien arrojó los bolígrafos y gritó. Hice que despidieran a la
gente si no se comportaban bien. Fue horrible. Fui horrible.

Luego llegó el día en que mi esposa me obligó a mirarme detenidamente en el espejo.

No me gustó lo que vi. Ella me dijo que no era muy agradable estar conmigo.
Tuve que estar de acuerdo. Pero no me gustó, así que salí furioso de la casa y
comencé a caminar sin rumbo. Caminé durante unos treinta minutos, hirviendo
mientras caminaba; y luego empezó a llover.

Y algo hizo clic dentro de mi cabeza. Empecé a reír. Me reí de mi locura.

Me reí de mi estrés. Me reí del hombre del espejo, el pobre imbécil que había estado
haciéndose la vida imposible a él y a los demás en nombre de... ¿qué?

Todo cambió ese día. Detuve las horas locas. Dejé el estilo de vida de alto estrés.
Dejé de tirar bolígrafos y de escribir funciones C de 3000 líneas.
Decidí que iba a disfrutar mi carrera haciéndolo bien, no haciéndolo estúpidamente.

Dejé ese trabajo lo más profesionalmente que pude y me convertí en consultor. Desde
ese día nunca he llamado "jefe" a otra persona.

EVITAR LA PRESIÓN DE IZQUIERDO

La mejor manera de mantener la calma bajo presión es evitar las situaciones que causan
presión. Es posible que evitarlo no elimine la presión por completo, pero puede
contribuir en gran medida a minimizar y acortar los períodos de alta presión.

151
Machine Translated by Google

CAPÍTULO 11 PRESIÓN

COMPROMISOS

Como descubrimos en el capítulo 10, es importante evitar comprometernos con plazos

que no estamos seguros de poder cumplir. La empresa siempre querrá estos compromisos
porque quiere eliminar el riesgo. Lo que debemos hacer es asegurarnos de que el riesgo esté
cuantificado y presentado a la empresa para que puedan gestionarlo adecuadamente. Aceptar
compromisos poco realistas frustra este objetivo y perjudica tanto a la empresa como a nosotros
mismos.

A veces los compromisos se hacen por nosotros. A veces nos encontramos con que nuestra

empresa ha hecho promesas a los clientes sin consultarnos. Cuando esto sucede, tenemos el
honor de ayudar a la empresa a encontrar una manera de cumplir esos
compromisos. Sin embargo, no estamos obligados por honor a aceptar los compromisos.

La diferencia es importante. Los profesionales siempre ayudarán a la empresa a encontrar la

manera de lograr sus objetivos. Pero los profesionales no necesariamente aceptan los
compromisos que la empresa asume para ellos. Al final, si no podemos encontrar la manera de
cumplir las promesas hechas por la empresa, entonces las personas que hicieron las
promesas deben aceptar la responsabilidad.

Esto es fácil de decir. Pero cuando su negocio fracasa y su cheque de pago se retrasa
debido a compromisos incumplidos, es difícil no sentir la presión. Pero si se ha comportado
profesionalmente, al menos podrá mantener la cabeza en alto mientras busca un nuevo trabajo.

MANTÉNGASE LIMPIO

La forma de avanzar rápido y mantener los plazos a raya es mantenerse limpio. Los profesionales
no sucumben a la tentación de crear un desorden para actuar rápidamente.
Los profesionales se dan cuenta de que “rápido y sucio” es un oxímoron. ¡Sucio siempre significa
lento!

Podemos evitar la presión manteniendo nuestros sistemas, nuestro código y nuestro diseño
lo más limpios posible. Esto no quita que pasemos horas interminables puliendo código.
Simplemente significa que no toleramos los líos. Sabemos que los líos nos ralentizarán,
provocando que perdamos fechas y rompamos compromisos. Por eso hacemos el mejor trabajo
que podemos y mantenemos nuestra producción lo más limpia posible.

152
Machine Translated by Google

PRESIÓN DE MANEJO

DISCIPLINA DE CRISIS

Sabes lo que crees al observarte a ti mismo en una crisis. Si en una crisis sigues tus
disciplinas, entonces realmente crees en esas disciplinas. Por otro lado, si cambia su
comportamiento en una crisis, entonces no cree realmente en su comportamiento
normal.

Si sigue la disciplina del desarrollo basado en pruebas en tiempos sin crisis pero la
abandona durante una crisis, entonces realmente no confía en que TDD sea útil.
Si mantienes tu código limpio durante tiempos normales pero haces líos en una crisis,
entonces realmente no crees que los líos te frenan. Si se empareja en una crisis pero
normalmente no se empareja, entonces cree que emparejar es más eficiente que no hacerlo.

Elija disciplinas con las que se sienta cómodo siguiendo en una crisis. Entonces síguelos
todo el tiempo. Seguir estas disciplinas es la mejor manera de evitar caer
en una crisis.

No cambie su comportamiento cuando llegue la crisis. Si sus disciplinas son la mejor

manera de trabajar, entonces deben seguirse incluso en lo más profundo de una crisis.

PRESIÓN DE MANEJO

Prevenir, mitigar y eliminar la presión está muy bien, pero a veces la presión llega a
pesar de todas sus mejores intenciones y prevenciones.
A veces, el proyecto simplemente lleva más tiempo de lo que nadie pensaba. A veces el
diseño inicial simplemente es incorrecto y es necesario reelaborarlo. A veces se pierde
un miembro valioso del equipo o un cliente. A veces haces un compromiso que
simplemente no puedes cumplir. ¿Entonces qué?

NO ENTRAR EN PÁNICO

Maneja tu estrés. Las noches sin dormir no te ayudarán a terminar más rápido. Sentarse y
preocuparse tampoco ayudará. ¡Y lo peor que puedes hacer es apresurarte!
Resiste esa tentación a toda costa. Correr solo te llevará más profundamente al agujero.

153
Machine Translated by Google

CAPÍTULO 11 PRESIÓN

En lugar de eso, reduce la velocidad. Piensa bien el problema. Trazar un rumbo hacia el mejor
resultado posible y luego avanzar hacia ese resultado a un ritmo razonable y constante.

COMUNICAR

Hazle saber a tu equipo y a tus superiores que estás en problemas. Cuéntales tus mejores planes
para salir del problema. Pídales su opinión y orientación.
Evite crear sorpresas. Nada enoja más y hace menos racional a la gente que las sorpresas. Las
sorpresas multiplican por diez la presión.

CONFÍA EN TUS DISCIPLINAS

Cuando las cosas se pongan difíciles, confíe en sus disciplinas. La razón por la que tienes
disciplinas es brindarle orientación en momentos de alta presión. Estos son los tiempos para prestar
especial atención a todas tus disciplinas. No son tiempos para cuestionarlos o abandonarlos.

En lugar de mirar a tu alrededor con pánico buscando algo, cualquier cosa, que te ayude a terminar
más rápido, sé más deliberado y dedicado a seguir las disciplinas que hayas elegido. Si sigue
TDD, escriba incluso más pruebas de lo habitual. Si eres un refactorizador despiadado, entonces
refactoriza aún más. Si mantiene sus funciones pequeñas, manténgalas aún más pequeñas. La
única manera de superar la olla a presión es confiar en lo que ya sabes que funciona: tus
disciplinas.

OBTENGA AYUDA

¡Par! Cuando la tensión esté alta, busque un asociado que esté dispuesto a emparejar el programa
con usted. Terminará más rápido y con menos defectos. Tu pareja te ayudará a mantener tus
disciplinas y evitará que entres en pánico. Tu pareja detectará cosas que tú pasas por alto, tendrá
ideas útiles y tomará el relevo cuando pierdas la concentración.

154
Machine Translated by Google

CONCLUSIÓN

Del mismo modo, cuando veas a alguien más que esté bajo presión, ofrécete a formar
pareja con él. Ayúdalos a salir del hoyo en el que se encuentran.

CONCLUSIÓN

El truco para manejar la presión es evitarla cuando puedas y capearla cuando no puedas.
Lo evitas gestionando compromisos, siguiendo tus disciplinas y manteniéndote limpio. Lo
superas manteniendo la calma, comunicándote, siguiendo tus disciplinas y buscando
ayuda.

155
Machine Translated by Google

Esta página se dejó en blanco intencionalmente.

Machine Translated by Google

12 COLABORACIÓN

La mayor parte del software es creado por equipos. Los equipos son más eficaces
cuando sus miembros colaboran profesionalmente. No es profesional ser un solitario o
un recluso en un equipo.

En 1974 yo tenía 22 años. Mi matrimonio con mi maravillosa esposa, Ann Marie, apenas tenía
seis meses. Todavía faltaba un año para el nacimiento de mi primera hija, Ángela. Y
trabajé en una división de Teradyne conocida como Chicago Laser Systems.

157
Machine Translated by Google

CAPÍTULO 12 COLABORACIÓN

A mi lado trabajaba mi compañero de secundaria, Tim Conrad. Tim y yo habíamos obrado bastantes
milagros en nuestra época. Construimos computadoras juntos en su sótano. En la mía construimos
las escaleras de Jacob. Nos enseñamos mutuamente cómo programar PDP­8 y cómo conectar
circuitos integrados y transistores a calculadoras que funcionen.

Éramos programadores que trabajaban en un sistema que utilizaba láseres para ajustar componentes
electrónicos como resistencias y condensadores con una precisión extremadamente alta. Por
ejemplo, recortamos el cristal del primer reloj digital, el Motorola Pulsar.

La computadora que programamos fue la M365, el clon PDP­8 de Teradyne. Escribimos en

lenguaje ensamblador y nuestros archivos fuente se guardaban en cartuchos de cinta magnética.
Aunque podíamos editar en una pantalla, el proceso era bastante complicado, por lo que utilizamos
listados impresos para la mayor parte de nuestra lectura de código y edición preliminar.

No teníamos ninguna facilidad para buscar en la base del código. No había forma de averiguar todos
los lugares donde se llamaba a una función determinada o se utilizaba una constante determinada.
Como puedes imaginar, esto fue un gran obstáculo.

Entonces, un día Tim y yo decidimos escribir un generador de referencias cruzadas. Este programa
leería nuestras cintas fuente e imprimiría una lista de cada símbolo, junto con el archivo y los números
de línea donde se usó ese símbolo.

El programa inicial fue bastante sencillo de escribir. Simplemente leyó la cinta fuente, analizó la sintaxis
del ensamblador, creó una tabla de símbolos y agregó referencias a las entradas. Funcionó muy bien,
pero fue terriblemente lento. Nos llevó más de una hora procesar nuestro Programa Operativo Maestro
(el MOP).

La razón por la que era tan lento era que manteníamos la tabla de símbolos en crecimiento en un único
búfer de memoria. Cada vez que encontramos una nueva referencia la insertamos en el búfer,
moviendo el resto del búfer hacia abajo unos pocos bytes para hacer espacio.

Tim y yo no éramos expertos en estructuras de datos y algoritmos. Nunca habíamos oído hablar de
tablas hash o búsquedas binarias. No teníamos idea de cómo hacer que un algoritmo fuera rápido.
Simplemente sabíamos que lo que estábamos haciendo era demasiado lento.

158
Machine Translated by Google

PROGRAMADORES CONTRA PERSONAS

Entonces intentamos una cosa tras otra. Intentamos poner las referencias en listas vinculadas.
Intentamos dejar espacios en la matriz y solo hacer crecer el búfer cuando los espacios se
llenaron. Intentamos crear listas vinculadas de lagunas. Probamos todo tipo de ideas locas.

Nos paramos frente a la pizarra de nuestra oficina y dibujamos diagramas de nuestras

estructuras de datos y realizamos cálculos para predecir el rendimiento. Llegábamos a la oficina
todos los días con otra idea nueva. Colaboramos como demonios.

Algunas de las cosas que probamos aumentaron el rendimiento. Algunos lo frenaron. Fue
enloquecedor. Fue entonces cuando descubrí por primera vez lo difícil que es optimizar el
software y lo poco intuitivo que es el proceso.

Al final conseguimos que el tiempo fuera inferior a 15 minutos, lo que estuvo muy cerca del
tiempo que llevó simplemente leer la cinta original. Entonces quedamos satisfechos.

PROGRAMADORES VERSUS PERSONAS

No nos convertimos en programadores porque nos guste trabajar con la gente. Por regla general,
las relaciones interpersonales nos parecen confusas e impredecibles. Nos gusta el comportamiento
limpio y predecible de las máquinas que programamos. Somos más felices cuando estamos
solos en una habitación durante horas, concentrándonos profundamente en algún
problema realmente interesante.

Bien, esa es una gran sobregeneralización y hay muchas excepciones. Hay muchos programadores
que son buenos trabajando con personas y disfrutan del desafío. Pero el promedio del grupo
todavía tiende en la dirección que dije. Nosotros, los programadores, disfrutamos de la
leve privación sensorial y de la inmersión de concentración en forma de capullo.

PROGRAMADORES VERSUS EMPLEADORES

En los años setenta y ochenta, mientras trabajaba como programador en Teradyne,

aprendí a ser realmente bueno depurando. Me encantaba el desafío y me lanzaba a los
problemas con vigor y entusiasmo. ¡Ningún insecto podría esconderse de mí por
mucho tiempo!

159
Machine Translated by Google

CAPÍTULO 12 COLABORACIÓN

¡Cuando resolví un error fue como obtener una victoria o matar al Jabberwock!
Iba a ver a mi jefe, Ken Finder, espada Vorpal en mano, y le describía apasionadamente lo
interesante que era el error. Un día, Ken finalmente estalló en frustración: “Los insectos no son
interesantes. ¡Sólo es necesario corregir los errores!”

Aprendí algo ese día. Es bueno tener pasión por lo que hacemos. Pero también es bueno estar
atento a los objetivos de las personas que le pagan.

La primera responsabilidad del programador profesional es satisfacer las necesidades de su

empleador. Eso significa colaborar con sus gerentes, analistas comerciales, evaluadores y otros
miembros del equipo para comprender en profundidad los objetivos comerciales. Esto no significa
que tengas que convertirte en un experto en negocios. Significa que debe comprender por qué está
escribiendo el código que está escribiendo y cómo la empresa que lo emplea se beneficiará de ello.

Lo peor que puede hacer un programador profesional es enterrarse felizmente en una tumba de
tecnología mientras el negocio colapsa y arde a su alrededor. ¡Tu trabajo es mantener el negocio a
flote!

Por tanto, los programadores profesionales se toman el tiempo para comprender el negocio. Hablan
con los usuarios sobre el software que están utilizando. Hablan con el personal de ventas y marketing
sobre los problemas y cuestiones que tienen. Hablan con sus gerentes para comprender los objetivos
del equipo a corto y largo plazo.

En definitiva, prestan atención al barco en el que navegan.

La única vez que me despidieron de un trabajo de programación fue en 1976. En ese momento
trabajaba para Outboard Marine Corp.. Estaba ayudando a escribir un sistema de
automatización de fábrica que utilizaba IBM System/7 para monitorear docenas de máquinas de
fundición de aluminio en el taller.

Técnicamente, este fue un trabajo desafiante y gratificante. La arquitectura del System/7 era
fascinante y el sistema de automatización de la fábrica en sí era realmente interesante.

También teníamos un buen equipo. El líder del equipo, John, era competente y estaba motivado.
Mis dos compañeros de programación fueron agradables y serviciales. teníamos un laboratorio

160
Machine Translated by Google

PROGRAMADORES CONTRA PERSONAS

dedicado a nuestro proyecto, y todos trabajamos en ese laboratorio. El socio comercial estaba
comprometido y en el laboratorio con nosotros. Nuestro gerente, Ralph, era competente,
concentrado y estaba a cargo.

Todo debería haber sido genial. El problema era yo. Estaba bastante entusiasmado con el
proyecto y con la tecnología, pero a la edad de 24 años simplemente no podía preocuparme por el
negocio o por su estructura política interna.

Mi primer error fue el primer día. Me presenté sin corbata. Yo había usado uno en mi entrevista
y había visto que todos los demás usaban corbatas, pero no logré establecer la conexión.
Entonces, en mi primer día, Ralph vino a verme y me dijo claramente: “Aquí usamos corbatas”.

No puedo decirte cuánto me molestó eso. Me molestó en un nivel profundo. Llevaba la corbata
todos los días y la odiaba. ¿Pero por qué? Sabía en lo que me estaba metiendo. Conocía las
convenciones que habían adoptado. ¿Por qué estaría tan molesto? Porque yo era un pequeño
imbécil egoísta y narcisista.

Simplemente no pude llegar a tiempo al trabajo. Y pensé que no importaba. Después de todo,
estaba haciendo "un buen trabajo". Y era cierto, estaba haciendo un muy buen trabajo escribiendo
mis programas. Era fácilmente el mejor programador técnico del equipo. Podría escribir código
más rápido y mejor que los demás. Pude diagnosticar y resolver problemas más rápido.
Sabía que era valioso. Entonces las horas y las fechas no importaban mucho.
a mí.

La decisión de despedirme se tomó un día en el que no llegué a tiempo a un hito. Aparentemente,

John nos había dicho a todos que quería una demostración de las funciones funcionales el
próximo lunes. Estoy seguro de que lo sabía, pero las fechas y los horarios simplemente no
eran importantes para mí.

Estábamos en desarrollo activo. El sistema no estaba en producción. No había ninguna razón

para dejar el sistema funcionando cuando no había nadie en el laboratorio. Debí ser el último en
salir ese viernes y aparentemente dejé el sistema en un estado que no funcionaba. El
hecho de que el lunes fuera importante simplemente no se me había quedado grabado en el
cerebro.

161
Machine Translated by Google

CAPÍTULO 12 COLABORACIÓN

Llegué una hora tarde ese lunes y vi a todos reunidos con tristeza alrededor de un sistema que
no funcionaba. John me preguntó: "¿Por qué el sistema no funciona hoy, Bob?" Mi
respuesta: "No lo sé". Y me senté a depurarlo. Todavía no tenía ni idea sobre la
demostración del lunes, pero por el lenguaje corporal de los demás me di cuenta de que algo
andaba mal. Entonces John se acercó y me susurró al oído: "¿Y si Stenberg hubiera
decidido visitarme?" Luego se alejó disgustado.

Stenberg era el vicepresidente a cargo de la automatización. Hoy en día lo llamaríamos CIO.

La pregunta no tenía ningún significado para mí. "¿Así que lo que?" Pensé. "El sistema no
está en producción, ¿cuál es el problema?"

Recibí mi primera carta de advertencia ese mismo día. Me dijo que tenía que cambiar mi
actitud inmediatamente o “el resultado será una terminación rápida”. ¡Estaba
horrorizado!

Me tomé un tiempo para analizar mi comportamiento y comencé a darme cuenta de lo que

había estado haciendo mal. Hablé con John y Ralph al respecto. Decidí cambiarme a
mí y a mi trabajo.

¡Y lo hice! Dejé de llegar tarde. Empecé a prestar atención a la política interna. Empecé
a comprender por qué John estaba preocupado por Stenberg. Empecé a ver la mala situación
en la que lo había puesto al no tener ese sistema funcionando el lunes.

Pero fue demasiado poco y demasiado tarde. La suerte estaba echada. Recibí una segunda
carta de advertencia un mes después por un error trivial que cometí. En ese momento debería
haberme dado cuenta de que las cartas eran una formalidad y que la decisión de
despedirme ya había sido tomada. Pero estaba decidido a rescatar la situación. Entonces
trabajé aún más duro.

La reunión de despido se produjo unas semanas después.

Ese día fui a casa con mi esposa embarazada de 22 años y tuve que decirle que me habían
despedido. Esa no es una experiencia que quiera repetir jamás.

162
Machine Translated by Google

PROGRAMADORES CONTRA PERSONAS

PROGRAMADORES VERSUS PROGRAMADORES

Los programadores suelen tener dificultades para trabajar en estrecha colaboración con otros programadores.

Esto conduce a algunos problemas realmente terribles.

Código propio

Uno de los peores síntomas de un equipo disfuncional es cuando cada programador construye un
muro alrededor de su código y se niega a permitir que otros programadores lo toquen.
He estado en lugares donde los programadores ni siquiera dejaban que otros
programadores vieran su código. Esta es una receta para el desastre.

Una vez fui consultor para una empresa que fabricaba impresoras de alta gama. Estas máquinas
tienen muchos componentes diferentes, como alimentadores, impresoras, apiladores, grapadoras,
cortadoras, etc. La empresa valoró cada uno de estos dispositivos de manera diferente. Los
alimentadores eran más importantes que los apiladores y nada era más importante que la impresora.

Cada programador trabajó en su dispositivo. Un tipo escribiría el código para el alimentador, otro
escribiría el código para la grapadora. Cada uno de ellos guardó su tecnología para sí mismo y evitó
que nadie más tocara su código.
La influencia política que ejercían estos programadores estaba directamente relacionada con cuánto
valoraba la empresa el dispositivo. El programador que trabajó en la impresora era inexpugnable.

Esto fue un desastre para la tecnología. Como consultor pude ver que había una duplicación masiva
en el código y que las interfaces entre los módulos estaban completamente sesgadas. Pero ningún
argumento de mi parte podría convencer a los programadores (o a la empresa) de cambiar su forma
de actuar. Después de todo, sus revisiones salariales estaban ligadas a la importancia de los
dispositivos que mantenían.

Propiedad colectiva

Es mucho mejor derribar todos los muros de propiedad del código y hacer que el equipo sea dueño
de todo el código. Prefiero equipos en los que cualquier miembro del equipo pueda consultar
cualquier módulo y realizar los cambios que considere apropiados. Quiero que el equipo sea
dueño del código, no los individuos.

163
Machine Translated by Google

CAPÍTULO 12 COLABORACIÓN

Los desarrolladores profesionales no impiden que otros trabajen en el código. No construyen muros
de propiedad en torno al código. Más bien, trabajan entre sí en la mayor parte posible del sistema.
Aprenden unos de otros trabajando juntos en otras partes del sistema.

Emparejamiento

A muchos programadores no les gusta la idea de la programación en pares. Esto me parece

extraño ya que la mayoría de los programadores se emparejarán en caso de emergencia. ¿Por qué?
Porque es claramente la forma más eficaz de solucionar el problema. Simplemente nos remonta al
viejo dicho: dos cabezas piensan mejor que una. Pero si el emparejamiento es la forma más eficiente
de resolver un problema en una emergencia, ¿por qué no es la forma más eficiente de resolver
un problema en un período?

No voy a citarles estudios, aunque hay algunos que podrían citarse. No os voy a contar ninguna
anécdota, aunque hay muchas que podría contar. Ni siquiera te voy a decir cuánto debes combinar. Lo
único que te voy a decir es que pareja de profesionales. ¿Por qué? Porque al menos para algunos
problemas es la forma más eficaz de resolverlos. Pero esa no es la única razón.

Los profesionales también hacen pareja porque es la mejor manera de compartir conocimientos
entre ellos. Los profesionales no crean silos de conocimiento. Más bien, aprenden las diferentes partes
del sistema y del negocio al asociarse entre sí. Reconocen que aunque todos los miembros del equipo
tienen una posición en la que jugar, todos los miembros del equipo también deberían poder jugar
en otra posición en caso de necesidad.

Los profesionales se emparejan porque es la mejor manera de revisar el código. Ningún sistema
debería constar de código que no haya sido revisado por otros programadores. Hay muchas
formas de realizar revisiones de código; la mayoría de ellos son terriblemente ineficientes.
La forma más eficiente y eficaz de revisar el código es colaborar en su redacción.

CEREBELOS
Tomé el tren hacia Chicago una mañana del año 2000, durante el apogeo del boom de las punto com.
Cuando bajé del tren al andén me asaltó un enorme cartel que colgaba sobre las puertas de
salida. La señal era para un conocido

164
Machine Translated by Google

CEREBELOS

empresa de software que estaba reclutando programadores. Decía: Ven a frotar los cerebelos
con los mejores.

Inmediatamente me llamó la atención la absoluta estupidez de un cartel como ese. Estos

pobres y despistados publicistas intentaban atraer a una población de programadores altamente
técnicos, inteligentes y conocedores. Éste es el tipo de personas que no sufren particularmente
bien la estupidez. Los anunciantes intentaban evocar la imagen de un intercambio de
conocimientos con otras personas muy inteligentes. Lamentablemente se referían a una parte
del cerebro, el cerebelo, que se ocupa del control de los músculos finos, no de la inteligencia.
Así que las mismas personas a las que intentaban atraer se burlaban de tan tonto error.

Pero algo más me intrigó sobre ese cartel. Me hizo pensar en un grupo de personas intentando
frotar cerebelos. Dado que el cerebelo se encuentra en la parte posterior del cerebro, la mejor
manera de frotar los cerebelos es de espaldas uno al otro. Me imaginé un equipo de
programadores en cubículos, sentados en las esquinas, dándose la espalda, mirando las pantallas
con auriculares. Así es como se frotan los cerebelos. Eso tampoco es un equipo.

Los profesionales trabajan juntos. No pueden trabajar juntos mientras están sentados en los
rincones con auriculares. Así que quiero que os sentéis alrededor de mesas, uno frente al
otro. Quiero que podáis oler el miedo del otro. Quiero que puedas escuchar los murmullos
frustrados de alguien. Quiero una comunicación fortuita, tanto verbal como corporal. Quiero que os
comuniquéis como una unidad.

Quizás crea que trabaja mejor cuando trabaja solo. Puede que sea cierto, pero no significa
que el equipo funcione mejor cuando trabajas solo.
Y, de hecho, es muy poco probable que trabaje mejor cuando trabaja solo.

Hay ocasiones en las que trabajar solo es lo correcto. Hay ocasiones en las que simplemente
es necesario pensar detenidamente en un problema. Hay ocasiones en las que la tarea es tan
trivial que sería un desperdicio tener a otra persona trabajando contigo. Pero, en general,
es mejor colaborar estrechamente con otras personas y trabajar con ellas una gran parte del
tiempo.

165
Machine Translated by Google

CAPÍTULO 12 COLABORACIÓN

CONCLUSIÓN

Quizás no nos metimos en la programación para trabajar con personas. Mala suerte para
nosotros. La programación se trata de trabajar con personas. Necesitamos trabajar con
nuestro negocio y necesitamos trabajar entre nosotros.

Lo sé, lo sé. ¿No sería fantástico si nos encerraran en una habitación con seis pantallas
gigantes, un tubo T3, un conjunto paralelo de procesadores ultrarrápidos, memoria RAM y
disco ilimitados y un suministro interminable de refrescos de cola dietéticos y chips de maíz
picantes? Por desgracia, no será así. Si realmente queremos pasar nuestros días
programando, tendremos que aprender a hablar con la gente.1

1. Una referencia a la última palabra de la película Soylent Green.

166
Machine Translated by Google

13 EQUIPOS Y PROYECTOS

¿Qué pasa si tienes muchos pequeños proyectos que hacer? ¿Cómo debería asignar
esos proyectos a los programadores? ¿Qué pasa si tienes un proyecto realmente enorme
que hacer?

167
Machine Translated by Google

CAPÍTULO 13 EQUIPOS Y PROYECTOS

¿ Se mezcla ?

He asesorado a varios bancos y compañías de seguros a lo largo de los años.

Una cosa que parecen tener en común es la extraña forma en que dividen los proyectos.

A menudo, un proyecto en un banco será un trabajo relativamente pequeño que requerirá

uno o dos programadores durante algunas semanas. Este proyecto a menudo contará
con un director de proyecto, que también gestiona otros proyectos. Contará con un analista
de negocios, que también proporcionará los requisitos para otros proyectos. Contará con
algunos programadores que también están trabajando en otros proyectos. Se asignarán
uno o dos evaluadores, y ellos también trabajarán en otros proyectos.

¿Ves el patrón? El proyecto es tan pequeño que no se puede asignar a ninguna persona
a tiempo completo. Todos trabajan en el proyecto al 50, o incluso al 25 por ciento.

Ahora bien, aquí hay una regla: no existe la mitad de una persona.

No tiene sentido decirle a un programador que dedique la mitad de su tiempo al proyecto

A y el resto de su tiempo al proyecto B, especialmente cuando los dos proyectos tienen
dos gerentes de proyecto diferentes, diferentes analistas de negocios, diferentes
programadores y diferentes evaluadores. ¿Cómo diablos puedes llamar equipo a una
monstruosidad como esa? Eso no es un equipo, es algo que salió de una licuadora Waring.

EL EQUIPO GELADO

Se necesita tiempo para que se forme un equipo. Los miembros del equipo comienzan a formar relaciones.
Aprenden a colaborar entre sí. Aprenden las peculiaridades, fortalezas y debilidades de
los demás. Finalmente, el equipo comienza a solidificarse.

Hay algo verdaderamente mágico en un equipo solidario. Pueden hacer milagros.

Se anticipan, se cubren, se apoyan y exigen lo mejor de cada uno. Hacen que las
cosas sucedan.

Un equipo consolidado suele estar formado por una docena de personas. Podrían ser
hasta veinte o tan solo tres, pero el mejor número probablemente sea alrededor de doce. El

168
Machine Translated by Google

¿ SE MEZCLA ?

El equipo debe estar compuesto por programadores, evaluadores y analistas. Y debería tener un
director de proyecto.

La proporción entre programadores, probadores y analistas puede variar mucho, pero 2:1 es un
buen número. Así, un equipo de doce personas bien integrado podría tener siete programadores,
dos evaluadores, dos analistas y un director de proyecto.

Los analistas desarrollan los requisitos y escriben pruebas de aceptación automatizadas para ellos.
Los evaluadores también escriben pruebas de aceptación automatizadas. La diferencia entre los dos
es la perspectiva. Ambos son requisitos de escritura. Pero los analistas se centran en el valor
empresarial; Los evaluadores se centran en la corrección. Los analistas escriben los casos del
camino feliz; Los evaluadores se preocupan por lo que podría salir mal y escriben la falla y el límite.
casos.

El director del proyecto realiza un seguimiento del progreso del equipo y se asegura de que el
equipo comprenda los cronogramas y las prioridades.

Uno de los miembros del equipo puede desempeñar un papel a tiempo parcial de entrenador o
maestro, con la responsabilidad de defender el proceso y las disciplinas del equipo. Actúan como
la conciencia del equipo cuando el equipo se siente tentado a salirse del proceso debido a
la presión del cronograma.

Fermentación

Se necesita tiempo para que un equipo como este resuelva sus diferencias, lleguen a un acuerdo
y realmente encajen. Podría llevar seis meses. Incluso podría llevar un año. Pero una vez que
sucede, es mágico. Un equipo consolidado planificará juntos, resolverá problemas juntos,
enfrentará problemas juntos y logrará que las cosas se hagan.

Una vez que esto sucede, es ridículo romperlo sólo porque un proyecto llega a su fin. Es
mejor mantener ese equipo unido y seguir alimentándolo con proyectos.

¿Qué fue primero, el equipo o el proyecto?

Los bancos y las compañías de seguros intentaron formar equipos en torno a proyectos. Este es
un enfoque tonto. Los equipos simplemente no pueden encajar. Los individuos están sólo en el

169
Machine Translated by Google

CAPÍTULO 13 EQUIPOS Y PROYECTOS

proyecto por un corto tiempo, y solo por un porcentaje de su tiempo, y por lo tanto nunca
aprenden cómo tratar entre sí.

Las organizaciones de desarrollo profesional asignan proyectos a equipos existentes, no

forman equipos en torno a proyectos. Un equipo consolidado puede aceptar muchos proyectos
simultáneamente y dividirá el trabajo de acuerdo con sus propias opiniones, habilidades y
capacidades. El equipo gelificado realizará los proyectos.

P ERO ¿ CÓMO LO GESTIONAS ?

Los equipos tienen velocidades.1 La velocidad de un equipo es simplemente la cantidad de

trabajo que puede realizar en un período de tiempo fijo. Algunos equipos miden su velocidad
en puntos por semana, donde los puntos son una unidad de complejidad. Desglosan las
características de cada proyecto en el que están trabajando y las estiman en puntos. Luego miden
cuántos puntos obtienen por semana.

La velocidad es una medida estadística. Un equipo puede lograr 38 puntos una semana, 42 la
siguiente y 25 la siguiente. Con el tiempo esto se promediará.

La dirección puede establecer objetivos para cada proyecto asignado a un equipo. Por ejemplo, si
la velocidad promedio de un equipo es 50 y tienen tres proyectos en los que están trabajando,
entonces la gerencia puede pedirle al equipo que divida su esfuerzo en 15, 15 y 20.

Además de contar con un equipo consolidado trabajando en sus proyectos, la ventaja de este
esquema es que, en caso de emergencia, la empresa puede decir: “El proyecto B está en crisis;
Pon el 100% de tu esfuerzo en ese proyecto durante las próximas tres semanas”.

Reasignar prioridades tan rápidamente es prácticamente imposible con los equipos que salieron
de la licuadora, pero los equipos consolidados que están trabajando en dos o tres proyectos
al mismo tiempo pueden cambiar en un instante.

EL DILEMA DEL PROPIETARIO DEL PROYECTO

Una de las objeciones al enfoque que propongo es que los propietarios del proyecto pierden cierta
seguridad y poder. Propietarios de proyectos que cuentan con un equipo dedicado a

1. [RCM2003] págs. 20­22; [COHN2006] Busque en el índice muchas referencias excelentes sobre la velocidad.

170
Machine Translated by Google

BIBLIOGRAFÍA

su proyecto puede contar con el esfuerzo de ese equipo. Saben que debido a que
formar y disolver un equipo es una operación costosa, la empresa no eliminará el equipo por
razones de corto plazo.

Por otro lado, si los proyectos se asignan a equipos consolidados y esos equipos asumen
varios proyectos al mismo tiempo, entonces la empresa es libre de cambiar las
prioridades a su antojo. Esto puede hacer que el propietario del proyecto se sienta
inseguro sobre el futuro. Los recursos de los que depende el propietario del proyecto
podrían perderse repentinamente.

Francamente, prefiero la última situación. La empresa no debe verse atada de manos por la
dificultad artificial de formar y disolver equipos. Si la empresa decide que un proyecto
tiene mayor prioridad que otro, debería poder reasignar recursos rápidamente. Es
responsabilidad del propietario del proyecto defender su proyecto.

CONCLUSIÓN

Los equipos son más difíciles de construir que los proyectos. Por lo tanto, es mejor formar
equipos persistentes que avancen juntos de un proyecto a otro y puedan asumir más de
un proyecto a la vez. El objetivo al formar un equipo es darle suficiente tiempo para
consolidarse y luego mantenerlo unido como un motor para realizar muchos proyectos.

BIBLIOGRAFÍA

[RCM2003]: Robert C. Martin, Desarrollo de software ágil: principios, patrones y prácticas,

Upper Saddle River, Nueva Jersey: Prentice Hall, 2003.

[COHN2006]: Mike Cohn, Estimación y planificación ágiles, Upper Saddle River,

Nueva Jersey: Prentice Hall, 2006.

171
Machine Translated by Google

Esta página se dejó en blanco intencionalmente.

Machine Translated by Google

14
ME NTO ANILLO ,
APRENDIZAJE Y
ARTESANÍA

Siempre me ha decepcionado la calidad de los graduados en informática. No es

que los graduados no sean brillantes o talentosos, es sólo que no se les ha
enseñado de qué se trata realmente la programación.

173
Machine Translated by Google

CAPÍTULO 14 MENTORÍA, APRENDIZAJE Y ARTESANÍA

GRADOS DE FRACASO

Una vez entrevisté a una joven que estaba cursando su maestría en informática en una
importante universidad. Estaba solicitando un puesto de pasante de verano. Le pedí que
escribiera código conmigo y ella dijo: "Realmente no escribo código".

Lea el párrafo anterior nuevamente y luego pase de este al siguiente.

Le pregunté qué cursos de programación había tomado para obtener su maestría. Ella dijo que
no había tomado ninguno.

Tal vez quieras comenzar desde el principio del capítulo sólo para asegurarte de no haber caído
en algún universo alternativo o haber despertado de un mal sueño.

En este punto, es posible que se esté preguntando cómo un estudiante de un programa de

maestría en informática puede evitar un curso de programación. Me pregunté lo mismo en
ese momento. Todavía me lo pregunto hoy.

Por supuesto, ésta es la más extrema de una serie de decepciones que he tenido al entrevistar a
graduados. No todos los graduados de informática son decepcionantes, ¡ni mucho menos!
Sin embargo, he notado que aquellos que no lo son tienen algo en común: casi todos aprendieron
a programar por sí mismos antes de ingresar a la universidad y continuaron aprendiendo
por sí mismos a pesar de la universidad.

Ahora no me malinterpretes. Creo que es posible obtener una educación excelente en una
universidad. Es sólo que también creo que es posible moverse por el sistema y obtener un
diploma, y poco más.

Y hay otro problema. Incluso los mejores programas de grado en informática no suelen
preparar al joven graduado para lo que encontrará en la industria. Esto no es tanto una
crítica a los programas de grado sino la realidad de casi todas las disciplinas.
Lo que aprendes en la escuela y lo que encuentras en el trabajo suelen ser cosas muy diferentes.

MENTORÍA

¿Cómo aprendemos a programar? Déjame contarte mi historia sobre cómo ser mentorizado.

174
Machine Translated by Google

MENTORÍA

DI GI ­ COMP I, MI PRIMERA COMPUTADORA

En 1964, mi madre me regaló una pequeña computadora de plástico cuando cumplí doce
años. Se llamaba Digi­Comp I.1. Tenía tres chanclas de plástico y seis puertas de
plástico . Podrías conectar las salidas de los flip­flops a las entradas de las puertas y .
También puedes conectar la salida de las puertas y a las entradas de los flip­flops. En
resumen, esto le permitió crear una máquina de estados finitos de tres bits.

El kit venía con un manual que te proporcionaba varios programas para ejecutar.
Programaste la máquina empujando pequeños tubos (segmentos cortos de pajitas de refresco)
en pequeñas clavijas que sobresalían de las chanclas. El manual le decía exactamente dónde
colocar cada tubo, pero no para qué hacían los tubos. ¡Esto me pareció muy frustrante!

Miré la máquina durante horas y determiné cómo funcionaba en el nivel más bajo; pero no
pude, por mi vida, descubrir cómo hacer que hiciera lo que yo quería que hiciera. La
última página del manual me decía que enviara un dólar y ellos me devolverían un manual
indicándome cómo programar la máquina.2

Envié mi dólar y esperé con la impaciencia de un niño de doce años. El día que llegó el manual
lo devoré. Era un tratado sencillo sobre álgebra booleana que cubría la factorización
básica de ecuaciones booleanas, leyes asociativas y distributivas y el teorema de DeMorgan.
El manual mostraba cómo expresar un problema en términos de una secuencia de
ecuaciones booleanas. También describió cómo reducir esas ecuaciones para que quepan en
6 puertas y.

Concebí mi primer programa. Todavía recuerdo el nombre: Puerta Computarizada del Sr.
Patternson. Escribí las ecuaciones, las reduje y las asigné a los tubos y clavijas de la máquina.
¡Y funcionó!

Escribir esas tres palabras hace un momento me provocó escalofríos. Los mismos escalofríos
que recorrieron a ese niño de doce años hace casi medio siglo. Me enganché.
Mi vida nunca volvería a ser la misma.

¿Recuerdas el momento en que funcionó tu primer programa? ¿Cambió su vida o le puso en

un camino del que no podía apartarse?

1. Hay muchos sitios web que ofrecen simuladores de este pequeño y estimulante ordenador.
2. Todavía tengo este manual. Ocupa un lugar de honor en una de mis estanterías.

175
Machine Translated by Google

CAPÍTULO 14 MENTORÍA, APRENDIZAJE Y ARTESANÍA

No lo descubrí todo por mí mismo. Fui mentoreado. Algunas personas muy amables y muy hábiles
(con quienes tengo una enorme deuda de gratitud) se tomaron el tiempo de escribir un tratado sobre
álgebra booleana accesible a un niño de doce años. Conectaron la teoría matemática con la
pragmática de la pequeña computadora de plástico y me dieron el poder para hacer que esa
computadora hiciera lo que yo quería que hiciera.

Acabo de sacar mi copia de ese fatídico manual. Lo guardo en una bolsa con cierre zip.
Sin embargo, los años han pasado factura, amarilleando las páginas y haciéndolas quebradizas. Aún
así, el poder de las palabras brilla en ellas. La elegancia de su descripción del álgebra booleana
consumió tres escasas páginas. Su recorrido paso a paso por las ecuaciones de cada uno de los
programas originales sigue siendo convincente. Fue una obra de maestría. Fue una obra que cambió la
vida de al menos un joven. Sin embargo, dudo que nunca sepa los nombres de los autores.

EL ECP­18 EN LA ESCUELA SECUNDARIA

A la edad de quince años, cuando era estudiante de primer año de secundaria, me gustaba pasar el
rato en el departamento de matemáticas. (¡Imagínese!) Un día trajeron una máquina del tamaño de una
sierra de mesa. Era una computadora educativa hecha para escuelas secundarias, llamada
ECP­18. Nuestra escuela iba a recibir una demostración de dos semanas.

Me quedé en segundo plano mientras los profesores y técnicos hablaban. Esta máquina tenía una
palabra de 15 bits (¿qué es una palabra?) y una memoria de batería de 1024 palabras. (Para
entonces ya sabía qué era la memoria de batería, pero sólo en concepto).

Cuando lo encendieron, emitió un chirrido que recordaba el despegue de un avión a reacción. Supuse
que era el tambor girando. Una vez que aceleró, todo estuvo relativamente tranquilo.

La máquina era preciosa. Básicamente era un escritorio de oficina con un maravilloso panel de
control que sobresalía de la parte superior como el puente de un acorazado. El panel de control
estaba adornado con hileras de luces que también eran pulsadores.
Sentarse en ese escritorio era como sentarse en la silla del Capitán Kirk.

Mientras observaba a los técnicos presionar esos botones, noté que se iluminaban cuando los
presionaban y que se podían presionar nuevamente para apagarlos. También noté que había otros
botones que estaban presionando; botones con nombres como depositar y ejecutar.

176
Machine Translated by Google

MENTORÍA

Los botones de cada fila se agruparon en cinco grupos de tres. Mi Digi­Comp también tenía
tres bits, por lo que podía leer un dígito octal expresado en binario. No fue un gran salto
darse cuenta de que se trataba sólo de cinco dígitos octales.

Mientras los técnicos apretaban los botones, podía oírlos murmurar para sí mismos.
Empujarían 1, 5, 2, 0, 4 en la fila del búfer de memoria mientras se decían a sí mismos
"almacenar en 204". Presionaban 1, 0, 2, 1, 3 y murmuraban: "cargaban 213 en el acumulador".
¡Había una fila de botones llamados acumulador!

Diez minutos de eso y para mi mente de quince años quedó bastante claro que el 15 significaba
almacenar y el 10 significaba cargar, que el acumulador era lo que se estaba almacenando o
cargando, y que los otros números eran los números de uno de las 1024 palabras del tambor.
(¡Así que eso es lo que es una palabra!)

Poco a poco (sin juego de palabras), mi mente ansiosa se aferró a más y más códigos de
instrucciones y conceptos. Cuando los técnicos se fueron, ya sabía los conceptos básicos de
cómo funcionaba esa máquina.

Esa tarde, durante una sala de estudio, entré sigilosamente al laboratorio de matemáticas
y comencé a jugar con la computadora. ¡Había aprendido hace mucho tiempo que es
mejor pedir perdón que permiso! Activé un pequeño programa que multiplicaría el acumulador
por dos y sumaría uno. ¡Puse un 5 en el acumulador, ejecuté el programa y vi 138 en el acumulador!
¡Había funcionado!

Activé varios otros programas simples como ese y todos funcionaron según lo planeado. ¡Yo
era el amo del universo!

Días después me di cuenta de lo estúpido y afortunado que había sido. Encontré una hoja de
instrucciones tirada en el laboratorio de matemáticas. Mostraba todas las diferentes instrucciones
y códigos de operación, incluidos muchos que no había aprendido al observar a los técnicos. Me
alegré de haber interpretado correctamente los que conocía y me emocioné con los demás. Sin
embargo, una de las nuevas instrucciones fue HLT. Dio la casualidad de que la instrucción de
detenerse era una palabra compuesta exclusivamente de ceros. Y dio la casualidad de que había
puesto una palabra compuesta exclusivamente de ceros al final de cada uno de mis programas
para poder cargarla en el acumulador y borrarla. La idea de detenerme simplemente no se me
había ocurrido. ¡Simplemente pensé que el programa se detendría cuando estuviera terminado!

177
Machine Translated by Google

CAPÍTULO 14 MENTORÍA, APRENDIZAJE Y ARTESANÍA

Recuerdo que en un momento me senté en el laboratorio de matemáticas y vi a uno de

los profesores luchar para que un programa funcionara. Estaba intentando escribir
dos números en decimal en el teletipo adjunto y luego imprimir la suma. Cualquiera que
haya intentado escribir un programa como este en lenguaje de máquina en una
minicomputadora sabe que está lejos de ser trivial. Tienes que leer los caracteres, convertirlos
a dígitos, luego a binarios, agregarlos, volver a convertirlos a decimales y codificarlos
nuevamente en caracteres. Y créanme, ¡es mucho peor cuando ingresas el programa
en binario a través del panel frontal!

Vi cómo detuvo su programa y luego lo ejecutó hasta que se detuvo.

(¡Oh! ¡Esa es una buena idea!) Este punto de interrupción primitivo le permitió examinar el
contenido de los registros para ver qué había hecho su programa. Lo recuerdo
murmurando: "¡Vaya, eso fue rápido!" ¡Chico, tengo noticias para él!

No tenía idea de cuál era su algoritmo. Ese tipo de programación todavía era mágica para
mí. Y nunca me habló mientras yo miraba por encima de su hombro. De hecho, nadie
me habló de esta computadora. Creo que me consideraban una molestia que debía ser
ignorada, revoloteando por el laboratorio de matemáticas como una polilla. Baste decir
que ni el alumno ni los profesores habían desarrollado un alto grado de habilidad social.

Al final consiguió que su programa funcionara. Fue increíble verlo. Escribía lentamente
los dos números porque, a pesar de su protesta anterior, esa computadora no era rápida
(piense en leer palabras consecutivas de un tambor giratorio en 1967). Cuando
presionó regresar después del segundo número, la computadora parpadeó ferozmente
por un momento y luego comenzó a imprimir el resultado. Tomó aproximadamente un
segundo por dígito. Imprimió todo menos el último dígito, parpadeó aún más ferozmente
durante cinco segundos y luego imprimió el último dígito y se detuvo.

¿Por qué esa pausa antes del último dígito? Nunca lo descubrí. Pero me hizo darme cuenta
de que el enfoque de un problema puede tener un efecto profundo en el usuario. Aunque el
programa produjo la respuesta correcta, todavía había algo mal en ella.

Esto fue tutoría. Ciertamente no fue el tipo de tutoría que hubiera esperado. Hubiera sido
bueno si uno de esos profesores me hubiera tomado bajo su protección y hubiera trabajado
conmigo. Pero no importó, porque estaba observando
ellos y aprendiendo a un ritmo vertiginoso.

178
Machine Translated by Google

MENTORÍA

MENTORÍA NO CONVENCIONAL

Les conté esas dos historias porque describen dos tipos muy diferentes de tutoría, ninguno
de los cuales es el tipo que la palabra suele implicar. En el primer caso aprendí de los
autores de un manual muy bien escrito. En el segundo caso, aprendí observando a
personas que intentaban activamente ignorarme. En ambos casos el conocimiento
adquirido fue profundo y fundamental.

Por supuesto, también tuve otros tipos de mentores. Estaba un amable vecino que
trabajaba en Teletype y que me trajo a casa una caja con 30 relés telefónicos para jugar.
¡Déjame decirte, dale a un muchacho algunos relés y un transformador de tren eléctrico y podrá
conquistar el mundo!

Estaba el amable vecino que era operador aficionado y que me mostró cómo usar un multímetro
(que rápidamente rompí). Estaba el dueño de la tienda de artículos de oficina que me
permitió entrar y “jugar” con su costosa calculadora programable. Estaba la oficina
de ventas de Digital Equipment Corporation que me permitió entrar y “jugar” con sus PDP­8
y PDP­10.

Luego estaba el gran Jim Carlin, un programador de BAL que me salvó de ser despedido
de mi primer trabajo de programación al ayudarme a depurar un programa Cobol que
estaba mucho más allá de mi alcance. Me enseñó a leer volcados de memoria y a
formatear mi código con líneas en blanco, filas de estrellas y comentarios apropiados.
Él me dio mi primer empujón hacia la artesanía. Lamento no haber podido devolverle el favor
cuando el descontento del jefe recayó sobre él un año después.

Pero, francamente, eso es todo. Simplemente no había tantos programadores experimentados

a principios de los años setenta. En todos los demás lugares donde trabajé, era mayor. No
había nadie que me ayudara a descubrir qué era la verdadera programación profesional. No
hubo ningún modelo a seguir que me enseñara cómo comportarme o qué valorar. Esas
cosas las tuve que aprender por mí mismo y no fue nada fácil.

NOCKS DUROS

Como le dije antes, de hecho, me despidieron de ese trabajo de automatización de fábrica en

1976. Aunque era técnicamente muy competente, no había aprendido a prestar atención
al negocio ni a los objetivos comerciales. Fechas y plazos previstos

179
Machine Translated by Google

CAPÍTULO 14 MENTORÍA, APRENDIZAJE Y ARTESANÍA

nada para mi. Me olvidé de una gran demostración el lunes por la mañana, dejé el sistema
roto el viernes y llegué tarde el lunes con todos mirándome enojados.

Mi jefe me envió una carta advirtiéndome que tenía que hacer cambios inmediatamente o me
despedirían. Esta fue una importante llamada de atención para mí. Reevalué mi vida y mi
carrera y comencé a realizar algunos cambios significativos en mi comportamiento, algunos
de los cuales usted ha leído en este libro. Pero fue demasiado poco y demasiado tarde.
El impulso iba en la dirección equivocada y pequeñas cosas que antes no habrían importado
se volvieron significativas. Entonces, aunque lo intenté con todas mis fuerzas, finalmente
me escoltaron fuera del edificio.

No hace falta decir que no es divertido llevar ese tipo de noticias a una esposa embarazada
y una hija de dos años. Pero me levanté y llevé algunas lecciones de vida poderosas a mi
siguiente trabajo, que ocupé durante quince años y que formó la verdadera base de mi carrera
actual.

Al final, sobreviví y prosperé. Pero tiene que haber una manera mejor. Habría sido mucho
mejor para mí si hubiera tenido un verdadero mentor, alguien que me enseñara los pros y
los contras. Alguien a quien podría haber observado mientras lo ayudaba con pequeñas
tareas, y que revisaría y guiaría mis primeros trabajos. Alguien que actúe como modelo a
seguir y me enseñe valores y reflejos adecuados. Un sensei. Un maestro. Un mentor.

APRENDIZAJE
¿Qué hacen los médicos? ¿Crees que los hospitales contratan graduados en medicina y los
meten en quirófanos para realizar cirugías cardíacas en su primer día de trabajo? De
Por supuesto que no.

La profesión médica ha desarrollado una disciplina de tutoría intensa instalada en

el ritual y lubricada con la tradición. La profesión médica supervisa las universidades
y se asegura de que los graduados tengan la mejor educación.
Esa educación implica cantidades aproximadamente iguales de estudio en el aula y actividad
clínica en hospitales que trabajan con profesionales.

Al graduarse, y antes de poder obtener la licencia, los médicos recién nombrados deben pasar
un año en práctica supervisada y capacitación llamada pasantía.

180
Machine Translated by Google

APRENDIZAJE

Se trata de una intensa formación en el puesto de trabajo. El pasante está rodeado de modelos a
seguir y maestros.

Una vez completada la pasantía, cada una de las especialidades médicas requiere de tres a cinco
años más de práctica supervisada y capacitación conocida como residencia. El residente gana
confianza al asumir responsabilidades cada vez mayores sin dejar de estar rodeado y supervisado por
médicos experimentados.

Muchas especialidades requieren entre uno y tres años más de beca en la que el estudiante continúa
con una formación especializada y una práctica supervisada.

Y luego son elegibles para realizar sus exámenes y obtener la certificación de la junta.

Esta descripción de la profesión médica era algo idealizada y probablemente tremendamente

inexacta. Pero el hecho es que cuando hay mucho en juego, no enviamos a los graduados a una sala,
les echamos carne de vez en cuando y esperamos que salgan cosas buenas. Entonces, ¿por qué
hacemos esto en el software?

Es cierto que hay relativamente pocas muertes causadas por errores de software. Pero hay pérdidas
monetarias importantes. Las empresas pierden enormes cantidades de dinero debido a la formación
inadecuada de sus desarrolladores de software.

De alguna manera, la industria del desarrollo de software ha tenido la idea de que los
programadores son programadores y que una vez que te gradúas puedes codificar. De hecho, no es
nada raro que las empresas contraten a niños recién salidos de la escuela, los formen “equipos” y les
pidan que construyan los sistemas más críticos. ¡Es una locura!

Los pintores no hacen esto. Los fontaneros no. Los electricistas no. ¡Diablos, ni siquiera creo que

los cocineros de comida rápida se comporten de esta manera! Me parece que las empresas que
contratan graduados en informática deberían invertir más en su formación de lo que McDonalds
invierte en sus servidores.

No nos engañemos pensando que esto no importa. Hay mucho en juego. Nuestra civilización

funciona con software. Es un software que mueve y manipula la información que impregna nuestra
vida diaria. El software controla los motores, las transmisiones y los frenos de nuestros
automóviles. Mantiene nuestros saldos bancarios, nos envía nuestros

181
Machine Translated by Google

CAPÍTULO 14 MENTORÍA, APRENDIZAJE Y ARTESANÍA

facturas y acepta nuestros pagos. El software lava nuestra ropa y nos dice la hora.
Pone imágenes en la televisión, envía mensajes de texto, hace llamadas telefónicas y
nos entretiene cuando estamos aburridos. Está en todas partes.

Dado que confiamos a los desarrolladores de software todos los aspectos de nuestras vidas,
desde los más pequeños hasta los más trascendentales, sugiero que un período razonable de
capacitación y práctica supervisada no es inapropiado.

APRENDIZAJE DE SOFTWARE
Entonces, ¿cómo debería la profesión del software incorporar a los jóvenes graduados a
las filas del profesionalismo? ¿Qué pasos deben seguir? ¿Qué desafíos deberían
enfrentar? ¿Qué objetivos deberían alcanzar? Trabajemos al revés.

Maestros

Se trata de programadores que han tomado la iniciativa en más de un proyecto de

software importante. Por lo general, tendrán más de 10 años de experiencia y habrán
trabajado en varios tipos diferentes de sistemas, lenguajes y sistemas operativos.
Saben cómo liderar y coordinar varios equipos, son diseñadores y arquitectos
competentes y pueden codificar círculos alrededor de todos los demás sin sudar. Se
les ofrecieron puestos directivos, pero los rechazaron, huyeron después de aceptarlos
o los integraron en su función principalmente técnica. Mantienen ese rol técnico
leyendo, estudiando, practicando, haciendo y enseñando. Es a un maestro a quien
la empresa asignará la responsabilidad técnica de un proyecto. Piensa, "Scotty".

Oficiales

Se trata de programadores capacitados, competentes y enérgicos. Durante este período

de su carrera aprenderán a trabajar bien en equipo y a convertirse en líderes de equipo.
Conocen la tecnología actual, pero normalmente carecen de experiencia con muchos
sistemas diversos. Suelen conocer un idioma, un sistema, una plataforma; pero están
aprendiendo más. Los niveles de experiencia varían ampliamente entre sus filas, pero
el promedio es de unos cinco años. En el extremo opuesto de ese promedio
tenemos maestros florecientes; en el lado cercano tenemos aprendices recientes.

182
Machine Translated by Google

APRENDIZAJE

Los oficiales están supervisados por maestros u otros oficiales de mayor rango.
A los jóvenes oficiales rara vez se les permite autonomía. Su trabajo está estrechamente
supervisado. Su código es examinado. A medida que ganan experiencia, crece la autonomía.
La supervisión se vuelve menos directa y más matizada. Con el tiempo, pasa a la revisión
por pares.

Aprendices/Pasantes

Los graduados comienzan sus carreras como aprendices. Los aprendices no tienen autonomía.
Están muy estrechamente supervisados por oficiales. Al principio no asumen ninguna
tarea, simplemente brindan asistencia a los oficiales. Este debería ser un momento de
programación de pareja muy intensa. Aquí es cuando se aprenden y refuerzan las
disciplinas. Aquí es cuando se crea la base de los valores.

Los oficiales son los maestros. Se aseguran de que los aprendices conozcan los principios y
patrones de diseño, las disciplinas y los rituales. Los oficiales enseñan TDD, refactorización,
estimación, etc. Asignan lecturas, ejercicios y prácticas a los aprendices; revisan su
progreso.

El aprendizaje debería durar un año. En ese momento, si los oficiales están dispuestos a aceptar al
aprendiz en sus filas, harán una recomendación a los maestros. Los maestros deben examinar al
aprendiz tanto mediante entrevista como revisando sus logros. Si los maestros están de acuerdo,
entonces el aprendiz se convierte en oficial.

LA REALIDAD
Una vez más, todo esto es idealizado e hipotético. Sin embargo, si cambias los nombres y
entrecierras los ojos ante las palabras, te darás cuenta de que no es tan diferente de la forma en
que esperamos que funcionen las cosas ahora. Los graduados son supervisados por jóvenes líderes
de equipo, quienes son supervisados por líderes de proyectos, etc. ¡El problema es que, en la
mayoría de los casos, esta supervisión no es técnica! En la mayoría de las empresas no
existe ningún tipo de supervisión técnica. Los programadores obtienen aumentos y eventuales
ascensos porque, bueno, eso es exactamente lo que se hace con los programadores.

La diferencia entre lo que hacemos hoy y mi programa ideal de aprendizaje es el enfoque en la

enseñanza técnica, la capacitación, la supervisión y la revisión.

183
Machine Translated by Google

CAPÍTULO 14 MENTORÍA, APRENDIZAJE Y ARTESANÍA

La diferencia es la noción misma de que los valores profesionales y la perspicacia técnica deben
enseñarse, cultivarse, mimarse y cultivarse. Lo que falta en nuestro enfoque estéril actual es la
responsabilidad de los mayores de enseñar a los
joven.

ARTESANÍA

Así que ahora estamos en condiciones de definir esta palabra: artesanía. ¿Qué es exactamente?
Para entenderlo, veamos la palabra artesano. Esta palabra trae a la mente habilidad y calidad.
Evoca experiencia y competencia. Un artesano es alguien que trabaja con rapidez, pero sin prisas,
que ofrece presupuestos razonables y cumple los compromisos. Un artesano sabe cuándo
decir que no, pero se esfuerza por decir que sí. Un artesano es un profesional.

La artesanía es la mentalidad de los artesanos. La artesanía es un meme que contiene valores,

disciplinas, técnicas, actitudes y respuestas.

¿Pero cómo adoptan los artesanos este meme? ¿Cómo logran esta mentalidad?

El meme de artesanía se pasa de una persona a otra. Lo enseñan los mayores a los jóvenes. Se
intercambia entre pares. Se observa y se vuelve a aprender, como los mayores observan a los
jóvenes. La artesanía es un contagio, una especie de virus mental.
Lo captas observando a los demás y permitiendo que el meme se arraigue.

CONVENCER A LA GENTE

No se puede convencer a la gente para que sea artesano. No puedes convencerlos de que
acepten el meme de la artesanía. Los argumentos son ineficaces. Los datos son intrascendentes.
Los estudios de casos no significan nada. La aceptación de un meme no es tanto una decisión
racional sino emocional. Esto es algo muy humano .

Entonces, ¿cómo lograr que la gente adopte el meme de la artesanía? Recuerda que un meme es
contagioso, pero sólo si se puede observar. Entonces haces que el meme sea observable.
Actúas como un modelo a seguir. Primero te conviertes en un artesano y dejas que tu habilidad
se muestre. Luego deja que el meme haga el resto del trabajo.

184
Machine Translated by Google

CONCLUSIÓN

CONCLUSIÓN

La escuela puede enseñar la teoría de la programación informática. Pero la escuela no

enseña ni puede enseñar la disciplina, la práctica y la habilidad de ser un artesano. Esas
cosas se adquieren a través de años de tutela y tutoría personal. Es hora de que aquellos de
nosotros en la industria del software afrontemos el hecho de que guiar al próximo grupo
de desarrolladores de software hacia la madurez nos corresponderá a nosotros, no a las universidades.
Es hora de que adoptemos un programa de aprendizaje, pasantías y orientación a largo plazo.

185
Machine Translated by Google

Esta página se dejó en blanco intencionalmente.

Machine Translated by Google

HERRAMIENTA A

En 1978, estaba trabajando en Teradyne en el sistema de prueba telefónica que describí anteriormente. El
sistema tenía aproximadamente 80 KSLOC de ensamblador M365. Mantuvimos el código fuente en cintas.

Las cintas eran similares a esos cartuchos de cinta estéreo de 8 pistas que eran tan populares
en los años 70. La cinta era un bucle sin fin y la unidad de cinta sólo podía moverse en una dirección.
Los cartuchos venían en longitudes de 10', 25', 50' y 100'.
Cuanto más larga era la cinta, más tardaba en “rebobinarse”, ya que la unidad de cinta simplemente
tenía que moverla hacia adelante hasta encontrar el “punto de carga”. Una cinta de 100' tardó cinco
minutos en llegar al punto de carga, por lo que elegimos la longitud de nuestras cintas con prudencia.1

1. Estas cintas sólo se podían mover en una dirección. Entonces, cuando había un error de lectura, no había forma de que la unidad
de cinta realizara una copia de seguridad y leyera nuevamente. Tenías que detener lo que estabas haciendo, enviar la cinta de
regreso al punto de carga y luego comenzar de nuevo. Esto sucedió dos o tres veces por día. Los errores de escritura también
eran muy comunes y la unidad no tenía forma de detectarlos. Así que siempre escribíamos las cintas en pares y luego
comprobamos los pares cuando terminábamos. Si una de las cintas era mala, inmediatamente hacíamos una copia. Si ambos
estaban mal, lo cual era muy poco frecuente, empezábamos toda la operación de nuevo. Así era la vida en los años 70.

187
Machine Translated by Google

APÉNDICE A HERRAMIENTAS

Lógicamente, las cintas estaban subdivididas en archivos. Podrías tener tantos archivos en una cinta como
quepan. Para encontrar un archivo, cargó la cinta y luego avanzó un archivo a la vez hasta encontrar el
que deseaba. Mantuvimos una lista del directorio del código fuente en la pared para saber cuántos
archivos omitir antes de llegar al que queríamos.

Había una copia maestra de 100' de la cinta del código fuente en un estante del laboratorio.
Estaba etiquetado como Maestro. Cuando queríamos editar un archivo, cargábamos la
cinta fuente maestra en una unidad y una cinta en blanco de 10' en otra. Saltaríamos el Maestro
hasta que llegamos al archivo que necesitábamos. Luego copiaríamos ese archivo en la cinta borrador.
Luego “rebobinábamos” ambas cintas y volvíamos a colocar el Master en el estante.

Había un directorio especial del Maestro en un tablón de anuncios del laboratorio.

Una vez que habíamos hecho las copias de los archivos que necesitábamos editar, poníamos un alfiler
de color en el tablero al lado del nombre de ese archivo. ¡Así es como revisamos los archivos!

Editamos las cintas en una pantalla. Nuestro editor de texto, ED­402, fue realmente muy bueno. Era
muy similar a vi. Leíamos una “página” de la cinta, editábamos el contenido y luego escribíamos
esa página y leíamos la siguiente. Una página normalmente tenía 50 líneas de código. No podías
mirar hacia adelante en la cinta para ver las páginas que estaban por venir, y no podías mirar hacia atrás
en la cinta para ver las páginas que habías editado. Entonces usamos listados.

De hecho, marcaríamos nuestros listados con todos los cambios que quisiéramos realizar y
luego editaríamos los archivos de acuerdo con nuestras marcas. ¡Nadie escribió ni
modificó código en la terminal! Eso fue un suicidio.

Una vez que se realizaron los cambios en todos los archivos que necesitábamos editar, fusionaríamos esos
archivos con el maestro para crear una cinta funcional. Esta es la cinta que usaríamos para ejecutar
nuestras compilaciones y pruebas.

Una vez que terminábamos las pruebas y estábamos seguros de que nuestros cambios funcionaban,
mirábamos el tablero. Si no hubiera pines nuevos en el tablero, simplemente volveríamos a etiquetar
nuestra cinta de trabajo como Maestro y quitaríamos los pines del tablero. Si había nuevos pines en el
tablero, los quitábamos y le pagábamos la cinta de trabajo a la persona cuyos pines todavía estaban en
el tablero. Tendrían que hacer la fusión.

188
Machine Translated by Google

CONTROL DE CÓDIGO FUENTE

Éramos tres y cada uno tenía su propio color de pin, por lo que nos resultó fácil saber quién tenía qué
archivos extraídos. Y como todos trabajábamos en el mismo laboratorio y hablábamos entre nosotros todo el

tiempo, manteníamos el estado del tablero en nuestras cabezas. Por lo general, el tablero era redundante y

muchas veces no lo usábamos.

HERRAMIENTAS

Hoy en día, los desarrolladores de software tienen una amplia gama de herramientas para
elegir. No vale la pena involucrarse con la mayoría, pero hay algunos con los que todo
desarrollador de software debe estar familiarizado. Este capítulo describe mi conjunto de
herramientas personal actual. No he realizado un estudio completo de todas las demás
herramientas que existen, por lo que esto no debe considerarse una revisión exhaustiva. Esto es justo lo que us

CONTROL DE CÓDIGO FUENTE

Cuando se trata de control del código fuente, las herramientas de código abierto suelen ser la
mejor opción. ¿Por qué? Porque están escritos por desarrolladores, para desarrolladores. Las
herramientas de código abierto son lo que los desarrolladores escriben por sí mismos cuando
necesitan algo que funcione.

Hay bastantes sistemas de control de versiones “empresariales” comerciales y costosos

disponibles. Encuentro que estos no se venden tanto a desarrolladores sino a gerentes,
ejecutivos y "grupos de herramientas". Su lista de características es impresionante y
convincente. Desafortunadamente, a menudo no tienen las funciones que los desarrolladores
realmente necesitan. El principal de ellos es la velocidad.

UNA “E NPR ISE ” ” SISTEMA DE CONTROL DE FUENTE

Puede ser que su empresa haya invertido una pequeña fortuna en un sistema de control de
código fuente “empresarial”. Si es así, mi más sentido pésame. Probablemente sea
políticamente inapropiado que usted ande diciéndole a todo el mundo: "El tío Bob dice que no lo
usemos". Sin embargo, existe una solución fácil.

Puede verificar su código fuente en el sistema "empresarial" al final de cada iteración (una vez
cada dos semanas aproximadamente) y usar uno de los sistemas de código abierto.

189
Machine Translated by Google

APÉNDICE A HERRAMIENTAS

en medio de cada iteración. Esto mantiene a todos contentos, no viola ninguna regla corporativa y
mantiene alta su productividad.

BLOQUEO PESIMISTO VERSUS OPTIMISTA

El bloqueo pesimista parecía una buena idea en los años 80. Después de todo, la forma más sencilla de
gestionar los problemas de actualizaciones simultáneas es serializarlas. Así que si soy
editando un archivo, será mejor que no. De hecho, el sistema de pasadores de colores que
utilicé a finales de los años 70 era una forma de bloqueo pesimista. Si había un pin en un
archivo, no editaste ese archivo.

Por supuesto, el bloqueo pesimista tiene sus problemas. Si bloqueo un archivo y luego me voy de
vacaciones, todos los demás que quieran editar ese archivo se quedarán atascados. De hecho, incluso
si mantengo el archivo bloqueado durante uno o dos días, puedo retrasar a otras personas que
necesitan realizar cambios.

Nuestras herramientas han mejorado mucho en la combinación de archivos fuente que se han editado
simultáneamente. En realidad, es bastante sorprendente cuando lo piensas. Las herramientas analizan los dos
archivos diferentes y el antepasado de esos dos archivos, y luego aplican múltiples estrategias para
descubrir cómo integrar los cambios simultáneos.
Y hacen un trabajo bastante bueno.

Así que la era del bloqueo pesimista ha terminado. Ya no necesitamos bloquear archivos cuando los
revisamos. De hecho, no nos molestamos en revisar archivos individuales en absoluto. Simplemente
revisamos todo el sistema y editamos los archivos que necesitamos.

Cuando estemos listos para verificar nuestros cambios, realizamos una operación de "actualización".
Esto nos dice si alguien más ingresó el código antes que nosotros, fusiona automáticamente la mayoría de
los cambios, encuentra conflictos y nos ayuda a realizar las fusiones restantes. Luego confirmamos el
código combinado.

Tendré mucho que decir sobre el papel que desempeñan las pruebas automatizadas y la
integración continua con respecto a este proceso más adelante en este capítulo. Por el momento
digamos que nunca registramos código que no pase todas las pruebas.
Nunca jamás.

190
Machine Translated by Google

CONTROL DE CÓDIGO FUENTE

CVS/SVN

El antiguo sistema de control de fuente en espera es CVS. Fue bueno para su época, pero
se ha vuelto un poco obsoleto para los proyectos de hoy. Aunque es muy bueno para
manejar archivos y directorios individuales, no es muy bueno para cambiar el nombre de
archivos o eliminar directorios. Y el ático. . . . Bueno, cuanto menos se hable de eso, mejor.

Subversion, por otro lado, funciona muy bien. Le permite verificar todo el sistema en una sola
operación. Puede actualizar, fusionar y confirmar fácilmente.
Siempre y cuando no se ramifique, los sistemas SVN son bastante sencillos de
administrar.

Derivación

Hasta 2008 evité todas las formas de ramificación excepto las más simples. Si un
desarrollador creaba una rama, esa rama debía volver a la línea principal antes del final de
la iteración. De hecho, era tan austero respecto a la ramificación que rara vez se hacía
en los proyectos en los que participaba.

Si está utilizando SVN, sigo pensando que es una buena política. Sin embargo, hay algunas
herramientas nuevas que cambian el juego por completo. ellos son los distribuidos
Sistemas de control de fuentes. git es mi favorito de los sistemas de control de fuente
distribuida. Déjame contarte sobre esto.

git

Comencé a usar git a finales de 2008 y desde entonces ha cambiado todo en la forma en
que uso el control del código fuente. Comprender por qué esta herramienta cambia
tanto las reglas del juego está más allá del alcance de este libro. Pero comparar la Figura
A­1 con la Figura A­2 debería valer algunas de las palabras que no voy a incluir aquí.

La Figura A­1 muestra algunas semanas de desarrollo del proyecto FitNesse mientras
estaba controlado por SVN. Puedes ver el efecto de mi austera regla de no
ramificarse. Simplemente no nos ramificamos. En cambio, realizamos actualizaciones,
fusiones y confirmaciones muy frecuentes en la línea principal.

191
Machine Translated by Google

APÉNDICE A HERRAMIENTAS

Figura A­1 FITNESSE bajo subversión

La imagen de la Figura A­2 muestra algunas semanas de desarrollo en el mismo

proyecto usando git. Como puede ver, nos estamos ramificando y fusionando por
todas partes. Esto no se debió a que relajara mi política de no sucursales; más bien, simplemente

192
Machine Translated by Google

CONTROL DE CÓDIGO FUENTE

Figura A­2 FITNESSE bajo git

se convirtió en la forma obvia y más conveniente de trabajar. Los desarrolladores

individuales pueden crear ramas de muy corta duración y luego fusionarlas entre sí a su
antojo.

193
Machine Translated by Google

APÉNDICE A HERRAMIENTAS

Observe también que no puede ver una línea principal verdadera. Eso es porque no hay ninguno.
Cuando usas git no existe un repositorio central o una línea principal.
Cada desarrollador guarda su propia copia del historial completo del proyecto en su máquina
local. Ellos registran y retiran esa copia local y luego la fusionan con otras según sea necesario.

Es cierto que mantengo un repositorio dorado especial en el que envío todas las versiones y compilaciones
provisionales. Pero llamar a este repositorio la línea principal sería perder el sentido. En realidad, es
solo una instantánea conveniente de todo el historial que cada desarrollador mantiene localmente.

Si no entiendes esto, está bien. git es una especie de confusión al principio. Tienes que acostumbrarte
a cómo funciona. Pero te diré esto: git y herramientas similares son lo que parece el futuro del control
del código fuente.

DITOR IDE/E
Como desarrolladores, pasamos la mayor parte de nuestro tiempo leyendo y editando código. Las
herramientas que utilizamos para este propósito han cambiado mucho a lo largo de las décadas.
Algunas son inmensamente poderosas y otras han cambiado poco desde los años 70.

VI

Uno pensaría que los días en que se usaba vi como editor de desarrollo principal habrían
quedado atrás. Hoy en día existen herramientas que superan con creces a vi y a otros editores de
texto simples similares. Pero la verdad es que vi ha disfrutado de un importante resurgimiento en
popularidad debido a su simplicidad, facilidad de uso, velocidad y flexibilidad. Puede que Vi
no sea tan potente como Emacs o Eclipse, pero sigue siendo un editor rápido y potente.

Dicho esto, ya no soy un usuario avanzado de vi. Hubo un día en que me conocían como un vi “dios”,
pero esos días ya pasaron. Utilizo vi de vez en cuando si necesito realizar una edición rápida de un
archivo de texto. Incluso lo he usado recientemente para realizar un cambio rápido en un archivo fuente
de Java en un entorno remoto. Pero la cantidad de codificación verdadera que he realizado en vi en
los últimos 10 años es extremadamente pequeña.

194
Machine Translated by Google

IDE/EDITOR

E MACS

Emacs sigue siendo uno de los editores más potentes que existen y probablemente lo
seguirá siendo durante las próximas décadas. El modelo de ceceo interno lo garantiza.
Como herramienta de edición de uso general, nada se le acerca. Por otro lado, creo que
Emacs realmente no puede competir con los IDE de propósito específico que ahora
dominan. La edición de código no es un trabajo de edición de propósito general.

En los años 90 yo era un fanático de Emacs. No consideraría usar nada más. Los editores
de apuntar y hacer clic de la época eran juguetes ridículos que ningún desarrollador podía
tomar en serio. Pero a principios de la década del 2000 conocí IntelliJ, mi IDE actual de
elección, y nunca miré hacia atrás.

EC LI PSE / I NTE L LI J

Soy un usuario de IntelliJ. Me encanta. Lo uso para escribir Java, Ruby, Clojure,
Scala, Javascript y muchos otros. Esta herramienta fue escrita por programadores
que entienden lo que necesitan los programadores al escribir código. A lo largo de los
años, rara vez me han decepcionado y casi siempre me han complacido.

Eclipse es similar en potencia y alcance a IntelliJ. Los dos son simplemente pasos
agigantados por encima de Emacs cuando se trata de editar Java. Hay otros IDE en esta
categoría, pero no los mencionaré aquí porque no tengo experiencia directa con ellos.

Las características que distinguen a estos IDE de herramientas como Emacs son las
formas extremadamente poderosas en las que le ayudan a manipular el código. En IntelliJ,
por ejemplo, puedes extraer una superclase de una clase con un solo comando.
Puede cambiar el nombre de variables, extraer métodos y convertir la herencia en
composición, entre muchas otras funciones excelentes.

Con estas herramientas, la edición de código ya no se trata tanto de líneas y caracteres

como de manipulaciones complejas. En lugar de pensar en los siguientes caracteres y líneas
que debe escribir, piense en las siguientes transformaciones que debe realizar. En
resumen, el modelo de programación es notablemente diferente y altamente productivo.

195
Machine Translated by Google

APÉNDICE A HERRAMIENTAS

Por supuesto, este poder tiene un costo. La curva de aprendizaje es alta y el tiempo de preparación
del proyecto no es insignificante. Estas herramientas no son livianas. Requieren muchos recursos
informáticos para funcionar.

TEXTO E
TextMate es potente y ligero. No puede realizar las maravillosas manipulaciones que pueden realizar
IntelliJ y Eclipse. No tiene el potente motor lisp ni la biblioteca de Emacs. No tiene la velocidad y
fluidez de vi. Por otro lado, la curva de aprendizaje es pequeña y su funcionamiento intuitivo.

Utilizo TextMate de vez en cuando, especialmente para C++ ocasionalmente. Usaría Emacs para
un proyecto grande de C++, pero estoy demasiado oxidado para molestarme con Emacs para las
pequeñas tareas cortas de C++ que tengo.

PUEDO SEGUIMIENTO

Actualmente estoy usando Pivotal Tracker. Es un sistema elegante y sencillo de utilizar. Encaja muy
bien con el enfoque ágil/iterativo. Permite que todas las partes interesadas y desarrolladores se
comuniquen rápidamente. Estoy muy satisfecho con ello.

Para proyectos muy pequeños, a veces he usado Lighthouse. Es muy rápido y fácil de configurar y
usar. Pero no se acerca al poder de Tracker.

También he usado simplemente una wiki. Los wikis están bien para proyectos internos. Le permiten
configurar cualquier esquema que desee. No estás obligado a seguir un proceso determinado o una
estructura rígida. Son muy fáciles de entender y utilizar.

A veces, el mejor sistema de seguimiento de problemas de todos es un juego de tarjetas y un

tablero de anuncios. El tablero de anuncios está dividido en columnas como "Pendientes", "En curso" y
"Listo". Los desarrolladores simplemente mueven las tarjetas de una columna a la siguiente cuando
sea necesario. De hecho, este puede ser el sistema de seguimiento de problemas más común
utilizado por los equipos ágiles en la actualidad.

La recomendación que hago a los clientes es comenzar con un sistema manual como el tablón de
anuncios antes de comprar una herramienta de seguimiento. Una vez que hayas dominado el

196
Machine Translated by Google

CONSTRUCCIÓN CONTINUA

sistema manual, tendrá el conocimiento necesario para seleccionar la herramienta adecuada. De

hecho, la elección adecuada puede ser simplemente seguir utilizando el sistema manual.

LOS ERRORES CUENTAN

Los equipos de desarrolladores ciertamente necesitan una lista de cuestiones en las que trabajar. Esos
problemas incluyen nuevas tareas y funciones, así como errores. Para cualquier equipo de
tamaño razonable (de 5 a 12 desarrolladores), el tamaño de esa lista debe ser de decenas a cientos. No miles.

Si tienes miles de errores, algo anda mal. Si tiene miles de funciones y/o tareas, algo anda mal. En
general, la lista de problemas debe ser relativamente pequeña y, por lo tanto, manejable con una
herramienta liviana como wiki, Lighthouse o Tracker.

Existen algunas herramientas comerciales que parecen ser bastante buenas. He visto clientes
usarlos pero no he tenido la oportunidad de trabajar con ellos directamente. No me opongo a
herramientas como ésta, siempre y cuando el número de cuestiones siga siendo pequeño y
manejable. Cuando las herramientas de seguimiento de problemas se ven obligadas a rastrear miles
de problemas, la palabra "seguimiento" pierde significado. Se convierten en “basureros de
problemas” (y a menudo también huelen a basurero).

CONSTRUCCIÓN CONTINUA

Últimamente he estado usando Jenkins como mi motor de construcción continua. Es liviano, simple y
casi no tiene curva de aprendizaje. Lo descargas, lo ejecutas, realizas algunas configuraciones
rápidas y sencillas y ya estás en funcionamiento. Muy lindo.

Mi filosofía sobre la construcción continua es simple: conéctelo a su sistema de control de código

fuente. Cada vez que alguien ingresa el código, debería compilarlo automáticamente y luego informar el
estado al equipo.

El equipo simplemente debe mantener la construcción funcionando en todo momento. Si la

construcción falla, debería ser un evento de "detener las imprentas" y el equipo debería reunirse para
resolver rápidamente el problema. Bajo ninguna circunstancia se debe permitir que la falla persista
durante un día o más.

197
Machine Translated by Google

APÉNDICE A HERRAMIENTAS

Para el proyecto FitNesse, hago que todos los desarrolladores ejecuten el script de compilación continua antes de

comprometerse. La construcción tarda menos de 5 minutos, por lo que no es oneroso.

Si hay problemas, los desarrolladores los resuelven antes de la confirmación. Por lo tanto, la
construcción automática rara vez tiene problemas. La fuente más común de fallas en la compilación
automática resulta ser problemas relacionados con el entorno, ya que mi entorno de
compilación automática es bastante diferente de los entornos de desarrollo del
desarrollador.

HERRAMIENTAS DE PRUEBA UNIDAD

Cada idioma tiene su propia herramienta de prueba unitaria particular. Mis favoritos son JUnit

para Java, rspec para Ruby, NUnit para .Net, Midje para Clojure y CppUTest para C y C++.

Cualquiera que sea la herramienta de prueba unitaria que elija, hay algunas características básicas que

todas deberían admitir.

1. La ejecución de las pruebas debe ser rápida y sencilla. Si esto se hace a través de

Los complementos IDE o las herramientas simples de línea de comandos son irrelevantes, siempre que los

desarrolladores puedan ejecutar esas pruebas a su antojo. El gesto para ejecutar las pruebas debería ser trivial.

Por ejemplo, ejecuto mis pruebas CppUTest escribiendo comando­M en TextMate.

Tengo este comando configurado para ejecutar mi archivo MAKE , que ejecuta automáticamente las pruebas

e imprime un informe de una línea si todas las pruebas pasan. Tanto JUnit como rspec son compatibles

con IntelliJ, por lo que todo lo que tengo que hacer es presionar un botón. Para NUnit, uso el complemento

Resharper para obtener el botón de prueba.

2. La herramienta debe brindarle una indicación visual clara de pasa/falla. No importa si se trata de una barra

verde gráfica o de un mensaje de consola que dice "Todas las pruebas pasan". El punto es que usted debe

poder decir que todas las pruebas pasaron rápidamente y sin ambigüedades. Si tiene que leer un informe

de varias líneas, o peor aún, comparar el resultado de dos archivos para saber si las pruebas pasaron,

entonces no superó este punto.

3. La herramienta debería brindarle una indicación visual clara del progreso. No importa si se trata de un medidor

gráfico o una cadena de puntos, siempre y cuando puedas decir que todavía se están logrando progresos y

que las pruebas no se han estancado ni abortado.

198
Machine Translated by Google

HERRAMIENTAS DE PRUEBA DE COMPONENTES

4. La herramienta debe disuadir a los casos de prueba individuales de comunicarse con

entre sí. JUnit hace esto creando una nueva instancia de la clase de prueba para cada
método de prueba, evitando así que las pruebas utilicen variables de instancia para
comunicarse entre sí. Otras herramientas ejecutarán los métodos de prueba en orden

aleatorio para que no pueda depender de que una prueba preceda a otra. Cualquiera
que sea el mecanismo, la herramienta debería ayudarle a mantener sus pruebas
independientes entre sí. Las pruebas dependientes son una trampa profunda en la que no querrás caer.

5. La herramienta debería facilitar la redacción de pruebas. JUnit hace esto proporcionando una API
conveniente para realizar afirmaciones. También utiliza atributos de Java y reflexión para distinguir las
funciones de prueba de las funciones normales. Esto permite que un buen IDE identifique
automáticamente todas sus pruebas, eliminando la molestia de cablear conjuntos y crear listas de
pruebas propensas a errores.

HERRAMIENTAS DE PRUEBA DE COMPONENTES

Estas herramientas sirven para probar componentes a nivel API. Su función es garantizar que el
comportamiento de un componente se especifique en un lenguaje que la empresa y el personal
de control de calidad puedan comprender. De hecho, el caso ideal es cuando los analistas de negocios y
el control de calidad puedan escribir esa especificación utilizando la herramienta.

LA DEFINICIÓN DE HECHO

Más que cualquier otra herramienta, las herramientas de prueba de componentes son el medio por el
cual especificamos lo que significa hecho . Cuando los analistas de negocios y el control de calidad
colaboran para crear una especificación que define el comportamiento de un componente, y
cuando esa especificación se puede ejecutar como un conjunto de pruebas que pasan o fallan, entonces
hecho adquiere un significado muy inequívoco: "Todas las pruebas pasan".

APTITUD

Mi herramienta de prueba de componentes favorita es FitNesse. Escribí una gran parte y soy el principal
responsable. Entonces es mi bebé.

FitNesse es un sistema basado en wiki que permite a los analistas de negocios y especialistas en control
de calidad escribir pruebas en un formato tabular muy simple. Estas tablas son similares a Parnas.

199
Machine Translated by Google

APÉNDICE A HERRAMIENTAS

tablas tanto en forma como en intención. Las pruebas se pueden ensamblar rápidamente en
suites, y las suites se pueden ejecutar a voluntad.

FitNesse está escrito en Java pero puede probar sistemas en cualquier idioma porque se comunica con un

sistema de prueba subyacente que puede escribirse en cualquier idioma. Los lenguajes admitidos incluyen

Java, C#/.NET, C, C++, Python, Ruby, PHP, Delphi y otros.

Hay dos sistemas de prueba que subyacen a FitNesse: Fit y Slim. Fit fue escrito por Ward Cunningham y fue la

inspiración original para FitNesse y similares.

Slim es un sistema de prueba mucho más simple y portátil que es el preferido por los usuarios de FitNesse

en la actualidad.

OTRAS HERRAMIENTAS

Conozco varias otras herramientas que podrían clasificarse como herramientas de prueba de componentes.

• RobotFX es una herramienta desarrollada por ingenieros de Nokia. Utiliza una tabla similar.

formato para FitNesse, pero no está basado en wiki. La herramienta simplemente se ejecuta en archivos planos

preparados con Excel o similar. La herramienta está escrita en Python pero puede probar sistemas en

cualquier idioma utilizando puentes adecuados.

• Green Pepper es una herramienta comercial que tiene varias similitudes con FitNesse. Está basado en la

popular wiki de confluencia.

• Cucumber es una herramienta de texto plano impulsada por un motor Ruby, pero capaz de

probando muchas plataformas diferentes. El lenguaje de Cucumber es el estilo popular Dado/Cuando/Entonces.

• JBehave es similar a Cucumber y es el padre lógico de Cucumber. Es

escrito en Java.

HERRAMIENTAS DE PRUEBA DE INTEGRACIÓN

Las herramientas de prueba de componentes también se pueden utilizar para muchas pruebas de integración,

pero no son apropiadas para las pruebas que se realizan a través de la interfaz de usuario.

En general, no queremos realizar muchas pruebas a través de la interfaz de usuario porque las interfaces de usuario

son notoriamente volátiles. Esa volatilidad hace que las pruebas que pasan por la interfaz de usuario sean muy frágiles.

200
Machine Translated by Google

UML/MDA

Dicho esto, hay algunas pruebas que deben pasar por la interfaz de usuario; las más importantes son
las pruebas de la interfaz de usuario. Además, se deben realizar algunas pruebas de un extremo a otro de
todo el sistema ensamblado, incluida la interfaz de usuario.

Las herramientas que más me gustan para las pruebas de UI son Selenium y Watir.

UML/MDA
A principios de los años 90 tenía muchas esperanzas de que la industria de herramientas CASE provocaría
un cambio radical en la forma de trabajar de los desarrolladores de software. Mientras miraba hacia el
futuro desde aquellos días embriagadores, pensé que a estas alturas todo el mundo estaría codificando
diagramas en un nivel superior de abstracción y que el código textual sería cosa del pasado.

Vaya, me equivoqué. No sólo no se ha cumplido este sueño, sino que cada intento de avanzar en esa
dirección ha fracasado estrepitosamente. No es que no existan herramientas y sistemas que demuestren el
potencial; lo que pasa es que esas herramientas simplemente no hacen realidad el sueño y casi nadie parece
querer utilizarlas.

El sueño era que los desarrolladores de software pudieran dejar atrás los detalles del código textual
y los sistemas de creación en un lenguaje de diagramas de nivel superior. De hecho, según dice el sueño, es
posible que no necesitemos programadores en absoluto. Los arquitectos podrían crear sistemas
completos a partir de diagramas UML. Los motores, enormes, geniales y poco comprensivos
con la difícil situación de los simples programadores, transformarían esos diagramas en código
ejecutable. Ese era el gran sueño de la Arquitectura Dirigida por Modelos (MDA).

Desafortunadamente, este gran sueño tiene un pequeño defecto. MDA asume que el problema es el código.
Pero el código no es el problema. Nunca ha sido el problema.
El problema es el detalle.

LOS DETALLES

Los programadores son administradores de detalles. Eso es lo que hacemos. Especificamos el

comportamiento de los sistemas hasta el más mínimo detalle. Usamos lenguajes textuales para esto
(código) porque los lenguajes textuales son notablemente convenientes (considere el inglés, por ejemplo).

201
Machine Translated by Google

APÉNDICE A HERRAMIENTAS

¿Qué tipo de detalles gestionamos?

¿Conoces la diferencia entre los dos caracteres \n y \r? El primero, \n, es un avance de línea. El
segundo, \r, es un retorno de carro. ¿Qué es un carruaje?

En los años 60 y principios de los 70, uno de los dispositivos de salida más comunes para las
computadoras era el teletipo. El modelo ASR332 fue el más común.

Este dispositivo constaba de un cabezal de impresión que podía imprimir diez caracteres por segundo.
El cabezal de impresión estaba compuesto por un pequeño cilindro con los caracteres grabados en
él. El cilindro giraba y se elevaba de modo que el carácter correcto estuviera frente al papel, y luego
un pequeño martillo golpeaba el cilindro contra el papel. Había una cinta entintada entre el cilindro y el
papel, y la tinta se transfería al papel con la forma del personaje.

El cabezal de impresión iba sobre un carro. Con cada carácter, el carro se movía un espacio hacia la
derecha, llevándose consigo el cabezal de impresión. Cuando el carro llegó al final de la línea de 72
caracteres, tenía que devolverlo explícitamente enviando los caracteres de retorno de carro (\r = 0 ´
0D); de lo contrario, el cabezal de impresión continuaría imprimiendo caracteres en la columna
72. convirtiéndolo en un desagradable rectángulo negro.

Por supuesto, eso no fue suficiente. Devolver el carro no elevó el papel a la siguiente línea. Si
devolvió el carro y no envió un carácter de avance de línea (\n = 0 ´ 0A), entonces la nueva
línea se imprimiría encima de la línea anterior.

Por lo tanto, para un teletipo ASR33 la secuencia de fin de línea era “\r\n”. En realidad, había que
tener cuidado con eso, ya que el carruaje podría tardar más de 100 ms en regresar. Si envió “\n\r”, es
posible que el siguiente carácter se imprima cuando el carro regrese, creando así un carácter borroso
en el medio de la línea. Para estar seguros, a menudo rellenamos la secuencia de final de línea
con uno o dos caracteres rubout3 (0 ´ FF).

2. [Link]
3. Los personajes de Rubout fueron muy útiles para editar cintas de papel. Por convención, se ignoraron los caracteres borrados.
Su código, 0 ´ FF, significaba que se perforaron todos los agujeros en esa fila de la cinta. Esto significaba que cualquier
personaje podía convertirse en un borrado golpeándolo demasiado. Por lo tanto, si cometió un error al escribir su
programa, puede retroceder y presionar borrar, luego continuar escribiendo.

202
Machine Translated by Google

UML/MDA

En los años 70, cuando los teletipos comenzaron a dejar de usarse, los sistemas operativos como
UNIX acortaron la secuencia de final de línea a simplemente '\n'. Sin embargo, otros sistemas
operativos, como DOS, continuaron usando la convención '\r\n'.

¿Cuándo fue la última vez que tuvo que lidiar con archivos de texto que utilizan la convención
“incorrecta”? Me enfrento a este problema al menos una vez al año. Dos archivos fuente idénticos
no se comparan y no generan sumas de verificación idénticas porque usan extremos de línea
diferentes. Los editores de texto no ajustan correctamente las palabras ni colocan doble espacio en el
texto porque los finales de línea son "incorrectos". Los programas que no esperan líneas en blanco
fallan porque interpretan '\r\n' como dos líneas. Algunos programas reconocen '\r\n' pero no reconocen
'\n\r'. Etcétera.

A eso me refiero con detalle. ¡Intenta codificar la horrible lógica para ordenar los finales de línea en
UML!

SIN ESPERANZA , SIN CAMBIO

La esperanza del movimiento MDA era que se pudiera eliminar una gran cantidad de detalles
utilizando diagramas en lugar de códigos. Hasta ahora, esa esperanza ha resultado desesperada.
Resulta que simplemente no hay muchos detalles adicionales incrustados en el código que puedan
eliminarse mediante imágenes. Es más, las imágenes contienen sus propios detalles accidentales.
Las imágenes tienen su propia gramática, sintaxis, reglas y limitaciones. Entonces, al final, la
diferencia en el detalle es un lavado.

La esperanza de MDA era que los diagramas demostraran estar en un nivel de abstracción más
alto que el código, al igual que Java está en un nivel más alto que el ensamblador. Pero, una vez más,
hasta ahora esa esperanza ha resultado infundada. La diferencia en el nivel de abstracción es,
en el mejor de los casos, mínima.

Y, finalmente, digamos que un día alguien inventa un lenguaje diagramado

verdaderamente útil. No serán arquitectos los que dibujarán esos diagramas, serán programadores.
Los diagramas simplemente se convertirán en el nuevo código, y se necesitarán
programadores para dibujar ese código porque, al final, todo se trata de detalles, y son los
programadores quienes gestionan esos detalles.

203
Machine Translated by Google

APÉNDICE A HERRAMIENTAS

CONCLUSIÓN

Las herramientas de software se han vuelto mucho más poderosas y abundantes desde que comencé a
programar. Mi conjunto de herramientas actual es un subconjunto simple de esa colección de animales. yo uso git
para control de código fuente, Tracker para gestión de problemas, Jenkins para compilación continua, IntelliJ
como mi IDE, XUnit para pruebas y FitNesse para pruebas de componentes.

Mi máquina es una Macbook Pro, Intel Core i7 a 2,8Ghz, con pantalla mate de 17 pulgadas, 8GB de
ram, 512GB SSD, con dos pantallas extra.

204
Machine Translated by Google

ÍNDICE

A Pruebas de aceptación automatizadas, 97–99

Pruebas de Garantía de calidad automatizada, 8
aceptación Evitación, 125
automatizadas, 97–99
comunicación y 97 integración continua y, B
104­105 Callejones sin salida, 125­126
definición de, 94 el Bossavit, Laurent, 83
papel del desarrollador en, 100– Juego de bolos, 83
101 trabajo adicional y, 99 Ramificación, 191
GUI y, 103–105 Recuento de errores, 197

negociación y, 101–102 Objetivos empresariales, 154

agresión pasiva y, 101–102 sincronización

de, 99–100 pruebas do

unitarias y, 102–103 cafeína, 122

escritores de, 99–100 certeza, 74
Roles adversarios, 20­23 Control

Estimación de afinidad, 140­141 de código, 189–194

Ambigüedad, en los requisitos, 92–94 propiedad, 157

Disculpas, 6 3 a.m., 53–54

Aprendices, 183 preocupación, 54–55

Aprendizaje, 180–184 Dojo de codificación, 83–87

Argumentos, en reuniones, 120­121 Colaboración, 14, 151–160

Arrogancia, 16 Propiedad colectiva, 157­158

205
Machine Translated by Google

ÍNDICE

Compromiso(s), 41–46 Reuniones de demostración, 120

control y, 44 Diseño, desarrollo basado en pruebas y,

disciplina y, 47–50 76–77
estimación y, 132 Patrones de diseño,
expectativas y, 45 12 principios de diseño,
identificación, 43–44 12 detalles, 201–
implícito, 134–135 203 Desarrollo. ver desarrollo
importancia de, 132 impulsado por pruebas (TDD)
falta de, 42–43 Desacuerdos, en reuniones, 120–121
presión y, 146 Compromiso
Comunicación de disciplina y, 47–50 crisis,

pruebas de aceptación y, 147

97 presión y, 148 de Desconexión, 64

requisitos, 89–94 Documentación, 76

Pruebas de componentes Dominio, conocimiento de, 15

en la estrategia de prueba, 110–111 “Hecho”, definición, 67, 94–97
herramientas para, 199–200 Enfoque de “no hacer daño”, 5– 10
Conflicto, en reuniones, 120–121 para funcionar, 5–
Construcción continua, 197–198 8 para estructurar,

Integración continua, 104­105 8–10 Conducir, 64

Aprendizaje continuo, 13
E
Control, compromiso y, 44
Eclipse, 195–196
Coraje, 75–76
Emacs, 195
Artesanía, 184
Identificación
Aporte creativo, 59–60, 123
del empleador(es), 15
Disciplina de crisis, 147
programadores vs., 153–156
pepino, 200
Estimación
Cliente, identificación con, 15
afinidad, 140–141
CVS, 191
ansiedad,
Tiempo de ciclo, en desarrollo
92 compromiso y, 132
basado en pruebas, 72
definición de, 132–133
D ley de grandes números y, 141
Plazos nominal, 136
entrega falsa y, 67 optimista, 135–136
esperanza y, 65 PERT y, 135–138
tiempo extra y, 66 pesimista, 136
prisa y, 65–66 probabilidad y, 133 de
Depuración, 60–63 tareas, 138–141
Tasa de inyección de defectos, 75 trivariado, 141

206
Machine Translated by Google

ÍNDICE

Expectativas, compromiso y, 45 Entrada, creatividad, 59–60, 123

Experiencia, ampliación, 87. Integración, continua, 104–105
Pruebas de integración
F
en la estrategia de pruebas, 111–112
Fallo, grados de, 174. herramientas para, 200–201
entrega falsa, 67 IntelliJ, 195­196
Fitness, 199–200
Pasantes, 183
Flexibilidad, 9
Interrupciones, 57–58
Zona de flujo, 56–58
Seguimiento de problemas, 196–197
Dedos voladores, 139
Reuniones de planificación de iteraciones, 119.
Enfoque, 121–123
Reuniones retrospectivas de iteración, 120.
Función, en el enfoque de “no
hacer daño”, 5–8 j
Compórtate, 200
GRAMO

Oficiales, 182–183
Gaillot, Emmanuel, 83
Equipo gelificado, 162­164 k
Git, 191­194 Kata, 84–85
Goles, 20­23, 118 Conocimiento
Interfaces gráficas de usuario (GUI), 103– del dominio, 15
105 mínimo, 12
Pimiento verde, 200 ética laboral y, 11­13
Grenning, James, 139
l
GUI, 103–105
Tardanza, 65–67
h Ley de los grandes números, 141
Golpes duros, 179–180 Aprendizaje, ética laboral y, 13
Ayuda, 67–70 "Vamos", 42
dar, 68 Lindstrom, Lowell, 140
tutoría y, 69–70 presión Bloqueo, 190
y, 148–149 recibir, 68–69
METRO

“Esperanza”, 42 Pruebas exploratorias manuales, en estrategia

de prueba, 112–113
Esperando, plazos y, 65
Maestría, 182
Humildad, 16
MDA, 201–203
I Agenda de
IDE/editor, 194 reuniones en, 118
Identificación, con empleador/ argumentos y desacuerdos en, 120–121
cliente, 15
Compromisos implícitos, 134­135 en declive, 117

207
Machine Translated by Google

ÍNDICE

Demostración de reuniones PERT (Evaluación de Programas y

(continuación) , Técnica de revisión), 135­138

120 metas Estimación pesimista, 136

dentro, 118 planificación de Bloqueo pesimista, 190

iteraciones, 119 iteraciones Actividad física, 123

retrospectivas, Planificación del póquer, 139­140

120 salidas, 118 Práctica

de pie, 119 gestión del tiempo y, 116–121 antecedentes sobre, 80–83

Tutoría, 14–15, 69–70, 174–180 ética, 87

Refactorización despiadada, 9 experiencia y, 87 tiempo

Líos, 126–127, 146 de respuesta y, 82–83 ética laboral y,

Métodos, 12 13–14

Arquitectura basada en modelos (MDA), Precisión, prematura, en los

201­203 requisitos, 91–92
Enfoque muscular, 123 Preparación, 52–55
música, 57 Presión

evitando, 145–147
norte
limpieza y, 146
“Necesidad”, 42
compromisos y, 146
Negociación, pruebas de aceptación y, 101– comunicación y, 148 manejo,
102.
147–149 ayuda y, 148–
Estimación nominal, 136
149 desorden y, 146
No profesional, 2
pánico y, 147–148

oh Inversión de prioridades,
125 Probabilidad, 133
Código abierto, 87
Profesionalismo, 2
Estimación optimista, 135­136
Programadores
Bloqueo optimista, 190
empleadores vs.,
Resultados, mejores posibles, 20­23
Horas extras, 66 153–156 personas vs., 153–

Código propio, 157 158 programadores vs.,

157 Propuesta, proyecto, 31–
Propiedad colectiva, 157­158
32
PAG

Ritmo, 63–64 q
Emparejamiento, 58, 148–149, Control de calidad (QA)
158 Pánico, 147– automatizado, 8
148 Pasión, 154 como captadores de
Agresión pasiva, 28–30, 101–102 Personas, errores, 6 como caracterizadores,
programadores vs., 153–158 Problemas 108–109 ideal de, como no encontrar
personales, 54–55 problemas, 108–109

208
Machine Translated by Google

ÍNDICE

problemas encontrados por, 6–7 t

como especificadores, Estimación de tareas, 138­141

108 como miembro del equipo, 108 Equipos y trabajo en equipo, 24–
30 solidificados,
R 162–164 gestión de, 164
Randori, 86­87 agresión pasiva y, 28–30
La lectura, como aporte creativo, 59 preservación, 163
Recarga, 122–123 proyecto iniciado, 163–164
Reputación, 5 dilema del propietario del proyecto con,
Requisitos de 164–165
comunicación de, 89–94 intentando y, 26–28
ansiedad de estimación y, 92 velocidad de, 164
ambigüedad tardía en, 92–94 Beneficios del desarrollo impulsado por
precisión prematura en, 91–92 pruebas (TDD) de,
incertidumbre y, 91–92 74–77 certeza y, 74
Responsabilidad, 2 a coraje y, 75–76 tiempo
5 disculpas y 6 de ciclo, 72 debut
enfoque de “no hacer daño” y 5 a 10 de, 71–72 tasa de
función y 5 a 8 inyección de defectos y, 75
estructura y 8 a 10 ética definición de, 7–8
de trabajo y 10 a 16 diseño y, 76– 77
RobotFX, 200 documentación y, 76
Roles, adversarios, 20­23 interrupciones y, 58 tres
Apresurándose, 34–35, 65–66 leyes de, 73–74 lo que
no es, 77–78
S
Santana, Carlos, 83 Aceptación de
“Debería”, 42 pruebas automatizada,
Ducha, 64 97–99 comunicación y, 97
Simplicidad, 34 integración continua y, 104–105
Dormir, 122 definición

Control de código fuente, 189–194 de, 94 rol del

En juego, 23­24 desarrollador en, 100–101 trabajo
Reuniones de pie, 119 adicional y, 99
Estructura GUI y, 103–105
en el enfoque de “no hacer daño”, 8–10 negociación y, 101–102
flexibilidad y, 9 agresión pasiva y, 101–102
importancia de, 8 sincronización de, 99–
SVN, 191­194 100 pruebas unitarias y,
Pruebas del sistema, en estrategia de prueba, 112. 102–103 escritores de, 99–100

209
Machine Translated by Google

ÍNDICE

Pirámide de automatización Estimaciones trivariadas, 141

de pruebas (continuación) , 109–113 Tiempo de respuesta, práctica y 82–

componente de 83

la estrategia de prueba, 110–111

Ud.
herramientas para, 199–200
UML, 201
importancia de, 7–8
Incertidumbre, requisitos y, 91–92 Tutoría no
integración en
convencional, 179. Véase también tutoría
la estrategia de prueba, 111–112
Pruebas unitarias
herramientas para, 200–

201 exploratorio manual, 112–113

pruebas de aceptación y, 102–103 en
estructura y, 9
estrategia de prueba, 110
sistema, 112
herramientas para, 198–199
unidad

pruebas de aceptación y, 102–103 en V

estrategia de prueba, 110
VI, 194
herramientas para, 198–199
Compañero de texto, 196 W.
Thomas, Dave, 84
Alejándose, 64
Código de las 3 a.m., 53–54 Wasa, 85–86
Tiempo, depuración, 63 Delphi de banda ancha, 138­141
Gestión del tiempo “Deseo”, 42
evitación y, 125 callejones Ética de trabajo, 10–16
sin salida y, 125–126 ejemplos de, colaboración y, 14 aprendizaje
116 enfoque y, 121– continuo y, 13 conocimiento y, 11–13
123 reuniones y, 116–121
tutoría y, 14–15 práctica y, 13–
líos y, 126–127 inversión de 14
prioridad y, 125 recarga y,

122–123 técnica de “tomates” para, Código de preocupación, 54–55

124 Bloqueo del escritor, 58–60

Cansancio, 53–54 Y

Técnica de gestión del tiempo “tomates”, "Sí"

124 costo de, 30–34

Herramientas, 189 aprender a decir, 46–50

210
Machine Translated by Google

Esta página se dejó en blanco intencionalmente.