Programador Limpio

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 sobre 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 considere un profesional no solo necesita saber, sino también seguir para
hacer crecer la joven profesión del desarrollo de software”.
—Mark Gaertner
Desarrollador senior de software
itagile GmbH
www.itagile.de
www.shino.de
“Algunos libros técnicos inspiran y enseñan; un poco de placer y diversión. Rara vez un libro técnico
hace las cuatro cosas. Robert Martin siempre me ha gustado y The Clean Coder no es una excepción.
Lea, aprenda y viva las lecciones de este libro y podrá llamarse a sí mismo un profesional del software”.
—George Bullock
Gerente sénior de programas
Microsoft Corp.
“Si un título en informática tuviera 'lectura obligatoria para después de graduarse', sería este. En el
mundo real, tu código incorrecto no desaparece cuando termina el semestre, no obtienes una A por
maratón de codificación la noche anterior a la fecha de 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 camino hacia la profesionalidad. . . y hace un trabajo notablemente entretenido”.
—Jeff Overbey
Universidad de Illinois en UrbanaChampaign
“Clean Coder es mucho más que un conjunto de reglas o pautas. Contiene sabiduría y conocimiento
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 te consideras un profesional del software,
necesitas este libro”.
—RL Bogetti
Diseñador líder del sistema
Salud de Baxter
www.RLBogetti.com
Esta página se dejó en blanco intencionalmente
El codificador limpio
La serie de Robert C. Martin
Visite informit.com/martinseries para obtener una lista completa de las publicaciones disponibles.
La serie
Robert
líderes, C. Martin
analistas enstá
de dirigida
egocios y ag erentes
desarrolladores
de software,
que desean equipo
aumentar sus
habilidades y competencia al nivel de un maestro artesano. La serie contiene
libros que guían a los profesionales de 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.
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
Muchas de las designaciones utilizadas por los fabricantes y vendedores para distinguir sus productos se reclaman como marcas
comerciales. Donde esas designaciones aparecen en este libro, y el editor estaba al tanto de un reclamo de marca registrada, las
designaciones se han impreso con letras mayúsculas iniciales o en mayúsculas.
El autor y el editor se han ocupado de la preparación de este libro, pero no ofrecen garantías expresas o implícitas de ningún tipo y
no asumen responsabilidad alguna por errores u omisiones. No se asume ninguna responsabilidad por daños incidentales o consecuentes en
relación con o que surjan del uso de la información o los programas contenidos en este documento.
La editorial ofrece excelentes descuentos en este libro cuando se pide 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:
Ventas corporativas y gubernamentales de EE.
UU. (800) 3823419
corpsales@pearsontechgroup.com
Para ventas fuera de los Estados Unidos, comuníquese con:
Ventas internacionales
internacional@pearson.com
Visítenos en la Web: www.informit.com/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. cm.
Incluye referencias bibliográficas e indice.
ISBN 0137081073 (pbk.: papel alcalino)
1. Programación de computadoras—Aspectos morales y éticos. 2. Programadores de
computadoras—Ética profesional. I. Título.
2011 QA76.9.M65M367
005.1092—dc22 2011005962
Copyright © 2011 Pearson Educación, 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 el permiso del editor antes de cualquier reproducción, almacenamiento en un sistema de recuperación o transmisión prohibida en
cualquier forma o por cualquier medio, ya sea electrónico, mecánico, fotocopiado, grabación o similar. Para obtener información sobre
permisos, escriba a:
Pearson Educación, Inc.
Departamento de Derechos y Contratos 501
Boylston Street, Suite 900 Boston, MA
02116 Fax: (617)
6713447
ISBN13: 9780137081073
ISBN10: 0137081073
Texto impreso en los Estados Unidos en papel reciclado en RR Donnelley en Crawfordsville, Indiana.
Primera impresión, mayo de 2011
Entre 1986 y 2000 trabajé de cerca con Jim Newkirk, un colega de Teradyne. Él y yo
compartimos la pasión por la programación y el código limpio.
Pasaríamos noches, tardes y fines de semana juntos jugando con diferentes estilos de
programación y técnicas de diseño. Estábamos continuamente tramando ideas de
negocios. Eventualmente formamos Object Mentor, Inc., juntos.
Aprendí muchas cosas de Jim mientras trabajábamos juntos en nuestros esquemas.
Pero uno de los más importantes fue su actitud de ética de trabajo; era algo que me
esforzaba por emular. Jaime es un profesional. Estoy orgulloso de haber trabajado con él
y de llamarlo mi amigo.
CONTENIDO
Prefacio XIII
Prefacio xix
Expresiones de gratitud XXIII
Sobre el Autor xxix
En la portada xxi
Introducción de requisitos previos 1
Capítulo 1 Profesionalismo 7
Cuidado con lo que pides 8
Asumir la responsabilidad 8
Primero, no hacer daño 11
Ética de trabajo dieciséis
Bibliografía 22
Capitulo 2 decir no 23
Roles adversarios 26
Altas estacas 29
Ser un “jugador de equipo” 30
El costo de decir sí 36
código imposible 41
ix
CONTENIDO
Capítulo 3 diciendo que sí 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 de escritor 64
depuración 66
Mide tu propio ritmo 69
llegar tarde 71
Ayuda 73
Bibliografía 76
Capítulo 5 Desarrollo basado en pruebas 77
El jurado está adentro 79
Las tres leyes de TDD 79
Lo que no es TDD 83
Bibliografía 84
Capítulo 6 Practicando 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
Prueba de aceptacion 100
Conclusión 111
Capítulo 8 Estrategias de prueba 113
El control de calidad no debería encontrar nada 114
X
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
EnfoqueManá 127
Tiempo Boxeo y Tomates 130
Evitación 131
Callejones sin salida 131
Pantanos, 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
Presión de manejo 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 ¿Combina? 167
168
Conclusión 171
Bibliografía 171
xi
CONTENIDO
Capítulo 14 Tutoría, aprendizaje y artesanía 173
Grados de falla 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
xi
PREFACIO
Has elegido este libro, así que asumo que eres un profesional del software. Eso es bueno; yo también. Y
ya que tengo su atención, déjenme decirles por qué elegí este libro.
Todo comienza 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.
Conoces el tipo; nos sentamos en una granja de cubículos en un edificio de tres pisos, los directores y
superiores tenían oficinas privadas, y llevar a todos los que necesitabas a la misma sala para una reunión
tomó una semana más o menos.
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 lograr que compraran nuestro producto. Eso significaba que teníamos que presentar
una solicitud ante el gobierno federal antes de un plazo determinado, pasar una auditoría de evaluación antes
de otra fecha e ir al mercado en una tercera fecha.
XIII
PREFACIO
Una y otra vez nuestra dirección nos recalcó 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 podían
registrarse el primer día, todos se registrarían con otra persona y estaríamos fuera del negocio.
Era el tipo de entorno en el que algunas personas se quejan y otras señalan que “la presión
hace diamantes”.
Fui gerente técnico de proyectos, ascendido de desarrollo. Mi responsabilidad era poner en
marcha el sitio web el día de la puesta en marcha, para que los clientes potenciales pudieran
descargar información y, lo que es más importante, formularios de inscripción. Mi socio en el
esfuerzo fue el gerente de proyectos orientado al negocio, 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 corporaciones de Estados Unidos, probablemente haya
visto la aversión al trabajo, las acusaciones y las acusaciones que son completamente naturales.
Nuestra empresa tenía una solución interesante para ese problema con Joe y conmigo.
Un poco como Batman y Robin, era nuestro trabajo 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 la ruta crítica y luego eliminaríamos todos los obstáculos posibles de esa ruta
crítica. Si alguien necesitaba software; iríamos a buscarlo. Si "les encantaría" configurar el
firewall pero "Dios mío, es hora de mi hora del almuerzo", les compraríamos el almuerzo. 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.
Tenemos cosas hechas.
Es un poco exagerado decir que pateamos sillas, gritamos y gritamos, pero usamos
todas las técnicas que teníamos a mano para hacer las cosas, inventamos algunas nuevas en
el camino y lo hicimos de una manera ética. manera de la que estoy orgulloso hasta el día de hoy.
xiv
PREFACIO
Pensé en mí mismo como un miembro del equipo, no por encima de saltar para escribir una declaración
SQL o hacer un pequeño emparejamiento para sacar el código por la puerta. En ese momento, pensaba
en Joe de la misma manera, como un miembro del equipo, no por encima.
Finalmente me di cuenta de que Joe no compartía esa opinión. Ese fue un día muy triste para mí.
Era viernes a la 1:00 pm; el sitio web se puso en marcha muy temprano el lunes siguiente.
habíamos terminado. *HECHO*. Todos los sistemas estaban listos; estábamos listos. Reuní a todo el
equipo técnico para la reunión final de scrum y estábamos listos para activar el interruptor. Más que
"solo" el equipo técnico, teníamos a la gente de negocios de marketing, los propietarios de productos,
con nosotros.
Estábamos orgullosos. Fue un buen momento.
Entonces Joe pasó por allí.
Dijo algo como: “Malas noticias. Legal no tiene listos los formularios de inscripción, por lo que aún no
podemos comenzar a funcionar”.
Esto no fue gran cosa; nos habíamos detenido por una cosa u otra durante todo el proyecto y teníamos
la rutina de Batman/Robin dominada. Estaba listo, y mi respuesta fue esencialmente: “Muy bien
compañero, hagámoslo 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?"
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,
echarles el mal de ojo y terminar con esto !”.
Joe no estuvo de acuerdo con mi evaluación y respondió: “Simplemente saldremos a fines de la próxima
semana. No es gran cosa."
XV
PREFACIO
Probablemente puedas adivinar el resto del intercambio; sonaba algo como esto:
Mateo: “¿Pero por qué? Podrían hacer esto en un par de horas.
Joe: "Podría tomar más que eso".
Matt: “Pero tienen todo el fin de semana. Un montón de tiempo. ¡Hagámoslo!"
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.
Pensándolo de nuevo, sin embargo, 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 su mejor desempeño, pero sospecho que Joe estaba jugando,
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 confiaba en nuestras respuestas y se sentía cómodo microgestionando la tecnología.
xvi
PREFACIO
equipo, y al mismo tiempo, por alguna razón, confiaba en el equipo legal y no estaba dispuesto a
microgestionarlos.
¿De que va todo eso?
De alguna manera, el equipo legal había demostrado profesionalismo de una manera que no lo
había hecho el equipo técnico.
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 algunos
años extra de universidad, aunque esos años de universidad podrían haber incluido un poco de
entrenamiento social implícito sobre cómo comportarse.
Desde ese día, hace tantos años, me he preguntado cómo tendría que cambiar la profesión
técnica para ser considerados profesionales.
Oh, tengo algunas ideas. Escribí un poco en el blog, leí mucho, logré mejorar mi propia situación
laboral y ayudar a algunos otros. Sin embargo, no conocía ningún libro que estableciera un plan, que
hiciera explícito todo el asunto.
Entonces, un día, de la nada, recibí una oferta para revisar un borrador inicial 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 un profesional. No con
tópicos trillados, no con apelaciones a papeles, sino con lo que puedes 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 trata de “simplemente ignorarte”.
xvii
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 del sitio web.
Solo que esta vez, imagínalo un poco diferente.
En lugar de eludir los compromisos, el personal técnico los hace.
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 se compromete realmente.
Ahora imagine que el personal está realmente trabajando en conjunto. Cuando los programadores están
bloqueados por las operaciones, levantan el teléfono y el administrador del sistema realmente
comienza a trabajar.
Cuando Joe viene a encender un fuego para trabajar en el boleto 14321, no necesita hacerlo; él puede
ver que el DBA está trabajando diligentemente, no navegando por la web. Del mismo modo, las
estimaciones que obtiene del personal parecen francamente consistentes, y no tiene la sensación de
que el proyecto sea una prioridad entre el almuerzo y la consulta del correo electrónico.
Todos los trucos e intentos de manipular el cronograma no se cumplen con un “Lo intentaremos”, sino
con un “Ese es nuestro compromiso; si quieres crear tus propias metas, siéntete libre”.
Después de un tiempo, sospecho que Joe comenzaría a pensar en el equipo técnico como
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.
—Mateo Heusser
Naturalista de procesos de software
xviii
PREFACIO
A las 11:39 am EST del 28 de enero de 1986, solo 73.124 segundos después del
lanzamiento y a una altitud de 48,000 pies, el transbordador espacial Challenger fue
hecho añicos por la falla del propulsor de cohete sólido derecho (SRB). Siete valientes
astronautas, incluida la maestra de secundaria Christa McAuliffe, se perdieron. La
expresión en el rostro de la madre de McAuliffe mientras observaba la muerte de su hija
a nueve millas de distancia me persigue hasta el día de hoy.
El Challenger se partió porque los gases de escape calientes del SRB averiado se
filtraron entre los segmentos de su casco, salpicando el cuerpo del
xix
PREFACIO
tanque de combustible externo. El fondo del tanque principal de hidrógeno líquido estalló, 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 separó de su puntal de popa
y giró alrededor de su puntal de proa. Su nariz perforó el tanque de oxígeno líquido. Estos
vectores de fuerza aberrantes hicieron que toda la nave, moviéndose muy por encima de Mach 1.5,
girara contra la corriente de aire. Las fuerzas aerodinámicas rápidamente rompieron todo en
pedazos.
Entre los segmentos circulares del SRB había 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 de 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, hubo un pulso de
presión a medida que los gases calientes se acumulaban rápidamente. Los segmentos del
refuerzo se hincharon hacia afuera y relajaron la compresión de 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 en un arco de 70 grados.
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 esos problemas a los gerentes de Morton Thiokol y la NASA siete
años antes. De hecho, las juntas tóricas de lanzamientos anteriores se dañaron de manera similar,
aunque no lo suficiente como para ser catastróficas. El lanzamiento más frío había experimentado el
mayor daño. Los ingenieros habían diseñado una reparación para el problema, pero la implementación
de esa reparación se había retrasado mucho.
Los ingenieros sospecharon que las juntas tóricas se ponían rígidas cuando estaban frías. También
sabían que las temperaturas para el lanzamiento del Challenger eran más frías que las de
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 sobre ese conocimiento. Escribieron notas
XX
PREFACIO
levantando banderas rojas gigantes. Instaron encarecidamente a los gerentes de Thiokol y de
la NASA a no lanzar. 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 gerentes 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 a medida que el Challenger
ascendía con gracia hacia el cielo, comenzaron a relajarse. Momentos antes de la
destrucción, mientras observaban el paso del vehículo a Mach 1, uno de ellos dijo que habían
"esquivado una bala".
A pesar de todas las protestas y memorandos, y los apremios de los ingenieros, los gerentes
creían que sabían mejor. 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 gerentes no eran simplemente tontos, eran criminales. Las vidas de siete buenos
hombres y mujeres, y las esperanzas de una generación que miraba hacia los viajes
espaciales, se desvanecieron en 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 las personas que
realmente sabían: los ingenieros.
Pero, ¿y los ingenieros? Ciertamente, los ingenieros hicieron lo que se suponía que
debían hacer. Informaron a sus gerentes y lucharon duro por su posición. 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. Entonces parecería que los ingenieros
pueden irse sin culpa.
Pero a veces me pregunto si alguno de esos ingenieros se quedó despierto por la noche,
obsesionado por la imagen de la madre de Christa McAuliffe y deseando haber llamado a Dan
Rather.
xxx
PREFACIO
SOBRE ESTE LIBRO _
Este libro trata sobre la profesionalidad del software. Contiene muchos consejos pragmáticos
en un intento de responder preguntas, tales como
• ¿ Qué es un profesional de software?
• ¿ Cómo se comporta un profesional?
• ¿ Cómo lidia un profesional con los conflictos, los horarios ajustados y las
gerentes?
• ¿ Cuándo y cómo debe un profesional decir “no”?
• ¿ Cómo lidia un profesional con la presión?
Pero escondido dentro 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 propio 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 riesgorecompensa.
Pero esa responsabilidad incluye otra cosa, una cosa aterradora. Como ingeniero, tiene un
conocimiento profundo sobre sus sistemas y proyectos que ningún gerente puede tener. Con ese
conocimiento viene la responsabilidad de actuar.
BIBLIOGRAFÍA
[McConnell87]: Malcolm McConnell, Challenger 'Un mal funcionamiento importante', Nuevo
York, Nueva York: Simon & Schuster, 1987
[WikiChallenger]: "Desastre del transbordador espacial Challenger"
http://en.wikipedia.org/wiki/Space_Shuttle_Challenger_disaster
XXII
EXPRESIONES DE GRATITUD
Mi carrera ha sido una serie de colaboraciones y esquemas. Aunque he tenido
muchos sueños y aspiraciones privados, 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 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, ¡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 unimos 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
PDP8. Él y yo construimos una calculadora binaria electrónica de 18 bits que
funciona con componentes básicos. Podía sumar, restar, multiplicar y dividir. Nos llevó
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. Para Tim: ¡Gracias!
XXIII
Tim y yo aprendimos a programar computadoras. Esto no fue fácil de hacer en 1968, pero lo
logramos. Tenemos libros sobre ensamblador PDP8, Fortran, Cobol, PL/1, entre otros. Los
devoramos. Escribimos programas que no teníamos ninguna esperanza 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 ciencias de la computación en nuestro segundo año.
Conectaron un teletipo ASR33 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 nos convertimos inmediatamente en los operadores de facto de esa máquina.
Nadie más podía acercarse a él.
El módem se conectó descolgando el teléfono y marcando el número. Cuando escuchó
el chillido 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 chillido.
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 podía marcar un teléfono (cualquier teléfono) tocando el número de
teléfono en el gancho del interruptor. Yo era baterista, así que tenía muy buenos reflejos y
sincronización. Podría marcar ese módem, con el candado 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 perforada en la cinta. Los estudiantes
escribieron sus programas en IITran, un lenguaje interpretado notablemente poderoso.
Los estudiantes dejarían sus cintas de papel en una canasta cerca de los Teletipos.
Después de la escuela, Tim y yo conectábamos la computadora (por supuesto, haciendo
tapping), cargamos 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 más tarde,
volvíamos a llamar y obteníamos las copias impresas, nuevamente a 10 caracteres por segundo.
El Teletipo no separó los listados de los estudiantes expulsando páginas. Simplemente imprimió uno tras otro.
XXIV
después del siguiente, así que los cortamos con tijeras, sujetamos la cinta de papel de
entrada a su lista y los colocamos en la cesta de salida.
Tim y yo éramos los maestros y dioses de ese proceso. Incluso los profesores nos dejaban
solos cuando estábamos en esa sala. 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. Nos acabamos de mudar 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.
roberto: gracias!
Luego, después de que todos los deberes de los estudiantes estaban hechos,
jugábamos. Escribimos programa tras programa para hacer cualquier cantidad de cosas
locas y raras. Escribimos programas que graficaban círculos y parábolas en ASCII en un
Teletipo. Escribimos programas de paseo aleatorio y generadores de palabras aleatorias.
Calculamos factorial 50 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 Tabulating 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. Le 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 ya Richard, quien
catalizó e impulsó gran parte de ese proceso: Gracias.
Después de renunciar y derretirme a la edad de 20 años, trabajé como reparador de
cortadoras de césped para mi cuñado. Era tan malo en eso que tuvo que despedirme.
¡Gracias, Wes!
Aproximadamente un año después terminé trabajando en Outboard Marine Corporation.
En ese momento estaba casada y tenía un bebé en camino. También me despidieron.
¡Gracias, John, Ralph y Tom!
xiv
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, conseguiste que
Bob y Mike lo hicieran. Nos divertimos mucho juntos.
¡Gracias, Mike!
Jerry Fitzpatrick también trabajó en Teradyne. Nos conocimos mientras jugábamos
Dungeons & Dragons juntos, pero rápidamente formamos una colaboración. Escribimos
software en un Commodore 64 para ayudar a los usuarios de D&D. También
comenzamos un nuevo proyecto en Teradyne llamado "La recepcionista electrónica".
Trabajamos juntos durante varios años y se convirtió y sigue siendo un gran amigo. ¡Gracias, Jerry!
Pasé un año en Inglaterra mientras trabajaba para Teradyne. Allí hice equipo con Mike
Kergozou. Él y yo tramamos juntos todo tipo de cosas, aunque la mayoría de esos esquemas
tenían que ver con bicicletas y pubs. Pero él era un programador dedicado que estaba muy
centrado en la calidad y la disciplina (aunque, tal vez, no estaría de acuerdo). ¡Gracias, Mike!
Al regresar de Inglaterra en 1987, comencé a intrigar 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 hacer los
millones que nunca llegaron. Pero continuamos con nuestras intrigas. ¡Gracias, Jim!
Al final fundamos Object Mentor juntos. 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 tantos otros con los que he esquematizado, tantos otros con los que he colaborado,
tantos otros 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,
xxi
Mike Hill, Eric Meade, Ron Jeffries, Kent Beck, Martin Fowler, Grady Booch y una lista
interminable de otros. Gracias a todos.
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 cumpliera
los 18. Durante 38 años ha sido mi compañera constante, mi timón y mi vela, mi amor y
mi vida. Espero con ansias 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, Angela, mi adorable mamá gallina e intrépida
asistente. Ella me mantiene en el buen camino y nunca me deja olvidar una fecha o un
compromiso. Planifico planes de negocios con mi hijo Micah, el fundador de 8thlight.com.
Su cabeza para los negocios es mucho mejor que la mía. ¡Nuestra última aventura,
cleancoders.com, 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, ¡las
intrigas serias acaban de comenzar!
Nadie en tu vida te enseñará más que tus hijos. ¡Gracias, niños!
xvii
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 gerentes de software altamente
experimentados que se especializan en ayudar a las empresas a realizar sus proyectos.
Object Mentor ofrece servicios de consultoría de mejora de procesos, consultoría de diseño de
software orientado a objetos, capacitación y desarrollo de habilidades a las principales
corporaciones de todo el mundo.
Martin ha publicado docenas de artículos en varias revistas comerciales y es un orador
habitual en conferencias y ferias comerciales internacionales.
Ha escrito y editado muchos libros, entre ellos:
• Diseño de aplicaciones C++ orientadas a objetos usando el método Booch
• Lenguajes de patrones de diseño de programas 3
xxix
SOBRE EL AUTOR
• Más joyas 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
Martin, líder en la industria del desarrollo de software, se desempeñó durante tres años como
editor en jefe del C++ Report y fue el primer presidente de Agile Alliance.
Robert también es el fundador de Uncle Bob Consulting, LLC y cofundador con su hijo Micah
Martin de The Clean Coders LLC.
xxx
EN LA PORTADA
La impresionante imagen de la portada, que recuerda al ojo de Sauron, es M1, la Nebulosa
del Cangrejo. M1 está ubicado 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 voló sus entrañas por todo el cielo en la fecha bastante auspiciosa del 4
de julio de 1054 d.C. A una distancia de 6500 años luz, esa explosión se le apareció a los chinos
xxi
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, se desvaneció lentamente de la vista a simple vista.
La imagen de la 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 tomado por el telescopio de rayos X Chandra.
La imagen visible muestra una nube de polvo y gas que se expande rápidamente 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 la furiosa velocidad de 1500 kilómetros por segundo. La
energía cinética de esa vieja explosión es impresionante por decir lo menos.
En el mismo 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ó que la estrella explotara 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 creados cuando se formaron todos esos neutrones, abrió la estrella y la hizo volar al reino
venidero.
El púlsar gira unas 30 veces por segundo; y parpadea mientras gira. Podemos verlo parpadear en nuestros
telescopios. Esos pulsos de luz son la razón por la que lo llamamos púlsar, que es la abreviatura de Pulsating
Star.
xxxii
PRE REQUISITO
I NTRODUCCIÓN
(No te saltes esto, lo vas a necesitar).
Supongo que acaba de leer este libro porque es programador de computadoras
y está intrigado por la noción de profesionalismo. Usted debería ser.
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 que lo he visto todo. me han despedido Me han alabado. He sido líder
de equipo, gerente, soldado raso e incluso director ejecutivo. he trabajado con brillante
1. No se asuste.
1
PREREQUISITO INTRODUCCIÓN
He trabajado con programadores y he trabajado con slugs.2 He trabajado en sistemas de software/
hardware integrados de última generación de alta tecnología, y he trabajado en sistemas de
nómina corporativos. He programado en COBOL, FORTRAN, BAL, PDP8, PDP11, C, C++, Java,
Ruby, Smalltalk y una plétora de otros lenguajes y sistemas.
He trabajado con ladrones de cheques no confiables y he trabajado con profesionales
consumados. Esta última clasificación es el tema de este libro.
En las páginas de este libro intentaré definir lo que 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 difícil. Verás, cuando conseguí mi primer trabajo como programador, profesional era la
última palabra que habrías usado para describirme.
Era el año 1969. Yo tenía 17 años. Mi padre había acosado 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 auto a alta velocidad con su mano ordenándole "¡Alto!"
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 los manuales, mi supervisor me pidió que escribiera un
sencillo programa Easycoder3. Me emocionó que me preguntaran. 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 identificaciones nuevas. 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 a
Autocoder para la computadora IBM 1401.
2
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 esos mazos uno encima del otro.
Así es como se veían estas pilas de cartas. Tenían rayas rojas y azules, y las rayas tenían unas
200 tarjetas cada una. Cada una de esas franjas contenía el código fuente de la biblioteca de
subrutinas que los programadores solían usar.
Los programadores simplemente tomarían el mazo superior de la pila, asegurándose de que solo
tomaran cartas rojas o azules, y luego las 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. Usted escribió su programa en el formulario de codificación
usando letras mayúsculas y un lápiz #2. En las últimas 6 columnas de cada línea escribiste un
número de secuencia con ese lápiz #2. Por lo general, incrementó el número de secuencia en 10
para poder insertar tarjetas más tarde.
El formulario de codificación fue para los perforadores de llaves. Esta empresa tenía varias
docenas de mujeres que tomaban formularios de codificación de una gran bandeja de entrada y
luego los "escribían" en máquinas perforadoras. 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 perforadores me devolvieron mi programa por correo interno.
Mi pequeño mazo de tarjetas perforadas estaba envuelto por mis formularios de codificación y
una goma elástica. Revisé las tarjetas en busca de errores de perforación. No hubo ninguno. Entonces
puse la plataforma de la biblioteca de subrutinas al final de mi plataforma de programas, y luego
llevé la plataforma arriba a los operadores de la computadora.
Las computadoras estaban detrás de puertas cerradas en una habitación 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 bandeja de entrada dentro de la sala de ordenadores.
Cuando llegaran a hacerlo, controlarían mi mazo.
3
Al día siguiente recuperé mi mazo. Estaba envuelto en una lista de los resultados de la carrera y
se mantuvo junto con una banda elástica. (¡Usábamos muchas bandas de goma en esos
días!)
Abrí la lista y vi que mi compilación había fallado. Los mensajes de error en la lista eran muy
difíciles de entender para mí, así que se los llevé a mi supervisor. Lo miró, murmuró
por lo bajo, tomó algunas notas rápidas en el listado, agarró mi mazo y luego me dijo que
lo siguiera.
Me llevó a la sala de perforación de llaves y se sentó frente a una máquina perforadora vacía.
Corrigió una por una las cartas que estaban equivocadas y añadió una o dos cartas más.
Rápidamente explicó lo que estaba haciendo, pero todo pasó como un relámpago.
Llevó la nueva consola a la sala de ordenadores y llamó a la puerta. Dijo algunas palabras
mágicas a uno de los operadores y luego entró en la sala de ordenadores detrás de él.
Me hizo señas para que lo siguiera. El operador instaló las unidades de cinta y cargó la
plataforma mientras observábamos. Las cintas giraron, la impresora parloteó y luego todo
terminó. El programa había funcionado.
Al día siguiente, mi supervisor me agradeció por mi ayuda y terminó mi empleo.
Aparentemente, ASC no sintió que tuviera tiempo para criar 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 tiempo
completo en el segundo turno en ASC operando impresoras fuera de línea. Estas impresoras imprimían correo
no deseado a partir de imágenes impresas almacenadas en cinta. Mi trabajo consistía en cargar las
impresoras con papel, cargar las cintas en las unidades de cinta, arreglar los atascos de papel y, por lo
demás, simplemente observar el funcionamiento de las máquinas.
Corría el año 1970. La universidad no era una opción para mí, ni me atraía en particular.
La guerra de Vietnam todavía estaba en su apogeo y los campus eran caóticos. Continué
inhalando libros sobre COBOL, Fortran, PL/1, PDP8 e IBM 360 Assembler. Mi intención
era pasar por alto la escuela y conducir lo más fuerte que pudiera para conseguir un trabajo
de programación.
4
Doce meses después logré ese objetivo. Fui ascendido 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 mini computadora simple similar
en arquitectura a una PDP8 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 de E/S, el sistema de archivos para los
discos, el intercambiador de superposición 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 a la semana para
cumplir con un plazo infernal. Mi salario era de $7,200 por 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 compañía nos dio un aumento del 2%. Nos sentimos engañados y abusados.
Varios de nosotros conseguimos trabajos en otros lugares y simplemente renunciamos.
Sin embargo, tomé 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. Tenía 19 años, desempleado, sin título. Me
entrevisté para algunos puestos de programación, pero esas entrevistas no salieron bien. Así que 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. Eventualmente tuvo que dejarme ir. Caí en un
funk desagradable.
Me quedaba despierto hasta las 3 am todas las noches comiendo pizza y viendo viejas películas de
monstruos en la vieja televisión en blanco y negro con orejas de conejo de mis padres. Solo algunos
de los fantasmas eran personajes de las películas. Me quedé en la cama hasta la 1 pm porque no quería
enfrentarme a mis días tristes. Tomé un curso de cálculo en un colegio comunitario local y reprobé. Yo
era un desastre.
5
Mi madre me llevó a un lado y me dijo que mi vida era un desastre y que había sido un idiota por
renunciar sin tener un nuevo trabajo, por renunciar tan emocionalmente y por renunciar
junto con mi amigo. Ella me dijo que nunca renuncias sin tener un nuevo trabajo, y siempre
renuncias tranquilamente, con frialdad y solo. Ella me dijo que debería llamar a mi antiguo jefe y
rogar que me devuelva mi antiguo trabajo.
Ella dijo: “Tienes que comer un pastel humilde”.
Los muchachos de diecinueve años no son conocidos por su apetito por el humilde pastel, y yo no
fui la excepción. Pero las circunstancias habían hecho mella en mi orgullo. Al final llamé a mi jefe y le
di un gran mordisco a ese humilde pastel. Y funcionó. 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 Ps y Qs y tratando de ser un
empleado tan valioso como pude. Fui recompensado con promociones y aumentos, y un
cheque de pago regular. La vida era buena. Cuando dejé esa empresa, fue en buenos términos y
con una oferta para un mejor trabajo en mi bolsillo.
Podrías pensar que había aprendido la lección; que ahora era un profesional. Lejos de ahi. Esa fue
solo la primera de muchas lecciones que necesitaba aprender. En los próximos años, me despedirían
de un trabajo por pasar por alto fechas críticas por descuido, y casi me despedirían de otro más
por filtrar inadvertidamente información confidencial a un cliente. Tomaría la iniciativa en un proyecto
condenado y lo hundiría sin pedir la ayuda que sabía que necesitaba. Yo 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
gran responsabilidad con la que lidiar. Y lo peor de todo, 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 secante de mis propios
crímenes y un conjunto de pautas para que usted evite caminar en mis primeros zapatos.
6
1 PROFESIONALIDAD
Oh, ríete, Curtin, viejo. Es una gran broma que nos juega el Señor, o el destino, o
la naturaleza, lo que prefieras. ¡Pero quien sea o lo que sea que lo jugó ciertamente
tenía sentido del humor! ¡Ja!"
— Howard, El tesoro de la Sierra Madre
7
CAPÍTULO 1 PROFESIONALIDAD
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?
CUIDADO CON LO QUE PIDE _
Profesionalismo es un término cargado. Ciertamente es una insignia de honor y orgullo,
pero también es un marcador de responsabilidad y rendición de cuentas. Los dos
van de la mano, por supuesto. No puede enorgullecerse y honrarse de algo por lo que no
se le puede responsabilizar.
Es mucho más fácil ser un no 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 limpia el desorden. Pero cuando un
profesional comete un error, limpia el desorden.
¿Qué sucedería si permitiera que un error se deslizara 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 "pasan
cosas" y comenzaría a escribir el siguiente módulo. ¡El profesional escribiría a la
compañía un cheque por $10,000!1
Sí, se siente un poco diferente cuando es tu propio dinero, ¿no? Pero ese sentimiento
es el sentimiento que tiene un profesional todo el tiempo. De hecho, ese sentimiento
es la esencia de la profesionalidad. Porque, verá, el profesionalismo se trata de asumir la
responsabilidad.
TOMAR RESPONSABILIDAD
Leíste la introducción, ¿verdad? Si no, regrese y hágalo ahora; establece el contexto
para todo lo que sigue en este libro.
Aprendí a asumir la responsabilidad sufriendo las consecuencias de no asumirla.
1. ¡Ojalá tenga una buena política de errores y omisiones!
8
TOMAR RESPONSABILIDAD
En 1979 estaba trabajando para una empresa llamada Teradyne. Yo era el "ingeniero
responsable" del software que controlaba un sistema basado en una mini y
microcomputadora 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 gerentes 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 las tasas de quejas de los
clientes que las comisiones de servicios públicos medían y utilizaban para regular las
tarifas que podían cobrar las compañías telefónicas. En resumen, estos sistemas fueron
increíblemente importantes.
Cada noche, estos sistemas ejecutaban una "rutina nocturna" en la que la minicomputadora
central le decía a cada una de las microcomputadoras satelitales que probaran
todas las líneas telefónicas bajo su control. Cada mañana, la computadora central sacaba
la lista de líneas defectuosas, junto con sus características de falla. Los gerentes del
área de servicio usarían este informe para programar reparadores para reparar 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 función que
nuestros clientes habían estado exigiendo. Les habíamos dicho que proporcionaríamos esa
nueva función en una fecha determinada. Apenas logré pasar las cintas al día siguiente 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 enviar el software a
tiempo, me había olvidado de probar la rutina. Había probado gran parte de la
9
otra funcionalidad del sistema, pero probar la rutina tomó horas y necesitaba enviar el
software. Ninguna de las correcciones de errores estaba en el código de rutina, así que me
sentí seguro.
Perder un informe nocturno era un gran problema. Significaba que los reparadores tenían
menos que hacer y más tarde estarían sobrecargados. Significaba que algunos clientes podrían
notar una falla y quejarse. La pérdida de los datos de una noche es suficiente para que un
gerente del área de servicio llame a Tom y lo critique.
Encendí nuestro sistema de laboratorio, cargué el nuevo software y luego comencé una rutina.
Tardó 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 anterior. Estaba enojado conmigo porque dije que esto
era un doble golpe para los clientes, ya que habían perdido los 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 para preguntarme
cuándo arreglaría esto. También se aseguró de que yo supiera sobre las críticas 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 nuevas cintas y todo volvió a la normalidad. Tom, que no
era mi jefe, se calmó y dejamos todo el episodio atrás. Mi jefe se acercó a mí cuando
terminó y me dijo: "Apuesto a que no volverás a hacer eso". Estuve de acuerdo.
Al reflexionar me di cuenta de que el envío sin probar la rutina había sido una
irresponsabilidad. La razón por la que descuidé la prueba fue para poder decir que había enviado
10
PRIMERO, NO HACER DAÑO
a tiempo. Se trataba de mí salvando la cara. No me había preocupado por el cliente, ni por mi
empleador. Solo me había preocupado mi propia reputación. Debería haber asumido la responsabilidad
antes 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 servicios habría llamado.
PRIMERO , NO HACER DAÑO _
Entonces, ¿cómo asumimos la responsabilidad? Hay algunos principios. Extraer del juramento hipocrático
puede parecer arrogante, pero ¿qué mejor fuente hay? Y, de hecho, ¿no tiene sentido que la primera
responsabilidad y el primer objetivo de un aspirante a profesional sea usar sus poderes para el bien?
¿Qué daño puede hacer un desarrollador de software? Desde un punto de vista puramente de software, puede
dañar tanto la función como la estructura del software. Exploraremos cómo evitar hacer precisamente eso.
N O DAÑO AL 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 sentir 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 están pagando para crear software que funcione exactamente como ellos
quieren.
Dañamos la función de nuestro software cuando creamos errores. Por lo tanto, para ser profesionales, no
debemos crear errores.
"¡Pero espera!" te escucho 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 deja libre. El cuerpo humano es demasiado complejo para entenderlo
en su totalidad, pero los médicos siguen jurando no hacer daño. Si ellos no se quitan el anzuelo así , ¿cómo
vamos a hacerlo nosotros?
11
"¿Nos estás diciendo que debemos ser perfectos?" ¿Te escucho objetar?
No, te digo que debes ser responsable de tus imperfecciones. El hecho de que se produzcan
errores en su código no significa que usted no sea responsable de ellos. El hecho de que
la tarea de escribir un software perfecto sea prácticamente imposible no significa que usted no sea
responsable de la imperfección.
Corresponde a 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 madura 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 su responsabilidad acercarse
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 deliberadamente un código que 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 usan QA como detectores de errores. Les envían código que no han revisado a
fondo. Dependen del control de calidad para encontrar los errores y reportarlos 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 este sea 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 perezoso e irresponsable. Liberar código para el control de calidad que no sabe que
funciona no es profesional. Viola la regla de "no hacer daño".
¿El control de calidad encontrará errores? Probablemente, así que prepárese para disculparse
y luego descubra por qué esos errores lograron escapar de su atención y haga algo para evitar que
vuelva a suceder.
12
Cada vez que el control de calidad, o peor aún, un usuario, encuentra un problema, debe
sorprenderse, disgustarse y decidirse 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ébalo. ¡Pruébalo de siete maneras hasta el domingo!
Tal vez le preocupe que probar tanto su código lleve demasiado tiempo. Después de todo, tienes
horarios y plazos que cumplir. Si pasa todo su tiempo probando, nunca obtendrá nada más escrito. ¡Buen
punto! Entonces, automatice sus pruebas. Escriba pruebas unitarias que pueda ejecutar en cualquier
momento y ejecute esas pruebas tan a menudo como pueda.
¿Cuánto del código debe probarse con estas pruebas unitarias automatizadas? ¿Realmente necesito
responder a 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 ser probada. Período.
¿No es eso poco realista? Por supuesto que no. Solo escribe código porque espera que se ejecute. Si
espera que se ejecute, debe saber que funciona. La única manera de saber esto es probarlo.
Soy el principal contribuyente y responsable de un proyecto de código abierto llamado FitNesse. Al
escribir estas líneas, 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 pruebas de 2000 es ~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 más alta que eso.
¿La cobertura es del 100%? No, 100% es una asíntota.
¿Pero no es un código difícil de probar? Sí, pero solo porque ese código ha sido diseñado para
que sea difícil de probar. La solución a eso es diseñar su código para que sea fácil
Probar. Y la mejor manera de hacerlo es escribir primero las pruebas, antes de escribir el código que
las supera.
13
Esta es una disciplina conocida como Test Driven Development (TDD), de la que hablaremos más en un
capítulo posterior.
Control de calidad automatizado
Todo el procedimiento de control de calidad para FitNesse es la ejecución de las pruebas unitarias y de
aceptación. Si esas pruebas pasan, envío. Esto significa que mi procedimiento de control de calidad toma
alrededor de tres minutos y puedo ejecutarlo a mi antojo.
Ahora bien, es cierto que nadie muere si hay un error en FitNesse. Nadie pierde millones de dólares tampoco.
Por otro lado, FitNesse tiene muchos miles de usuarios y una lista de errores muy pequeña.
Ciertamente, algunos sistemas son tan críticos para la misión que una breve prueba automatizada
es insuficiente para determinar la preparación para el despliegue. Por otro lado, tú como desarrollador
necesitas un mecanismo relativamente rápido y fiable para saber que el código que has escrito funciona y no
interfiere con el resto del sistema. Entonces, como mínimo, sus pruebas automatizadas deberían decirle que es
muy probable que el sistema pase el control de calidad.
NO DAÑO A LA ESTRUCTURA _
El verdadero profesional sabe que entregar la función 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.
La suposición fundamental que subyace a todos los proyectos de software es que el software es fácil de
cambiar. Si viola esta suposición al crear estructuras inflexibles, socava el modelo económico en el que se
basa toda la industria.
En resumen: debe poder realizar cambios sin costos desorbitados.
Desafortunadamente, demasiados proyectos quedan atrapados en un pozo de alquitrán de estructura deficiente.
Las tareas que antes tomaban días comienzan a tomar semanas y luego meses. La gerencia, desesperada por
recuperar el impulso perdido, contrata a más desarrolladores para acelerar las cosas. Pero estos
desarrolladores simplemente se suman al pantano, profundizando el daño estructural y aumentando el
impedimento.
14
Mucho se ha escrito sobre los principios y patrones de diseño de software que soportan
estructuras que son flexibles y mantenibles.2 Los desarrolladores profesionales de
software memorizan estas cosas y se esfuerzan por adaptar su software a ellas. Pero hay
un truco para esto que muy pocos desarrolladores de software siguen: si desea que su
software sea flexible, ¡tiene 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, refina
el diseño para que el próximo cambio sea más fácil.
¿Cuándo haces estos cambios fáciles? ¡Todo el tiempo! Cada vez que observa un
módulo, realiza cambios pequeños y ligeros 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 haga
algún acto de bondad al azar con el código cada vez que lo vea.
Esto es completamente contrario a la forma en que la mayoría de la gente piensa sobre
el software. Piensan que hacer 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á flexionando, entonces cuando necesite cambiarlo , lo encontrará rígido.
¿Por qué la mayoría de los desarrolladores temen hacer 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 de pruebas automatizado 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 enloquecedoramente casuales a la hora de hacer cambios aleatorios y
oportunistas. Cambiarán el nombre de una clase, por capricho. Notarán un método largo mientras
2. [PPP2001]
15
leyendo un módulo y particionándolo de forma rutinaria. 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 mando. 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 sea comercializable. No es responsabilidad de su empleador capacitarlo,
enviarlo a conferencias o comprarle libros. Estas cosas son tuyas
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. Eso 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 la manera de hacerlo usted mismo.
Tampoco es responsabilidad de su empleador darle el tiempo que necesita para
aprender. Algunos empleadores pueden proporcionar ese tiempo. Algunos
empleadores incluso pueden exigir que se tome el tiempo. Pero de nuevo, te están
haciendo un favor, y deberías estar apropiadamente agradecido. Tales favores no son
algo que debas esperar.
Le debe a su empleador una cierta cantidad de tiempo y esfuerzo. En aras del
argumento, usemos el estándar estadounidense de 40 horas por semana. Estas
40 horas deben dedicarse a los problemas de su empleador , no a sus problemas.
Debes planear trabajar 60 horas a la semana. Los primeros 40 son para su
empleador. Los 20 restantes son para ti. Durante las 20 horas restantes, debería estar
leyendo, practicando, aprendiendo y mejorando su carrera.
Puedo oírte pensar: “¿Pero qué pasa con mi familia? ¿Qué pasa con mi vida? ¿Se
supone que debo sacrificarlos por mi empleador?
dieciséis
ÉTICA DE TRABAJO
No estoy hablando de todo tu tiempo libre aquí. Estoy hablando de 20 horas extra por
semana. Eso es aproximadamente tres horas por día. Si usa su hora de almuerzo
para leer, escuchar podcasts en su viaje y pasar 90 minutos por día aprendiendo
un nuevo idioma, lo tendrá todo cubierto.
Haz las matematicas. En una semana hay 168 horas. Dale a tu empleador 40 ya tu
carrera otros 20. Eso deja 108. Otros 56 para dormir te dejan 52 para todo lo demás.
Tal vez no quiera hacer ese tipo de compromiso. Eso está bien, pero entonces no
deberías pensar en ti mismo como un profesional. Los profesionales dedican tiempo
cuidando su profesión.
Tal vez pienses que el trabajo debe quedarse en el trabajo y que no debes traerlo a casa.
¡Estoy de acuerdo! No debe estar trabajando para su 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 parte de
esas 20 horas es razonable. Pero recuerda, esas 20 horas son para ti. Deben usarse
para hacerte más valioso como profesional.
Tal vez pienses que esta es una receta para el agotamiento. Al contrario, es una receta
para evitar el agotamiento. Presumiblemente, se convirtió en desarrollador de software
porque le apasiona el software y su deseo de ser un profesional está motivado por esa
pasión. Durante esas 20 horas deberías estar haciendo esas cosas que refuerzan
esa pasión. ¡ Esas 20 horas deberían ser divertidas!
CONOCE TU CAMPO _
¿Sabes qué es un diagrama de NassiSchneiderman? ¿Si no, porque no? ¿Conoces
la diferencia entre una máquina de estado de Mealy y una de Moore? Debería.
¿Podrías escribir una ordenación rápida sin buscarla? ¿Sabes lo que significa el término
“Análisis de transformación”? ¿Podría realizar una descomposición funcional con
diagramas de flujo de datos? ¿Qué significa el término "datos vagabundos"? ¿Has
escuchado el término “Conascencia”? ¿Qué es una Mesa de Parnas?
17
Una riqueza de ideas, disciplinas, técnicas, herramientas y terminologías decoran los últimos
cincuenta años de nuestro campo. ¿Cuánto de esto sabes? 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 consulta parece obvia en la superficie. Ciertamente nuestro campo está
progresando ya un ritmo feroz. Curiosamente, sin embargo, ese progreso es en muchos
aspectos periférico. Es cierto que ya no esperamos 24 horas para completar la compilación.
Es cierto que escribimos sistemas que tienen un tamaño de gigabytes. Es cierto que
trabajamos en medio de una red mundial que brinda acceso instantáneo a la información.
Por otro lado, estamos escribiendo las mismas declaraciones si y mientras que estábamos
escribiendo hace 50 años. Mucho ha cambiado. Mucho no lo ha hecho.
La segunda parte de la consulta ciertamente no es cierta. Muy pocas ideas de los últimos 50
años se han vuelto irrelevantes. Algunos se han quedado al margen, es cierto. La idea de hacer
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.
En general, sin embargo, la gran mayoría de las ideas ganadas con tanto esfuerzo de los últimos
50 años son tan valiosas hoy como lo fueron entonces. Tal vez sean aún más valiosos ahora.
Recuerda la maldición de Santayana: “Aquellos que no pueden recordar el pasado
están condenados a repetirlo”.
Aquí hay una lista mínima de las cosas con las que todo profesional de software debería
estar familiarizado:
• Patrones de diseño. Debe poder describir los 24 patrones en el libro GOF y tener un
conocimiento práctico de muchos de los patrones en los libros POSA.
• Principios de diseño. Debes conocer los principios SOLID y tener una buena
comprensión de los principios componentes.
• Métodos. Debe comprender XP, Scrum, Lean, Kanban, Waterfall, Análisis estructurado
y Diseño estructurado.
18
ÉTICA DE TRABAJO
• Disciplinas. Debe 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 Estado, diagramas de flujo y tablas de decisión.
APRENDIZAJE CONTINUO
La tasa frenética de cambio en nuestra industria significa que los desarrolladores de software
deben continuar aprendiendo grandes cantidades solo para mantenerse al día. ¡Ay de los arquitectos
que dejen de codificar! Rápidamente se encontrarán irrelevantes. ¡Ay de los programadores que
dejan de aprender nuevos lenguajes! Mirarán cómo la industria los pasa por alto. ¡Ay de los
desarrolladores que no logran aprender nuevas disciplinas y técnicas! Sus compañeros sobresaldrán a
medida que decaigan.
¿Visitaría a un médico que no estuviera 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?
Leer libros, artículos, blogs, tweets. Ir a conferencias. Ir a grupos de usuarios.
Participar en grupos de lectura y estudio. Aprende cosas que están fuera de tu zona de confort. Si
eres programador de .NET, aprende Java. Si eres programador de Java, aprende Ruby. Si eres
un programador de C, aprende Lisp. Si realmente quieres ejercitar tu cerebro, ¡aprende Prolog and Forth!
PRÁCTICA
Práctica de profesionales. Los verdaderos profesionales trabajan duro para mantener sus habilidades
nítidas y listas. No es suficiente simplemente hacer su trabajo diario y llamar a eso práctica.
Hacer su trabajo diario es rendimiento, no práctica. La práctica es cuando ejercitas
específicamente tus habilidades fuera del desempeño de tu 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, tienen ejercicios especiales que
realizan. Escalas y estudios y corridas. Lo hacen una y otra vez para entrenar sus dedos y su mente, y
para mantener el dominio de su habilidad.
19
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 con frecuencia es la repetición de ejercicios
sencillos como el Juego de bolos o los Factores primos. Llamo a estos ejercicios kata. Hay
muchos katas de este tipo para elegir.
Un kata generalmente viene en forma de un problema de programación simple para resolver, como
escribir la función que calcula los factores primos de un número entero. El objetivo de hacer el kata
no es averiguar cómo resolver el problema; ya sabes cómo hacerlo. El objetivo del kata es
entrenar tus dedos y tu cerebro.
Hago un kata o dos todos los días, a menudo como parte de la preparación para el trabajo. Podría
hacerlo en Java, en Ruby, en Clojure o en algún otro idioma para el que quiera mantener mis
habilidades. Usaré el kata para perfeccionar una habilidad en particular, como mantener mis dedos
acostumbrados a presionar teclas de método abreviado o usar ciertas refactorizaciones.
Piense en el kata como un ejercicio de calentamiento de 10 minutos por la mañana y un 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 juntos, practicar juntos,
diseñar y planificar juntos. Al hacerlo, aprenden mucho unos de otros y hacen más cosas más
rápido y con menos errores.
Esto no significa que tengas que pasar el 100% de tu tiempo trabajando con otros.
El tiempo a solas también es muy importante. Por mucho que me guste programar en
pareja con otros, me vuelve loco si no puedo salir solo de vez en cuando.
MENTORÍA
La mejor forma de aprender es enseñando. Nada introducirá hechos y valores en su cabeza
más rápido y más difícil que tener que comunicárselos a las personas de las que es
responsable. Así que el beneficio de la enseñanza está fuertemente a favor del maestro.
20
ÉTICA DE TRABAJO
De la misma manera, no hay mejor manera de traer gente nueva a una organización que
sentarse con ellos y enseñarles cómo funciona. Los profesionales asumen la responsabilidad
personal de asesorar a los jóvenes. No permitirán que un menor se mueva sin
supervisión.
CONOCE TU DOMINIO _ _
Es responsabilidad de cada profesional de software comprender el dominio de las soluciones
que están programando. Si está escribiendo un sistema de contabilidad, debe conocer el
campo contable. Si está escribiendo una solicitud de viaje, debe conocer la industria de
viajes. No es necesario que sea un experto en el dominio, pero hay una cantidad razonable
de diligencia debida en la que debe participar.
Al iniciar un proyecto en un nuevo dominio, lea uno o dos libros sobre el tema.
Entreviste a su cliente y usuarios sobre la base y los conceptos básicos del dominio.
Pase algún tiempo con los expertos e intente comprender sus principios y valores.
Es el peor tipo de comportamiento no profesional codificar simplemente a partir de
una especificación sin comprender por qué esa especificación tiene sentido para el negocio.
Más bien, debe saber lo suficiente sobre el dominio para poder reconocer y desafiar los
errores de especificación.
ME IDENTIFICO CON TU EMPLEADOR / CLIENTE
Los problemas de su empleador son sus problemas. Debe 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
características 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
frente a ellos actitud con su empleador. Los profesionales evitan esto a toda costa.
21
HUMILDAD
La programación es un acto de creación. Cuando escribimos código estamos creando algo de la
nada. Estamos imponiendo audazmente el orden sobre el caos. Estamos comandando con confianza, con
detalles precisos, los comportamientos de una máquina que de otro modo podría causar un daño
incalculable. Entonces, programar es un acto de
arrogancia suprema.
Los profesionales saben que son arrogantes y no falsamente humildes. Un profesional conoce su trabajo y se
enorgullece de su trabajo. Un profesional confía en sus habilidades y toma riesgos audaces y calculados
basados en esa confianza. Un profesional no es tímido.
Sin embargo, un profesional también sabe que habrá momentos en los que fallará, sus cálculos de riesgo serán
erróneos, sus habilidades se quedarán cortas; se mirará en el espejo y verá a un tonto arrogante que
le devuelve la sonrisa.
Entonces, cuando un profesional se encuentra a sí mismo en el blanco de una broma, será el primero en reírse.
Nunca ridiculizará a los demás, pero aceptará el ridículo cuando se 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
objetivo. 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 del desarrollo ágil de software, Upper Saddle
River, NJ: Prentice Hall, 2002.
22
2DECIR NO _
"Hacer; o no. No hay que intentarlo”.
—Yoda
A principios de los años 70, yo y dos de mis amigos de diecinueve años estábamos trabajando en un
sistema de contabilidad en tiempo real para el sindicato de camioneros en Chicago para una empresa
llamada ASC. Si me vienen a la mente nombres como Jimmy Hoffa, deberían hacerlo. No te metiste con
los camioneros en 1971.
Se suponía que nuestro sistema entraría en funcionamiento en una fecha determinada. Mucho dinero
estaba en juego en esa fecha. Nuestro equipo había estado trabajando semanas de 60, 70 y 80 horas
para tratar de mantener ese horario.
23
CAPÍTULO 2 DECIR NO
Una semana antes de la fecha de lanzamiento, finalmente logramos armar el sistema en su
totalidad. Hubo muchos errores y problemas con los que lidiar, y trabajamos frenéticamente
en la lista. Apenas había tiempo para comer y dormir, y mucho menos para pensar.
Frank, el gerente de ASC, era un coronel retirado de la Fuerza Aérea. Era uno de esos gerentes
ruidosos y directos. Era su camino o la carretera, y él te ponía en esa carretera dejándote caer desde
10,000 pies sin paracaídas. Nosotros, los de diecinueve años, apenas podíamos hacer contacto
visual con él.
Frank dijo que tenía que hacerse antes de la fecha. Eso era todo lo que habia al respecto. Llegaría
la fecha y habríamos terminado. Período. Sin discusión. Cambio y fuera.
Mi jefe, Bill, era un tipo agradable. 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 salir en vivo en la fecha,
sin importar qué.
Así que salimos en vivo en la fecha. Y fue un desastre abrasador.
Había una docena de terminales semidúplex de 300 baudios que conectaban la sede central de
Teamster en Chicago con nuestra máquina treinta millas al norte en los suburbios. Cada una de esas
terminales se bloqueaba cada 30 minutos más o menos. Habíamos visto este problema antes, pero
no habíamos simulado el tráfico que los empleados de entrada de datos del sindicato estaban
repentinamente estrellándose contra nuestro sistema.
Para empeorar las cosas, las hojas sueltas que se imprimían 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 bloqueos fue reiniciar. Así que 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 sido congeladas tendrían que
empezar de nuevo. Y esto sucedía más de una vez por hora.
Después de medio día de esto, el gerente de la oficina de 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 e iban a tener que volver a ingresar todo usando el sistema anterior.
24
DECIR NO
Escuchamos los gemidos y rugidos de Frank por todo el edificio. Continuaron durante mucho,
mucho tiempo. Entonces Bill y el analista de nuestro sistema, Jalil, vinieron a nosotros 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 para el viernes”.
Así que dije: “Mira, apenas conseguimos que este sistema funcionara la semana pasada.
Tenemos que sacudir los problemas y cuestiones. Necesitamos cuatro semanas.
Pero Bill y Jalil se mantuvieron firmes. “No, realmente tiene que ser viernes. ¿Puedes al
menos intentarlo?
Luego, 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. Había otros problemas también. Pero gradualmente, después de
unas pocas semanas más, conseguimos 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 en sus manos. Tuvieron que contratar un nuevo lote de programadores para tratar de lidiar
con la gran cantidad de problemas que surgían 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 de lo que lo hicieron.
Ciertamente, el líder de nuestro equipo no debería haber cedido a la demanda del viernes.
Y ciertamente debería haber seguido diciendo "no" en lugar de ponerme en línea detrás de
nuestro líder de equipo.
Los profesionales dicen la verdad al poder. Los profesionales tienen el coraje de decir no a sus
jefes.
25
¿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 gerentes anhelan a
alguien que tenga las agallas para decir que no. Es la única forma en que realmente puedes hacer algo.
A DV E R S A R I A L ROLES
Uno de los revisores de este libro realmente odió este capítulo. Dijo que casi lo hizo dejar el libro.
Había construido equipos donde no había relaciones adversarias; los equipos trabajaron juntos en
armonía y sin confrontación.
Estoy feliz por este crítico, pero me pregunto si sus equipos son realmente tan libres de confrontación
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 a través de la confrontación de roles
antagónicos.
Los gerentes son personas con un trabajo que hacer, y la mayoría de los gerentes saben cómo hacer
ese trabajo bastante bien. Parte de ese trabajo es perseguir y defender sus objetivos tan
agresivamente como puedan.
De la misma manera, los programadores también son personas con un trabajo que hacer, y la mayoría
de ellos saben cómo hacer ese trabajo bastante bien. Si son profesionales perseguirán y defenderán
sus objetivos con la mayor agresividad posible .
Cuando su gerente le dice que la página de inicio de sesión debe estar lista para mañana, está
persiguiendo y defendiendo uno de sus objetivos. Él está haciendo su trabajo. Si sabe muy bien que
es imposible completar la página de inicio de sesión para mañana, entonces no está haciendo su trabajo
si dice "Está bien, lo intentaré". La única forma 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 van a llegar al mejor resultado posible.
26
FUNCIONES ADVERSARIALES
El mejor resultado posible es el objetivo que usted y su gerente comparten. El truco es encontrar ese
objetivo, y eso generalmente requiere negociación.
La negociación a veces puede ser agradable.
Mike: “Paula, necesito que la página de inicio de sesión esté lista para mañana”.
Paula: “¡Ay, vaya! ¿Tan pronto? Bueno, está bien, lo intentaré”.
Mike: “Está bien, eso es genial. ¡Gracias!"
Esa fue una pequeña conversación agradable. Se evitó toda confrontación. Ambas partes se fueron
sonriendo. Lindo.
Pero ambas partes se estaban comportando 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 solo miente. Ella podría no pensar en ello
como una mentira. Tal vez ella piensa que realmente lo intentará, y tal vez tiene una pequeña
esperanza de que realmente lo logrará. Pero al final, sigue siendo una mentira.
Mike, por otro lado, aceptó el "lo intentaré" como "sí". Eso es solo una tontería. Debería haber sabido que
Paula estaba tratando de evitar la confrontación, por lo que debería haber presionado el tema diciendo:
“Pareces indeciso. ¿Estás seguro de que puedes hacerlo mañana?
Aquí hay otra conversación agradable.
Paula: “Oh, lo siento Mike, pero me llevará más tiempo que eso”.
Mike: “¿Cuándo crees que puedas hacerlo?”
Paula: "¿Qué tal dentro de dos semanas?"
Mike: (garabatea algo en su diario) “Está bien, gracias”.
Tan agradable como fue, también fue terriblemente disfuncional y completamente 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
Mike, por otro lado, simplemente aceptó la fecha sin dudarlo, como si sus propios objetivos no importaran.
Uno se pregunta si simplemente no va a informarle a su jefe que la demostración del cliente tendrá que
posponerse debido a Paula. Ese tipo de comportamiento pasivoagresivo 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. Intentemos esto.
Paula: “No, Mike, ese 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 la
comercialización del producto se apoderara de los requisitos. Tengo al menos diez días
más de trabajo que hacer en esto. ¿No viste mi estimación actualizada en el wiki?
Mike: (mirando 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 que la página de inicio de sesión
funciona”.
Paula: "¿En 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 lo 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 empresa "Timessquaring" en la parte superior, y el botón de
ayuda y el texto flotante no funcionarán. No almacenará una cookie para recordarte
la próxima vez, y no te impondrá ninguna restricción de permisos. Pero podrá iniciar sesión.
¿Eso servirá?
Mike: "¿Podré iniciar sesión?"
Paula: “Sí, podrás iniciar sesión”.
Mike: "Eso es genial Paula, ¡eres un salvavidas!" (se aleja bombeando el aire y diciendo "¡Sí!")
28
ALTAS APUESTAS
Llegaron al mejor resultado posible. Hicieron esto diciendo que no y luego elaborando una solución que
fuera mutuamente aceptable para ambos. Estaban actuando como profesionales. La conversación fue un
poco contradictoria y hubo algunos momentos incómodos, pero eso es de esperar cuando dos personas
persiguen objetivos que no están perfectamente alineados.
¿QUÉ PASA CON 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. Mi experiencia es que el por qué es mucho menos importante que el hecho. Ese hecho es
que la página de inicio de sesión requerirá dos semanas.
Por qué tardará dos semanas es solo un detalle.
Aún así, saber por qué podría ayudar a Mike a comprender y, por lo 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,
tales explicaciones pueden ser útiles. Por otro lado, Mike podría estar en desacuerdo con la conclusión.
Mike podría decidir que Paula lo estaba haciendo todo mal. Él podría decirle que no necesita todas esas
pruebas, o todas esas revisiones, o que podría omitir el paso 12. Proporcionar demasiados detalles puede
ser una invitación para la microgestión.
CASO ALTO ESTADO
El momento más importante para decir no es cuando hay más en juego. Cuanto más alto es lo que está
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 que
pueda. Y eso a menudo significa decir que no.
Don (Director de Desarrollo): “Entonces, nuestra estimación actual para la finalización del proyecto
Golden Goose es dentro de doce semanas a partir de hoy, con una incertidumbre de
más o menos cinco semanas”.
Charles (CEO): (se sienta deslumbrante durante quince segundos mientras su rostro se enrojece)
¿Pretendes sentarte ahí y decirme que tal vez nos falten diecisiete semanas para el parto?
29
Don: "Eso es posible, sí".
Charles: (se levanta, Don se levanta un segundo después) “¡Maldita sea, Don! ¡Esto se
suponía que debía hacerse hace tres semanas! Tengo a Galitron llamándome
todos los días preguntándome dónde está su sistema de frakking.
¿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, Christ Chuck, ¡recortaste mi personal en un
veinte por ciento! ¿Le dijiste a Galitron que llegaríamos tarde?
Charles: “Sabes muy bien que no lo hice. No podemos darnos el lujo de perder ese orden, Don.
(Charles hace una pausa, su rostro se pone blanco) Sin Galitron, estamos realmente
perdidos. Lo sabes, ¿no? Y ahora con este retraso, me temo. . . ¿Qué le diré a
la junta? (Lentamente se vuelve a sentar 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á lanzamientos provisionales.
Quieren hacer la instalación una vez y terminar con ella. Simplemente no puedo
hacer eso 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 a tu equipo y quédate con este proyecto.
Moviente. Tengo algunas llamadas telefónicas muy difíciles que hacer”.
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 al
tablero). Pero si Don no se hubiera mantenido firme, esas llamadas podrían haberse retrasado
aún más.
SER UN “ PROVEEDOR DE EQUIPO ”
Todos hemos escuchado lo importante que es ser un “jugador de equipo”. Ser un jugador de equipo
significa jugar en tu posición lo mejor que puedas y ayudar a tus compañeros de equipo cuando se
encuentran en un aprieto. Un jugador de equipo se comunica con frecuencia, está atento a sus
compañeros de equipo y ejecuta sus propias responsabilidades lo mejor posible.
30
SER UN “ JUGADOR DE EQUIPO”
Un jugador de equipo no es alguien que dice que sí todo el tiempo. Considere este escenario:
Paula: “Mike, tengo esas estimaciones para ti. El equipo está de acuerdo en que estaremos listos
para dar una demostración en unas ocho semanas, más o menos una semana”.
Mike: “Paula, ya programamos la demostración para dentro de seis semanas”.
Paula: “¿Sin saber de nosotros primero? Vamos Mike, no puedes empujar eso
sobre nosotros.”
Mike: "Ya está hecho".
Paula: (suspiro) “Está bien, mire, volveré con el equipo y averiguaré 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, elabore el mejor plan que pueda y hágamelo saber.
mañana."
Paula: “Eso lo puedo hacer”.
Mike: “¿No hay algo que puedas hacer para traer esta fecha? Tal vez
hay una forma de trabajar de forma más inteligente y ser creativo”.
Paula: “Todos somos bastante creativos, Mike. Tenemos un buen manejo de la
problema, y la fecha será ocho o nueve semanas, no seis”.
Mike: “Podrías trabajar horas extras”.
Paula: “Eso solo nos hace ir más lentos, Mike. Recuerda el desastre que hicimos
¿La última vez que ordenamos horas extras?
Mike: "Sí, pero eso no tiene que 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 características 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 negando con la cabeza.)
Más tarde, en la reunión de estrategia del Director...
31
Don: “Está bien, Mike, como sabes, el cliente vendrá para una demostración en seis semanas.
Esperan ver que todo funcione”.
Mike: “Sí, y estaremos listos. Mi equipo se está rompiendo el trasero con esto y vamos a
hacerlo. Tendremos que trabajar un poco de tiempo extra y ser bastante creativos,
¡pero lo haremos realidad!”.
Don: "Es genial que usted y su personal sean tan jugadores de equipo".
¿Quiénes eran los verdaderos jugadores del equipo en este escenario? Paula estaba jugando para el
equipo, porque representaba lo que podía y no podía hacerse lo mejor que podía. Ella defendió
agresivamente su posición, a pesar de las persuasiones y persuasiones de Mike. Mike estaba
jugando en un equipo de uno. Mike es para Mike. Claramente no está en el equipo de Paula porque
la comprometió con algo que ella explícitamente dijo 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 con el plazo de seis
semanas. Mike no es malo; simplemente tiene demasiada confianza en su capacidad para
hacer 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 intento.
¿Quizás no te gusta esa idea? Tal vez pienses que intentarlo es algo positivo. Después de todo,
¿Habría Colón descubierto América si no lo hubiera intentado?
La palabra intentar tiene muchas definiciones. La definición con la que estoy en desacuerdo 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 podría aplicar, entonces ella y su equipo no deben
haber estado aplicando todo su esfuerzo antes. Deben haber tenido algún esfuerzo en reserva.1
1. Como Foghorn Leghorn: "Siempre mantengo mis plumas numeradas para una emergencia de este tipo".
32
La promesa de intentarlo es admitir que se ha estado reteniendo, que tiene una reserva de
esfuerzo adicional que puede aplicar. La promesa de intentarlo es admitir que la meta se puede
lograr mediante la aplicación de este esfuerzo adicional; además, es un compromiso de aplicar
ese esfuerzo extra para lograr la meta. Por lo tanto, al prometer intentarlo, te comprometes
a tener éxito. Esto pone la carga sobre ti.
Si su "intento" no conduce al resultado deseado, habrá fracasado.
¿Tienes una reserva extra de energía que has estado reteniendo? Si aplica estas reservas,
¿será capaz de cumplir la meta? O, al prometer intentarlo, ¿simplemente te estás preparando
para el fracaso?
Al prometer intentarlo, estás prometiendo cambiar tus planes. Después de todo, los planes
que tenías eran insuficientes. Al prometer intentarlo, está diciendo que tiene un nuevo plan.
¿Cuál es ese nuevo plan? ¿Qué cambio harás en tu comportamiento?
¿Qué cosas diferentes vas a hacer porque ahora estás “intentando”?
Si no tienes un nuevo plan, si no cambias tu comportamiento, si haces todo exactamente
como lo hubieras hecho antes de prometer “intentar”, ¿qué significa intentar?
Si no está reteniendo algo de energía en reserva, si no tiene un nuevo plan, si no va a cambiar
su comportamiento y si está razonablemente seguro de su estimación original, entonces
prometer intentarlo es fundamentalmente deshonesto. . estas 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ó. Nunca sugirió que podría haber algún esfuerzo
adicional, algún plan nuevo o algún cambio en el comportamiento que pudiera reducir esa
incertidumbre.
Tres semanas después …
Mike: "Paula, la demostración es en tres semanas y los clientes exigen que
la carga de archivos funcione".
Paula: "Mike, eso no está en la lista de características que acordamos".
33
Mike: “Lo sé, pero lo están exigiendo”.
Paula: “OK, eso significa que Single Signon o Backup tendrán que
ser eliminado de la demostración”.
Mike: “¡Absolutamente no! ¡Están esperando ver que esas funciones también funcionen!”
Paula: “Entonces, están esperando ver todas las funciones funcionando. ¿Es eso lo que
me estás diciendo? Te dije que eso no iba a suceder”.
Mike: “Lo siento, Paula, pero el cliente simplemente no cederá en esto. Ellos
Quieres verlo todo."
Paula: “Eso no va a pasar, Mike. Simplemente no lo es.
Mike: "Vamos, Paula, ¿no pueden al menos intentarlo?"
Paula: “Mike, podría intentar levitar. Podría intentar cambiar el plomo por oro.
Podría intentar cruzar a nado el Atlántico. ¿Crees que tendría éxito?
Mike: “Ahora no estás siendo razonable. No estoy pidiendo lo imposible”.
Paula: “Sí, Mike, lo eres”.
(Mike sonríe, asiente y se da vuelta para irse.)
Mike: “Tengo fe en ti Paula; Sé que no me defraudará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. Ella sospecha que Mike no le está diciendo a Don
sobre sus estimaciones. Podía dejar que Mike caminara por el final del precipicio.
Ella podría asegurarse de que las copias de todos los memorandos apropiados estuvieran
archivados, de modo que cuando ocurra el desastre pueda mostrar lo que le dijo a Mike y cuándo
le dijo. Esto es agresión pasiva. Acababa de dejar que Mike se ahorcara.
O bien, podría tratar de evitar el desastre comunicándose directamente con Don.
Esto es arriesgado, sin duda, pero también es de lo que realmente se trata ser un jugador de equipo.
Cuando un tren de carga se le acerca y usted es el único que puede verlo, puede salirse de la vía en
silencio y ver cómo atropellan a todos los demás, o puede gritar “¡Tren! ¡Fuera de la pista!
34
Dos días después …
Paula: “Mike, ¿le has contado a Don sobre mis estimaciones? ¿Le ha dicho a la
cliente que la demostración no tendrá la función de carga de archivos funcionando?”
Mike: “Paula, dijiste que harías que eso funcionara para mí”.
Paula: “No, Mike, no lo hice. Te dije que era imposible. Aquí tiene una copia del
memorándum que le envié después de nuestra charla.
Mike: "Sí, pero ibas a intentarlo de todos modos, ¿verdad?"
Paula: “Ya tuvimos esa discusión Mike. ¿Recuerdas, oro y plomo?
Mike: (suspira) “Mira, Paula, tienes que hacerlo. Sólo tienes que. Por favor, haz lo que sea
necesario, pero solo tienes que hacer que esto suceda por mí”.
Paula: “Mike. Te equivocas. 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 me pasaría por alto, no harías eso".
Paula: “No quiero a Mike, pero lo haré si me obligas”.
Mike: “Ay, Paula. . .”
Paula: “Mira, Mike, las funciones no estarán listas a tiempo para la demostración. Tienes
que meterte esto en la cabeza. Deja de tratar de convencerme de que trabaje más
duro. Deja de engañarte pensando que de alguna manera voy a sacar un conejo
de un sombrero. Enfréntate al hecho de que tienes que decírselo a Don, y tienes
que decírselo hoy”.
Mike: (Ojos muy abiertos) "¿Hoy?"
Paula: “Sí, Mike. Hoy. Porque mañana espero tener una reunión.
contigo y Don sobre qué funciones incluir en la demostración. Si esa reunión no
ocurre mañana, me veré obligado a ir a ver a Don yo mismo. Aquí hay una copia
del memorándum que explica precisamente eso”.
Mike: "¡Solo te estás cubriendo el trasero!"
Paula: “Mike, estoy tratando de cubrir el trasero de ambos . ¿Te imaginas la debacle si el
cliente viene aquí esperando una demostración completa y no podemos entregarla?
¿Qué pasa al final con Paula y Mike? Te dejo a ti que averigües las posibilidades. La cuestión es
que Paula se ha comportado de forma muy profesional. Ella ha dicho que no en todos los
momentos correctos y en todas las formas correctas. Ella dijo que no cuando la empujaron
35
para modificar sus estimaciones. Ella dijo que no cuando fue manipulada, engatusada y suplicada.
Y, lo más importante, dijo que no al autoengaño y la inacción de Mike. Paula estaba jugando para el
equipo. Mike necesitaba ayuda y ella usó 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 saludables se esfuerzan por
encontrar una manera de decir que sí. El gerente y los desarrolladores en equipos bien administrados
negociarán entre sí hasta que lleguen a un plan de acción acordado mutuamente.
Pero, como hemos visto, a veces la única forma de obtener el sí correcto es no tener miedo,
así que diga no.
Considere la siguiente historia que John Blanco publicó en su blog.2 Se reproduce aquí
con permiso. Mientras lo lee, pregúntese cuándo y cómo debería haber dicho que no.
¿ ES IMPOSIBLE UN CÓDIGO BUENO ? _
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 en 3D.
Y cuando llega al circuito profesional, comienza su búsqueda interminable para escribir código de
calidad comercial, fácil de mantener y "perfecto" 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 codificación de la perfección. No tengo ningún problema en iniciar una discusión de una hora
sobre por qué la elección de la jerarquía de herencia de mi socio de XP es incorrecta: que HASA es
mejor que ISA 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. http://raptureinvenice.com/?p=63
36
La propuesta de proyecto típica
Como desarrollador por contrato a tiempo completo (y a tiempo parcial), paso mis días (y noches) desarrollando
aplicaciones móviles para clientes. Y lo que he aprendido durante los muchos años que he estado 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 persiga ese diseño de software perfecto como yo. Es la ejecución la que encuentro más esquiva, y no por la
razón que crees.
Aquí, déjame contarte una historia.
Hacia fines del año pasado, una empresa bastante conocida presentó una RFP (Solicitud de propuesta) para que
se construyera una aplicación para ellos. Son un gran minorista, pero en aras del anonimato llamémoslos Gorilla Mart. Dicen
que necesitan crear una presencia en el iPhone y que les gustaría una aplicación producida para ellos antes del Black Friday.
¿La captura? 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 está tardando dos semanas en aprobar aplicaciones. (Ah, los buenos viejos tiempos). Entonces, espera, esta
aplicación tiene que estar escrita en . . . ¡¿¡¿DOS SEMANAS?!?!
Sí. Tenemos dos semanas para escribir esta aplicación. Y, desafortunadamente, hemos ganado la licitación. (En
los negocios, la importancia del cliente es importante). Esto va a suceder.
“Pero está bien”, dice el Ejecutivo #1 de Gorilla Mart. “La aplicación es simple. Solo 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 le daremos los gráficos. ¡Probablemente puedas, cuál es la palabra, sí, codificarlo!”
Gorilla Mart Executive #2 interviene. “Y solo necesitamos un par de cupones que el usuario pueda mostrar en la
caja registradora. La aplicación será desechable. Saquémoslo por la puerta y luego, para la Fase II, haremos
algo más grande y mejor desde cero”.
Y luego está sucediendo. A pesar de años de recordatorios constantes de que cada función que un cliente solicita siempre
será más compleja de escribir que de explicar, vaya por ella. Realmente crees que esta vez realmente se puede hacer en dos
semanas. ¡Sí! ¡Podemos hacer esto! ¡Esta vez es diferente!
Son solo algunos gráficos y una llamada de servicio para obtener la ubicación de una tienda. XML! Sin sudar. Podemos
hacer esto. ¡Estoy bombeado! ¡Vamos!
Solo toma un día para que tú y la realidad se vuelvan a conocer.
Yo: Entonces, ¿puede darme la información que necesito para llamar al servicio web de ubicación de su tienda?
El Cliente: ¿Qué es un servicio web?
A mí: …………
continúa
37
Y así fue 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. Es generado por código
Java. Ixno con la APIay. Y para empezar, está alojado por un socio estratégico de Gorilla Mart.
Ingrese el nefasto "tercero".
En términos de clientes, un “tercero” es similar a Angelina Jolie. A pesar de la promesa de que podrás tener una
conversación esclarecedora durante una buena comida y, con suerte, conectarte después... lo siento, no sucederá. Vas
a tener que fantasear con eso mientras te ocupas de los negocios tú mismo.
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 la 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 de PHP e integrarlos juntos— . . . ¿Qué?
¿Quieren que me encargue del control de calidad también?
Para compensar el trabajo extra, la codificación tendrá que ser un poco más rápida. Olvida esa fábrica abstracta. Use
un bucle for grande y gordo en lugar del compuesto, ¡no hay tiempo!
El buen código se ha vuelto imposible.
Dos semanas para completar
Déjame decirte que esas 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 sería el período de tiempo). En última
instancia, realmente tenía ocho días para hacer las cosas. La primera semana trabajé 74 horas y la semana siguiente. . .
Dios . . . Ni siquiera recuerdo, ha sido erradicado de mis sinapsis.
Probablemente sea algo bueno.
Pasé esos ocho días escribiendo código en una 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 constantes de
definición y luego, ¡jadeo!, volviendo a escribirlas) y absolutamente ¡NINGUNA prueba unitaria! (¿Quién necesita
barras rojas en un momento como este? ¡Simplemente me desmotivaría!)
Era un código bastante malo y nunca tuve tiempo de refactorizar. Sin embargo, teniendo en cuenta el marco
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, solo espera, se pone mejor.
Mientras le daba los toques finales a la aplicación (los toques finales eran escribir la totalidad del código del servidor),
comencé a mirar el código base y me pregunté si tal vez valía la pena.
La aplicación se hizo después de todo. ¡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
no ha visto la aplicación, ¡pero cree que sería una gran idea! También queremos un sistema de informes para
obtener esos correos electrónicos del servidor. Uno que es agradable y no demasiado caro.
(Espera, esa última parte fue Monty Python). Hablando de cupones, deben poder caducar después de una
cantidad de días que especificamos. Oh y …"
Demos un paso atrás. ¿Qué sabemos acerca de lo que es un buen código? Un buen código debe ser
extensible. Mantenible. Debe prestarse a la modificación. Debería leerse como prosa.
Bueno, este no era un buen código.
Otra cosa. Si quieres ser un mejor desarrollador, siempre debes tener presente inevitablemente esto: El cliente
siempre extenderá el plazo. Siempre querrán más características. Siempre querrán un cambio, TARDE. Y aquí está
la fórmula de qué esperar:
(# de Ejecutivos)2
+ 2 * # de Nuevos Ejecutivos
+ # de niños de Bob
= DÍAS AGREGADOS EN ÚLTIMO MINUTO
Ahora, los ejecutivos son gente decente. Creo. Ellos proveen para su familia (suponiendo que Satanás haya aprobado
que tengan una). Quieren que la aplicación tenga éxito (¡tiempo de promoción!). El problema es que todos
quieren reclamar directamente el é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 terminamos la función de correo
electrónico. Y luego me derrumbé por el agotamiento.
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 ti que la
aplicación llegue a tiempo. La tarde en que doblé la aplicación, envié un correo electrónico con la compilación final a
todas las partes interesadas, ejecutivos (¡silbado!), gerentes, etc.
"¡SE HACE! ¡LES TRAIGO V1.0! ALABADO TU NOMBRE.” Presioné Enviar, me recosté en mi silla y, con una
sonrisa de suficiencia, comencé a fantasear con cómo la compañía me subiría a sus hombros y encabezaría
una procesión por la calle 42 mientras me coronaban como "Mejor desarrollador Evar". Como mínimo, mi cara estaría
en toda su publicidad, ¿verdad?
Gracioso, 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ía pasado a lo siguiente.
¿Crees que miento? Mira esto. Empujé a la tienda de Apple sin completar una descripción de la aplicación.
Había solicitado uno de Gorilla Mart, y no me respondieron y no había tiempo para esperar. (Ver párrafo anterior.)
Los escribí de nuevo. Y otra vez. Obtuve
continúa
39
algo de nuestra propia gestión en él. Dos veces escuché de nuevo y dos veces me dijeron: "¿Qué necesitabas de
nuevo?" ¡NECESITO LA DESCRIPCIÓN DE LA APLICACIÓN!
Una semana después, Apple comenzó a probar la aplicación. Este suele ser un momento de alegría, pero en cambio
fue un momento de terror 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 puedo imaginar: "A la aplicación le falta una
descripción de la aplicación". Funcionalmente perfecto; sin descripción de la aplicación. Y por eso Gorilla Mart
no tenía preparada 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 con una semana de tiempo. Nos lo dieron una hora después del rechazo,
aparentemente esa fue la señal para poner manos a la obra.
Si estaba molesto antes, me pondría furioso una semana y media después de eso. Verás, todavía no nos habían
conseguido datos reales. Los productos y cupones en el servidor eran falsos. Imaginario.
El código del cupón era 1234567890. Ya sabes, tonterías falsas. (Bologna se deletrea tonterías 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é con horror abyecto y 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é el 911. Pero luego llamé a
Gorilla Mart y dije: "¡NECESITO DATOS!" Y nunca olvidaré la respuesta:
Oh, hola Juan. Tenemos un nuevo VP y hemos decidido no lanzarlo. 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 podrían ingresar a un Gorilla Mart con un cupón de iPhone
falso. Chico, 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 nunca se lanzó en primer lugar.
Resultado ? Rápido para completar, lento para comercializar
La lección de la historia es que sus partes interesadas, ya sea un cliente externo o una administración interna,
han descubierto cómo hacer que los desarrolladores escriban código rápidamente. ¿Efectivamente? No.
¿Rápidamente? Sí. Así es como funciona:
• Dígale al desarrollador que la aplicación es simple. Esto sirve para presionar a los
equipo de desarrollo en un falso estado de ánimo. También hace que los desarrolladores
comiencen a trabajar antes, por lo que...
40
CÓDIGO IMPOSIBLE
• Agregue funciones culpando al equipo por no reconocer su necesidad. En este caso, el
contenido codificado iba a requerir actualizaciones de la aplicación para cambiar.
¿Cómo podría no darme cuenta de eso? Lo hice, pero me habían hecho una promesa
falsa antes, por eso. O un cliente contratará a "un tipo nuevo" que reconoce que
hay una 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...
• Empuje 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?)
con un par de días para la fecha límite. ¿Por qué decirles que puede aplazar la fecha más
mientras están siendo tan productivos? ¡Aprovéchate de ello! Y así sigue, se añaden
unos días, se añade 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 terrible código. 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
de reducir los costos de desarrollo está volviendo obsoleto el buen código. Como desarrolladores, nos van a preguntar/
dijo/estafó para que escribiera el doble del código en la mitad del tiempo si no tenemos cuidado.
CÓDIGO I POSIBLE
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 solo el código el que sufrió
en su historia de disfunción. Era su familia, su empleador, su cliente y los usuarios.
Todos perdidos3 en esta aventura. Y perdieron por falta de profesionalismo.
Entonces, ¿quién estaba actuando de manera poco profesional? John deja en 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 su comportamiento malo? No me parece.
3. Con la posible excepción del empleador directo de John, aunque apuesto a que también perdieron.
41
La gente de Gorilla Mart quería 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
proporcionar esa opción. Entonces, ¿cómo puedes culparlos?
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 que no sabía lo que estaba haciendo otra parte. Pero todo eso
debería haber sido esperado. John incluso lo admite cuando dice: “A pesar de los años de
constantes recordatorios de que cada característica que un cliente solicita siempre será más
compleja de escribir que de explicar . . .”
Entonces, si el culpable no fue Gorilla Mart, ¿entonces quién?
Tal vez fue el empleador directo de John. John no dijo esto explícitamente, pero hubo una pista
cuando dijo, entre paréntesis: "En los negocios, la importancia del cliente es importante".
Entonces, ¿el empleador de John hizo promesas irrazonables a Gorilla Mart?
¿Presionaron a John, directa o indirectamente, para que hiciera realidad esas promesas? John
no dice esto, así que solo podemos preguntarnos.
Aun así, ¿dónde está la responsabilidad de John en todo esto? Le echo la culpa directamente a
John. John es 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.
Juan es el que trabajaba jornadas de 20 horas y semanas de 90 horas. John es quien se sustrajo
de su familia y de su vida para cumplir con este plazo.
¿Y por qué Juan hizo esto? Él nos dice en términos muy claros: “Presioné Enviar, me recosté en
mi silla y con una sonrisa de suficiencia comencé a fantasear con cómo la compañía me subiría
sobre sus hombros y encabezaría una procesión por la calle 42 mientras me coronaban como “El
mejor”. Desarrollador Evar”. En resumen, John estaba tratando de ser un héroe. Vio su oportunidad
de recibir elogios, y fue a por ella. Se inclinó y agarró el anillo de latón.
Los profesionales suelen ser héroes, pero no porque intenten serlo. Los profesionales se convierten
en héroes cuando hacen un trabajo bien, 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
CÓDIGO IMPOSIBLE
John debería haber dicho que no al plazo original de dos semanas. O si no, debería haber dicho que no cuando
descubrió que no había servicio web. Debería haber dicho que no a la solicitud de registro de correo electrónico
y vencimiento del cupón. Debería haber dicho que no a cualquier cosa que requiriera horribles horas extras y
sacrificios.
Pero, sobre todo, John debería haber dicho que no a su propia decisión interna de que la única forma de
terminar este trabajo a tiempo era armar un gran lío. Observe lo que dijo John sobre el buen código y las pruebas
unitarias:
“Para compensar el trabajo adicional, la codificación tendrá que ser un poco más rápida. Olvida esa fábrica
abstracta. Use un bucle for grande y gordo en lugar del compuesto, ¡no hay tiempo!
Y otra vez:
“Pasé esos ocho días escribiendo código en una 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 definir constantes y luego, ¡jadeo!, volviendo a escribirlas) y absolutamente ¡NINGUNA prueba unitaria! (¿Quién
necesita barras rojas en un momento como este? ¡Simplemente me desmotivaría!)”
Decir que sí a esas decisiones fue el verdadero quid del fracaso. John aceptó que la única forma de tener éxito
era comportarse de manera poco profesional, por lo que cosechó la recompensa adecuada.
Eso puede sonar duro. No está destinado 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 tenemos que darnos cuenta es que decir que sí a abandonar nuestras disciplinas
profesionales no es la forma de resolver los problemas. Abandonar esas disciplinas es la forma de crear
problemas.
Con eso, finalmente puedo responder la pregunta inicial de John:
“¿Es imposible un buen código? ¿La profesionalidad es imposible?”
Respuesta: digo que no.
43
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 ideáramos un nuevo tipo de producto e
inventamos "La recepcionista electrónica", o ER para abreviar.
45
CAPÍTULO 3 DECIR SÍ
Todos ustedes saben lo que es ER. ER es una de esas máquinas horribles que contesta el teléfono en
las empresas y te hace todo tipo de preguntas descerebradas 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 marque el nombre
de la persona que desea. Le pediría que pronunciara su nombre y luego llamaría a la persona en
cuestión. Anunciaría la llamada y preguntaría si debería ser aceptada. Si es así, conectaría la llamada
y la dejaría.
Podrías decirle a Urgencias dónde estabas. Podrías darle varios números de teléfono para intentarlo. Entonces,
si estuviera en la oficina de otra persona, la sala de emergencias podría encontrarlo. Si estuviera en su
casa, la sala de emergencias podría encontrarlo. Si estuviera en una ciudad diferente, ER podría encontrarlo.
Y, al final, si Urgencias no pudiera encontrarte, necesitaría un mensaje. Ahí es donde entró el correo de
voz.
Por extraño que parezca, Teradyne no pudo descubrir cómo vender ER. El proyecto se quedó sin
presupuesto y se transformó en algo que sabíamos cómo vender: CDS, The Craft Dispatch System,
para enviar a los reparadores de teléfonos a su próximo trabajo. Y Teradyne también retiró la patente
sin decírnoslo. (!) El actual titular de la patente presentó la solicitud tres meses después que nosotros.
(!!)1
Mucho después de la transformación de ER en CDS, pero mucho antes de que me enterara de que se
había retirado la patente. Esperé en un árbol al director general de la empresa. Teníamos un gran
roble afuera del frente del edificio. Me subí y esperé a que su Jaguar se detuviera. Lo encontré en la
puerta y le pedí unos minutos. Él obedeció.
Le dije que realmente necesitábamos volver a poner en marcha el proyecto de Urgencias. Le dije
que estaba seguro de que podría hacer dinero. Me sorprendió diciendo: “Está bien, Bob, elabora
un plan. Muéstrame cómo puedo ganar dinero. Si lo hace, y lo creo, volveré a poner en marcha la
sala de emergencias”.
No esperaba eso. Esperaba que dijera: “Tienes razón, Bob. Voy a empezar ese proyecto de nuevo, y
voy a encontrar la manera de hacer dinero en
1. No es que la patente valiera dinero para mí. Lo había vendido a Teradyne por $ 1, según mi empleo
contrato (y no conseguí el dólar).
46
UN LENGUAJE DE COMPROMISO
él." Pero no. Me devolvió la carga. Y era una carga sobre la que era ambivalente. Después de todo, yo
era un tipo de software, no un tipo de dinero. Quería trabajar en el proyecto de Urgencias, no ser
responsable de pérdidas y ganancias. Pero no quería mostrar mi ambivalencia. Así que le agradecí y
salí de su oficina con estas palabras:
“Gracias Russ. Estoy comprometido . . . Supongo."
Con eso, permítanme presentarles a Roy Osherove, quien les dirá cuán patética fue esa declaración.
AL LENGUAJE DEL 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 hasta el final de estas tres etapas?
• Le preguntas al técnico de TI por qué la red es tan lenta y te responde: “Sí. Realmente necesitamos
algunos enrutadores nuevos”. Y sabes que nunca pasará nada en esa categoría.
• Le pide a un miembro del equipo que ejecute algunas pruebas manuales antes de verificar el
código fuente y él responde: “Claro. Espero llegar a él al final del día”.
Y de alguna manera siente que tendrá que preguntar mañana si realmente se realizó alguna prueba
antes del checkin.
• Su jefe entra en la habitación y murmura: "Tenemos que movernos más rápido".
Y sabes que realmente quiere decir que TÚ tienes que moverte más rápido. Él no va a hacer nada al
respecto.
47
Hay muy pocas personas que, cuando dicen algo, lo dicen en serio y luego lo hacen. Hay algunos que
dicen cosas y las quieren decir , pero nunca lo hacen. Y hay muchas más personas que prometen
cosas y ni siquiera tienen la intención de cumplirlas. ¿Alguna vez escuchó a alguien decir: "Hombre,
realmente necesito perder algo de peso", y sabía que no iban a hacer nada al respecto? Pasa todo
el tiempo.
¿Por qué seguimos teniendo esa extraña sensación de que, la mayoría de las veces, las personas no
están realmente comprometidas 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 en la esquina, que puede terminar esa tarea de dos semanas
en una semana, pero no deberíamos.
En lugar de confiar en nuestras tripas, podemos usar algunos trucos relacionados con el lenguaje para
tratar de averiguar si las personas realmente quieren decir lo que dicen. Y cambiando lo que decimos,
podemos empezar a hacernos cargo de los pasos 1 y 2 de la lista anterior por nuestra cuenta. Cuando
decimos que nos comprometeremos con algo, y tenemos que decirlo en serio .
RECONOCIENDO EL COMPROMISO DE L AC KOF
Deberíamos mirar el lenguaje que usamos cuando nos comprometemos a hacer algo, como el signo
revelador de lo que vendrá. En realidad, es más una cuestión de buscar palabras específicas en lo
que decimos. Si no puede encontrar esas pequeñas palabras mágicas, es probable que no lo digamos
en serio o que no creamos que sea factible.
Aquí hay algunos ejemplos de palabras y frases para buscar que son signos reveladores de falta de
compromiso:
• Necesidad/debería. "Tenemos que hacer esto". "Necesito perder peso." "Alguien
debería hacer que eso suceda”.
• Deseo esperanza. “Espero terminar esto para mañana”. “Espero que podamos encontrarnos de
nuevo algún día”. “Ojalá tuviera tiempo para eso”. “Ojalá esta computadora fuera más rápida”.
• Vamos. (no seguido de "Yo . . .") "Veámonos alguna vez". "Terminemos con esto".
48
A medida que comience a buscar estas palabras, verá que comienza a detectarlas en casi todas
partes a su alrededor, e incluso en las cosas que le dice a los demás.
Descubrirá que tendemos a estar muy ocupados sin asumir la responsabilidad de las cosas.
Y eso no está bien cuando usted o alguien más confía en esas promesas como parte del trabajo. Sin
embargo, ha dado el primer paso: comience a reconocer la falta de compromiso a su
alrededor y en usted.
Escuchamos 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 o asumen que las cosas están
fuera de “mis” manos o no asumen la 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 la misma.
La verdad real es que usted, personalmente, SIEMPRE tiene algo que está bajo su
control, por lo que siempre hay algo a lo que te puedes comprometer por completo.
El ingrediente secreto para reconocer el compromiso real es buscar oraciones que suenen así: Lo
haré. . . por . . . (ejemplo: terminaré esto para el martes).
¿Qué tiene de importante esta oración? Está declarando un hecho sobre algo que USTED hará con un
tiempo final claro. No estás hablando de nadie más que de ti mismo.
Estás hablando de una acción que tomarás . No "posiblemente" lo tomará, o "podría llegar a él"; lo
lograrás .
No hay (técnicamente) salida de este compromiso verbal. Dijiste que lo harías y ahora solo es posible
un resultado binario: lo haces o no lo haces.
Si no lo hace, la gente puede hacer que cumpla 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ás).
Aterrador, ¿no?
49
Estás asumiendo toda la responsabilidad de 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 lo
obliga a hacer algo.
Has cambiado el lenguaje que usas por un lenguaje de compromiso, y eso te ayudará a superar las
próximas dos etapas: entenderlo y cumplirlo.
Aquí hay una serie de razones por las que es posible que no lo digas en serio , o que no lo sigas, con
algunas soluciones.
No funcionaría porque confío en la persona X para hacer esto.
Solo puedes comprometerte con cosas sobre las que tienes control total . Por ejemplo, si su objetivo
es terminar un módulo que también depende de otro equipo, no puede comprometerse a terminar el
módulo con total integración con el otro equipo. Pero puede comprometerse con acciones específicas
que lo llevarán a su 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únase al menos tres veces esta semana con el encargado de la construcción para asegurarse de que su
los cambios funcionan bien en el sistema de compilación de la empresa.
• Cree su propia compilación personal que ejecute sus pruebas de integración para el
módulo.
¿Ver la diferencia?
Si el objetivo final depende de otra persona, debe comprometerse con acciones específicas que lo
acerquen al objetivo final.
50
No funcionaría porque realmente no sé si se puede hacer.
Si no se puede hacer, aún puede comprometerse con acciones que lo acercarán al objetivo.
¡Descubrir si se puede hacer puede ser una de las acciones a las que comprometerse!
En lugar de comprometerse a corregir los 25 errores restantes antes del lanzamiento (lo que
puede no ser posible), puede comprometerse con estas acciones específicas que lo acercan 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.
• Dedique todo el tiempo que tenga esta semana a tratar de corregir cada error.
No funcionaría porque a veces simplemente no lo logro.
Eso pasa. Algo inesperado puede suceder, y así es la vida. Pero todavía quieres estar a la altura de
las expectativas. En ese caso, es hora de cambiar las expectativas, tan pronto como sea posible.
Si no puede hacer su compromiso, lo más importante es levantar una bandera roja lo antes posible
a quienquiera que se haya comprometido.
Cuanto antes levante 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 puede cumplirse, 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 puede llegar tarde y avisarle.
Tal vez puedan encontrar un lugar más cercano para reunirse, o tal vez posponer la reunión.
51
• Si te comprometiste a resolver un error que creías solucionable y en algún momento te das cuenta
de que el error es mucho más espantoso de lo que pensabas, puedes levantar la bandera. Luego,
el equipo puede decidir un curso de acción para hacer ese compromiso (emparejamiento,
aumentar las 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 dice a nadie sobre el problema potencial tan pronto como
sea posible, no le está dando a nadie la oportunidad de ayudarlo a cumplir con su compromiso.
RESUMEN _
Crear un lenguaje de compromiso puede sonar 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 de comunicación cara a cara. Se le tomará como un desarrollador serio que cumple
con su palabra, y esa es una de las mejores cosas que puede esperar en nuestra industria.
~~~
APRENDIENDO CÓMO 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 igual de importante
aprender a decir que sí.
EL OTRO LADO DE “PRUEBA ”
Imaginemos que Peter es el 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 piensa que escribir
la documentación para las modificaciones llevará algunas horas. El lunes por la mañana, su gerente,
Marge, le pregunta por el estado.
Marge: "Peter, ¿tendrás las modificaciones del motor de calificación listas para el viernes?"
Peter: "Creo que eso es factible".
52
APRENDIENDO A DECIR “SI”
Marge: "¿Eso incluirá la documentación?"
Peter: "Trataré de hacer eso también".
Tal vez Marge no puede escuchar el vacilante en las declaraciones de Peter, pero ciertamente no se
está comprometiendo mucho. Marge está haciendo preguntas que exigen respuestas booleanas,
pero las respuestas booleanas de Peter son confusas.
Note el abuso de la palabra intentar. En el último capítulo usamos la definición de "esfuerzo extra"
de intentar. Aquí, Peter está usando la definición de "tal vez, tal vez no".
Peter estaría mejor respondiendo así:
Marge: "Peter, ¿tendrás las modificaciones del motor de calificación listas para el viernes?"
Peter: "Probablemente, pero podría ser el lunes".
Marge: "¿Eso incluirá la documentación?"
Peter: “La documentación me llevará unas cuantas horas más, así que el lunes es posible, pero
podría ser hasta el martes”.
En este caso el lenguaje de Pedro es más honesto. Está describiendo su propia
incertidumbre a Marge. Marge puede ser capaz de lidiar con esa incertidumbre. Por otro lado, ella
podría no hacerlo.
COMPROMETERSE CON LA DISCIPLINA
Marge: “Peter, necesito un sí o un no definitivo. ¿Tendréis el motor de calificación terminado y
documentado para el viernes?”
Esta es una pregunta perfectamente justa para que Marge la haga. Tiene un horario que cumplir y
necesita una respuesta binaria sobre el viernes. ¿Cómo debe responder Pedro?
Peter: “En ese caso, Marge, tendré que decir que no. Lo más pronto que pueda estar seguro
que terminaré con las modificaciones y los documentos el martes”.
Marge: "¿Te comprometes para el martes?"
Pedro: “Sí, lo tendré todo listo el martes”.
53
Pero, ¿y si Marge realmente necesita que las modificaciones y la documentación estén listas para el viernes?
Marge: “Peter, el martes me da un problema real. 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, las modificaciones tienen que ser lo primero, porque generamos los documentos
de la salida 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 el fin de semana.
También podría hacer algunas horas de trabajo el sábado si las cosas tardan más de lo que espera. Entonces,
¿qué debería decirle a Marge?
Peter: "Mira Marge, hay una buena posibilidad de que pueda terminar todo el lunes por la mañana si
dedico algunas horas extra el sábado".
¿Resuelve eso el problema de Marge? No, simplemente cambia las probabilidades, y eso es lo que Peter
necesita decirle.
Marge: "¿Entonces puedo contar con el lunes por la mañana?"
Peter: "Probablemente, pero no definitivamente".
Eso podría no ser lo suficientemente bueno para Marge.
Marge: “Mira, Peter, realmente necesito una definición sobre esto. ¿ Hay alguna forma de
comprometerse a hacer esto antes del lunes por la mañana?
Peter podría verse tentado a romper la disciplina en este punto. Es posible que pueda hacerlo 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
hacerlo más rápido si no ejecuta la suite de regresión completa.
54
APRENDIENDO A DECIR “SI”
Aquí es donde el profesional traza la línea. En primer lugar, Peter simplemente está equivocado
acerca de 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 la suite de regresión completa. Años de
experiencia nos han enseñado que romper las disciplinas solo nos ralentiza.
Pero en segundo lugar, como profesional tiene la responsabilidad de mantener ciertos
estándares. Su código necesita ser probado, y necesita tener pruebas. Su código debe estar
limpio. Y tiene que estar seguro de que no ha 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 haga deben estar subordinados a eso. Así que toda esta línea de razonamiento
necesita abortar.
Peter: “No, Marge, realmente no hay forma de que pueda estar seguro de una fecha antes
del martes. Lo siento si eso estropea tu agenda, pero es solo la realidad a la que
nos enfrentamos”.
Marge: “Maldita sea. Realmente contaba con traer este antes.
¿Estas 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 horario".
En este caso, Marge aceptó la respuesta de Peter y comenzó a buscar otras opciones. Pero,
¿y si se han agotado todas las opciones de Marge? ¿Y si Peter 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 el lunes por la mañana. Es realmente crítico.
¿No hay algo que puedas hacer?
Así que ahora Peter empieza a pensar en trabajar un tiempo extra significativo, y probablemente
la mayor parte del fin de semana. Necesita ser muy honesto consigo mismo sobre su resistencia y
reservas. Es fácil decir que hará mucho los fines de semana, es mucho más difícil reunir la energía
suficiente para hacer un trabajo de alta calidad.
55
Los profesionales conocen sus límites. Saben cuántas horas extras pueden aplicar
efectivamente y saben cuál será el costo.
En este caso, Peter se siente bastante seguro de que unas pocas horas extra durante la semana
y algo de tiempo durante el fin de semana serán suficientes.
Peter: “Está bien, Marge, te diré algo. Llamaré a casa y limpiaré algunos
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 salga 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 que sí a todo lo que se les pide.
Sin embargo, deben 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 haya
dudas sobre lo que han prometido.
56
4 CODIFICACIÓN
En un libro anterior1 escribí mucho sobre la estructura y la naturaleza de Clean Code.
Este capítulo analiza el acto de codificar y el contexto que rodea ese acto.
Cuando tenía 18 años podía escribir razonablemente bien, pero tenía que mirar las teclas.
No podía escribir a ciegas. Así que una tarde pasé unas largas horas frente a un teclado
perforador 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 mal escritas.
1. [Martín09]
57
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.
Me di cuenta, durante esa larga noche, que escribir a ciegas tiene que ver con la confianza. Mis dedos
sabían dónde estaban las llaves, solo tenía que ganar la confianza de que no estaba cometiendo un
error. Una de las cosas que ayudó con esa confianza es que podía sentir cuando estaba cometiendo
un error. Al final de la noche, si cometía un error, lo sabía casi al instante y simplemente expulsaba la
tarjeta sin mirarla.
Ser capaz de detectar sus errores es realmente importante. No solo en escribir, sino en todo. Tener
sentido de error significa que cierras muy rápidamente el ciclo de retroalimentación y aprendes de tus
errores mucho más rápido. He estudiado y dominado varias disciplinas desde ese día en el 029. He
descubierto que en cada caso la clave del 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 propio código; son sobre mi comportamiento, estado de ánimo y actitud
mientras escribo código. Describen mi propio contexto mental, moral y emocional para escribir código.
Estas son las raíces de mi confianza y sentido del error.
Es probable que no esté de acuerdo con todo lo que digo aquí. Después de todo, esto es algo
profundamente personal. De hecho, es posible que discrepe violentamente 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 ser un codificador profesional.
Tal vez, al estudiar y contemplar mi propio entorno personal de codificación, 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 hagas malabarismos con muchos factores competitivos a la vez.
1. Primero, su código debe funcionar. Debes entender qué problema eres.
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 administrar
58
PREPARACIÓN
cada detalle de esa solución sin dejar de ser coherente con el idioma, la plataforma, la
arquitectura actual y todas las verrugas del sistema actual.
2. Su código debe resolver el problema planteado por 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 debe aumentar la rigidez,
fragilidad u opacidad de ese sistema. Las dependencias deben estar bien
administradas. En resumen, su código debe seguir sólidos principios de ingeniería.2
4. Su código debe ser legible por otros programadores. Esto no es simplemente un
cuestión de escribir comentarios bonitos. Más bien, requiere que elabores 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 puede dominar.
Hacer malabarismos con todas estas preocupaciones es difícil. Es fisiológicamente difícil
mantener la concentración y el enfoque necesarios durante largos períodos de tiempo.
Añádase a esto los problemas y distracciones del trabajo en equipo, en una
organización, y los afanes y preocupaciones de la vida cotidiana. La conclusión es que la
oportunidad de distracción es alta.
Cuando no puedas concentrarte y enfocarte lo suficiente, el código que escribas será
incorrecto. Tendrá errores. Tendrá la estructura incorrecta. Será opaco y enrevesado. No
resolverá los problemas reales de los clientes. En resumen, tendrá que ser reelaborado o
rehecho. Trabajar distraído genera desperdicio.
Si está cansado o distraído, no programe. Solo 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 AM
El peor código que he escrito fue a las 3 am. Era el año 1988 y yo trabajaba en una
empresa emergente de telecomunicaciones llamada Clear Communications. Todos
estábamos dedicando largas horas para construir "equidad de sudor". Por supuesto,
todos soñamos con ser ricos.
2. [Martín03]
59
Una tarde muy tarde, o mejor dicho, muy temprano en la mañana, para resolver un problema
de tiempo, hice que mi código se enviara un mensaje a sí mismo a través del sistema de
despacho de eventos (lo llamamos "enviar correo"). Esta fue la solución incorrecta , pero a
las 3 am se veía bastante bien. 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 tan bien conmigo mismo durante las largas horas que trabajaba.
Recuerdo sentirme dedicada. Recuerdo haber pensado que trabajar a las 3 am es lo que hacen
los profesionales serios. ¡Qué equivocado estaba!
Ese código volvió a mordernos 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 errores
de tiempo extraños y bucles de retroalimentación extraños. Nos metíamos en infinitos
bucles de correo cuando un mensaje hacía que se enviara otro, y luego otro,
infinitamente. Nunca tuvimos tiempo de reescribir este taco (eso pensamos), pero siempre
parecíamos tener tiempo para agregar otra verruga o parche para solucionarlo. El cruft 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 cansada o
frustrada, 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, salud y estilo de vida estén ajustados para que pueda dedicar ocho buenas horas al día.
CÓDIGO DE PREOCUPACIÓN
¿Alguna vez se peleó mucho con su cónyuge o amigo y luego trató de codificar? ¿Notaste que
había un proceso en segundo plano corriendo 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 tomas demasiado café o CocaCola Light.
Es una distracción.
Cuando estoy preocupado por una discusión con mi esposa, una crisis de clientes o un niño
enfermo, no puedo mantener la concentración. Mi concentración vacila. Me encuentro con
los ojos en la pantalla y los dedos en el teclado, sin hacer nada. Catatónico.
60
PREPARACIÓN
Paralizado. A un millón de millas de distancia trabajando en el problema en segundo plano
en lugar de resolver el problema de codificación que tengo delante.
A veces me obligaré a pensar en el código. Podría obligarme a escribir una línea o dos. 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,
revolviéndome interiormente con la preocupación de fondo.
He aprendido que este no es momento para 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 probable que nuestros empleadores no 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 registraré. Si tuve una discusión con mi
esposa, la llamaré y hablaré sobre los problemas. Si tengo problemas de dinero, dedicaré tiempo a pensar
en cómo puedo manejar 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 calmar el proceso de
fondo.
Idealmente, el tiempo dedicado a luchar con problemas personales sería 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 debe reservar específicamente tiempo en casa para calmar sus 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 silenciándolas que usar la fuerza bruta para
escribir código que tendrás que desechar más tarde ( o peor, vivir con).
61
LA ZONA DE FLUJO
Mucho se ha escrito sobre el estado hiperproductivo conocido como “flujo”.
Algunos programadores lo llaman "la Zona". Se llame como se llame, seguro que lo conoces.
Es el estado de conciencia de visión de túnel altamente enfocado en el que los programadores
pueden entrar mientras escriben código. En este estado se sienten productivos. En este
estado se sienten infalibles. Y así, desean alcanzar ese estado y, a menudo, miden su
autoestima por la cantidad de tiempo que pueden pasar allí.
Aquí hay un pequeño consejo de alguien que estuvo allí y regresó: Evite la Zona.
Este estado de conciencia no es realmente hiperproductivo y ciertamente no es infalible. En
realidad, es solo un estado meditativo suave en el que ciertas facultades racionales
disminuyen a favor de una sensación de velocidad.
Déjame ser claro sobre esto. Escribirá más código en la Zona. Si está practicando TDD,
recorrerá el ciclo rojo/verde/refactor más rápidamente.
Y sentirás una leve euforia o una sensación de conquista. El problema es que pierde parte
del panorama general mientras está en la Zona, por lo que es probable que tome decisiones
que luego tendrá que volver atrás y revertir. El código escrito en la Zona puede salir más
rápido, pero volverá a visitarlo más.
Hoy en día, cuando siento que me deslizo en la Zona, me alejo por unos minutos.
Aclaro mi mente respondiendo algunos correos electrónicos o mirando algunos tweets. Si está lo suficientemente
cerca para el mediodía, tomaré un descanso para almorzar. Si estoy trabajando en un equipo, encontraré un
compañero de pareja.
Uno de los grandes beneficios de la programación en pareja es que es prácticamente imposible
que una pareja entre en la Zona. La Zona es un estado no 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 de eso hablaremos en otro capítulo.
62
LA ZONA DE FLUJO
MÚSICA
En Teradyne, a finales de los 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 colgado sobre las tejas
del techo desde mi oficina hasta la sala de computadoras.
Tenía un sistema estéreo en mi oficina. Era un viejo tocadiscos, amplificador y parlantes
de piso. Tenía una importante colección de vinilos, incluidos Led Zeppelin, Pink Floyd y...
Bueno, te haces una idea.
Solía encender ese estéreo y luego escribir código. Pensé que ayudó a mi
concentración. Pero estaba equivocado.
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 lloran.
Fue entonces cuando me golpeó. 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.
Tal vez no funcione de esa manera para usted. Tal vez la música te ayude a escribir código.
Conozco a muchas personas que codifican mientras usan auriculares. Acepto que la música
puede ayudarlos, pero también sospecho que lo que realmente está sucediendo es que la
música los está ayudando a ingresar a la Zona.
INTERRUPCIONES _
Visualícese mientras codifica en su estación de trabajo. ¿Cómo respondes cuando alguien
te hace una pregunta? ¿Los golpeas? ¿Eres deslumbrante? ¿Tu lenguaje corporal les dice que
se vayan porque estás ocupado? En resumen, ¿eres grosero?
63
¿O dejas de hacer lo que estás haciendo y ayudas cortésmente a alguien que está atascado? ¿Los
tratas como te gustaría que te trataran a ti si estuvieras atrapado?
La respuesta grosera a menudo proviene de la Zona. Es posible que le moleste que lo arrastren
fuera de la Zona, o puede que le moleste 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, es solo que estás tratando de entender
algo complicado que requiere concentración. Hay varias soluciones para esto.
El emparejamiento puede ser muy útil como una forma de lidiar con las interrupciones. Su compañero
de pareja puede tener 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, 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 que pase
la prueba fallida.
Al final, por supuesto, habrá interrupciones que te distraigan y te hagan perder tiempo. Cuando
sucedan, recuerda que la próxima vez puedes ser tú quien necesite interrumpir a otra persona.
Así que la actitud profesional es una buena voluntad de ser útil.
BLOQUEO DEL ESCRITOR
A veces el código simplemente no viene. A mí me ha pasado esto y he visto que le pasa a otros. 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. Vas a leer tweets.
Revisarás libros, horarios o documentos. Convocarás reuniones. Comenzarás conversaciones
con otros. Harás cualquier cosa para no tener que enfrentarte a esa estación de trabajo y ver
cómo el código se niega a aparecer.
64
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 la preocupación, el miedo y la depresión.
Por extraño que parezca, hay una solución muy simple. Funciona casi siempre. Es fácil de hacer
y puede proporcionarle el impulso para escribir mucho código.
La solución: encontrar un compañero de pareja.
Es asombroso lo bien que funciona esto. Tan pronto como te sientas al lado de otra persona, los
problemas que te bloqueaban se desvanecen. Hay un cambio fisiológico que tiene lugar 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 me libera del bloqueo y me pone en marcha
de nuevo.
Esta no es una solución perfecta. A veces, el cambio dura una hora o dos, solo para ser seguido
por un agotamiento tan severo que tengo que separarme de mi pareja y encontrar algún hueco
para recuperarme. A veces, incluso cuando estoy sentado con alguien, no puedo hacer más
que simplemente estar 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. Aprendí hace mucho tiempo que la
producción creativa depende de la entrada creativa.
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, o poesía, o incluso una novela
romántica. Creo que el problema real es que la creatividad engendra creatividad.
También hay un elemento de escapismo. Las horas que paso lejos de mis problemas
habituales, mientras me estimulan activamente las ideas desafiantes y creativas, dan como
resultado una presión casi irresistible para crear algo yo mismo.
sesenta y cinco
No todas las formas de entrada creativa funcionan para mí. Ver la televisión no suele ayudarme
a crear. Ir al cine es mejor, pero solo un poco. Escuchar música no me ayuda a crear código,
pero sí me ayuda a crear presentaciones, charlas y videos. De todas las formas de
aporte creativo, nada funciona mejor para mí que la buena 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 prefería ningún
terminal en particular ni ninguna aplicación en particular. No importaba lo que el usuario había
estado haciendo antes del congelamiento. Un minuto la terminal funcionaba bien, y al
minuto siguiente estaba irremediablemente congelada.
Llevó semanas 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
tendría que dejar de trabajar y esperar hasta que pudiera coordinar a todos los demás
usuarios para terminar sus tareas. Luego nos llamarían y reiniciaríamos. Fue una pesadilla.
Pasamos las primeras dos semanas recopilando datos entrevistando a las personas
que experimentaron 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 simple inspector en tiempo real que podía operarse desde
el teletipo ASR33 que servía como nuestra consola. Con esto podríamos asomarnos
66
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 de estado que podíamos inspeccionar con el inspector. Y, por supuesto, todo esto había que
escribirlo desde cero en ensamblador y probarlo por las tardes cuando el sistema no estaba en uso.
Los terminales estaban controlados por interrupciones. Los caracteres que se enviaban a las terminales se
guardaban en búferes circulares. Cada vez que un puerto serie terminaba de enviar un carácter, se disparaba una
interrupción y el siguiente carácter en el búfer circular se preparaba para enviar.
Eventualmente 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é estaba sucediendo esto, pero al menos era
una pista. En algún lugar de los 5 KSLOC del código de supervisión hubo un error que manejó 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 los terminales mágicamente comenzarían a
funcionar de nuevo. Eventualmente 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.
Más tarde simplemente ejecutamos la utilidad de reparación una vez por segundo.
Aproximadamente un mes después, el problema de la congelación estaba muerto, en lo que respecta a los
Teamsters. De vez en cuando, uno de sus terminales se detenía durante medio segundo, pero a una velocidad base
de 30 caracteres por segundo, nadie parecía darse cuenta.
Pero, ¿por qué los contadores se desalinearon? Tenía diecinueve años y estaba decidido a averiguarlo.
El código de supervisión había sido escrito por Richard, quien desde entonces se había ido a la universidad.
Ninguno de los demás estaba familiarizado con ese código porque Richard había sido muy posesivo con él. Ese
código era suyo, y no se nos permitió saberlo. Pero ahora que Richard se había ido, saqué la lista de pulgadas de
grosor y comencé a repasarla página por página.
67
Las colas circulares en ese sistema eran solo estructuras de datos FIFO, es decir,
colas. Los programas de aplicación colocaron caracteres en un extremo de la cola hasta que
se llenó. Los jefes de interrupción sacaron los caracteres del otro extremo de la cola cuando
la impresora estaba lista para ellos. 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 jefes de interrupción pensaran que la cola estaba vacía.
Los cabezales de interrupción se ejecutan en un "hilo" diferente al resto del código. Por lo
tanto, los contadores y las variables que son manipulados por los encabezados de interrupción
y otro código deben protegerse de la actualización concurrente. En nuestro caso,
eso significaba desactivar las interrupciones en cualquier código que manipulara esas tres
variables. Cuando me senté con ese código, supe que estaba buscando un 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 plétora de poderosas herramientas a nuestra
disposición para encontrar todos los lugares donde el código tocó esas variables. En cuestión
de segundos sabríamos cada línea de código que los tocó. En cuestión de minutos
sabríamos cuál no desactivó las interrupciones. Pero esto fue en 1972, y no tenía ninguna
herramienta como esa. Lo que tenía eran mis ojos.
Estudié detenidamente cada página de ese código, buscando las variables.
Desafortunadamente, las variables se usaron en todas partes. Casi todas las páginas los
tocaron de una forma u otra. Muchas de esas referencias no deshabilitaron las interrupciones
porque eran referencias de solo lectura y, por lo tanto, inofensivas. El problema era que
en ese ensamblador en particular no había una buena manera de saber si una referencia
se leía solo sin seguir la lógica del código. Cada vez que se lee una variable, se puede
actualizar y almacenar posteriormente. 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 se actualizaba una de las tres variables mientras se habilitaban las interrupciones.
Hice los cálculos. La vulnerabilidad tenía una duración de unos dos microsegundos. Había
una docena de terminales funcionando a 30 cps, por lo que una interrupción cada 3 ms más
o menos. 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
MARCANDO USTED MISMO
Solucioné el problema, por supuesto, pero nunca tuve el coraje de apagar el hack automático que
inspeccionaba y arreglaba los contadores. Hasta el día de hoy no estoy convencido de que no haya
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 en la depuración del tiempo como una llamada de la naturaleza, algo que simplemente tiene
para acabar. Pero el tiempo de depuración es tan costoso para la empresa como el tiempo de codificación
y, por lo tanto, cualquier cosa que podamos hacer para evitarlo o disminuirlo es bueno.
Hoy en día paso mucho menos tiempo depurando que hace diez años. No he medido la diferencia, pero creo
que es un factor de diez. Logré esta reducción verdaderamente radical en el tiempo de depuración al adoptar
la práctica de Desarrollo dirigido por pruebas (TDD), que analizaremos en otro capítulo.
Ya sea que adopte TDD o alguna otra disciplina de igual eficacia,3 le corresponde a usted como
profesional reducir el tiempo de depuración lo más cerca posible de cero. Claramente, cero es un objetivo
asintótico, pero es el objetivo de todos modos.
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 los casos en los que se equivocaron. 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 está actuando de manera poco profesional.
PAC ING USTED MISMO
El desarrollo de software es un maratón, no un sprint. No puedes ganar la carrera tratando de correr tan
rápido como puedas desde el principio. Usted gana conservando sus recursos y controlando su propio
ritmo. Una corredora de maratón cuida su cuerpo antes y 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
SABER CUANDO ALEJARSE _ _
¿No puedes ir a casa hasta que resuelvas este problema? ¡Oh, sí que puedes, y
probablemente deberías! La creatividad y la inteligencia son estados mentales
fugaces. Cuando estás cansado, se van. Si luego golpea su cerebro que no funciona
durante hora tras hora tratando de resolver un problema, simplemente se cansará
más y reducirá la posibilidad de que la ducha o el automóvil lo ayuden a resolver el
problema.
Cuando estés atascado, 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 cuida sus recursos.
Controle su ritmo y el de su equipo. Aprende tus patrones de creatividad y brillantez,
y aprovéchalos en lugar de trabajar contra ellos.
CONDUCIENDO A CASA
Un lugar en el que he resuelto una serie de problemas es mi automóvil en el 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, debe
desconectarse de los problemas en el trabajo. Hay algo en la desconexión
que le permite a su mente buscar soluciones de una manera diferente y más
creativa.
LA DUCHA _
He resuelto un número excesivo de problemas en la ducha. Quizás ese chorro de
agua temprano en la mañana me despierte y me haga repasar todas las soluciones
que se le ocurrieron a mi cerebro mientras dormía.
Cuando está trabajando en un problema, a veces se acerca tanto que no puede ver
todas las opciones. Echas de menos soluciones elegantes porque la parte creativa
de tu mente está suprimida por la intensidad de tu enfoque. A veces, la mejor manera
de resolver un problema es ir a casa, cenar, mirar televisión, acostarse y luego
despertarse a la mañana siguiente y darse una ducha.
70
LLEGANDO TARDE
LLEGAR TARDE _
Llegarás tarde . Nos pasa a los mejores. Le sucede a los más dedicados de nosotros. A veces
simplemente exageramos 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úa diciéndoles a todos, hasta el final, que llegará a tiempo, y luego
los decepciona a todos. No hagas esto. En su lugar, mida regularmente su progreso en relación
con su objetivo y proponga tres4
fechas de finalización basadas en hechos: mejor caso, caso nominal y peor caso. Sea tan
honesto como pueda acerca de las tres fechas. ¡No incorpores la esperanza en tus estimaciones!
Presente los tres números a su equipo y a las partes interesadas. Actualice estos
números diariamente.
ESPERANZA _
¿Qué sucede 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 supongamos también que su estimación de tres números para la función en la que
está trabajando es 12/8/20.
¡No espere que pueda hacerlo todo en diez días! La esperanza es el asesino del proyecto.
La esperanza destruye horarios y arruina reputaciones. La esperanza te meterá en serios
problemas. Si la feria comercial es en diez días y su estimación nominal es de 12, no lo hará.
Asegúrese de que el equipo y las partes interesadas entiendan la situación y no se
detenga hasta que haya un plan alternativo. No dejes que nadie más tenga esperanza.
CORRIENDO _
¿Qué sucede si su gerente lo sienta y le pide que intente cumplir con la fecha límite?
¿Qué sucede si su gerente insiste en que “haga lo que sea necesario”? ¡Mantenga 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 Estimación.
71
tu jefe te está confrontando. Dígale a su jefe que ya ha considerado las opciones (porque lo
ha hecho) y que la única forma de mejorar el cronograma es reducir el alcance. No caiga en
la tentación de apresurarse.
¡Ay del pobre desarrollador que cede ante la presión y accede a tratar de cumplir con la
fecha límite! 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 da 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 forma de apresurarse. No puedes hacerte codificar más rápido. No puedes
obligarte a resolver problemas más rápido. Si lo intentas, solo te ralentizarás y crearás
un lío que también ralentizará a todos los demás.
Por lo tanto, debe responder a su jefe, su equipo y sus partes interesadas privándolos de la
esperanza.
CON EL TIEMPO
Entonces tu jefe dice: “¿Qué pasa si trabajas dos horas más al día? ¿Y si trabajas el sábado?
Vamos, tiene que haber una manera de exprimir suficientes horas para terminar la función a
tiempo”.
Las horas extras pueden funcionar y, a veces, son necesarias. A veces, puede hacer una cita
que de otro modo sería imposible al poner algunos días de diez horas y un sábado o dos.
Pero esto es muy arriesgado. No es probable que realice un 20% más de trabajo
trabajando un 20% más de horas. Lo que es más, las horas extraordinarias sin duda fallarán
si se prolongan durante más de dos o tres semanas.
Por lo tanto, no debe aceptar trabajar horas extra a menos que (1) pueda pagarlo
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 extra falle.
Ese último criterio es un factor decisivo. Si su jefe no puede explicarle lo que va a hacer si
falla el esfuerzo de horas extras, entonces no debe aceptar trabajar horas extras.
72
AYUDA
ENTREGA FALSA
De todos los comportamientos poco profesionales que un programador puede permitirse, quizás
el peor de todos es decir que has terminado cuando sabes que no es así. A veces esto es
solo una mentira abierta, y eso es suficientemente 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 puede ser tratado más tarde cuando tengamos más tiempo.
Esta es una práctica contagiosa. Si un programador lo hace, otros lo verán y seguirán su
ejemplo. 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. Uno de mis clientes en
realidad definió "hecho" como "registrado". El código ni siquiera tuvo que compilar. ¡Es muy
fácil estar "terminado" si nada tiene que funcionar!
Cuando un equipo cae en esta trampa, los gerentes escuchan que todo va bien. Todos los
informes de estado muestran que todos están a tiempo. Es como si los ciegos hicieran un picnic
en las vías del tren: nadie ve el tren de carga con el trabajo inconcluso acercándose a ellos hasta
que es demasiado tarde.
DEFINE “HACER UNO ”
Evita el problema de la entrega falsa al crear una definición independiente de "hecho". La mejor
manera de hacer esto es hacer que sus analistas comerciales y probadores creen pruebas
de aceptación automatizadas5 que deben pasar 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 ejecutarse con frecuencia.
AYUDA
La programación es difícil. Cuanto más joven eres, menos crees esto. Después de todo, es solo
un montón de declaraciones if y while . Pero a medida que adquiere experiencia, comienza a
darse cuenta de que la forma en que combina esas declaraciones si y mientras es críticamente
5. Consulte el Capítulo 7, “Pruebas de aceptación”.
73
importante. No puedes simplemente unirlos y esperar lo mejor. Más bien, debe dividir
cuidadosamente el sistema en pequeñas unidades comprensibles que tengan la menor
relación posible entre sí, y eso es difícil.
La programación es tan difícil, de hecho, que está más allá de la capacidad de una sola
persona para hacerlo bien. No importa qué tan hábil sea, sin duda se beneficiará de
los pensamientos e ideas de otro programador.
AYUDANDO A OTROS
Por eso, es responsabilidad de los programadores estar disponibles para ayudarse
unos a otros. Es una violación de la ética profesional aislarse 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 prestar algo de tu tiempo para ayudar a otros. De hecho, como profesional,
su honor está obligado a ofrecer esa ayuda siempre que sea necesario.
Esto no significa que no necesites un tiempo a solas. Por supuesto que sí. Pero tienes
que ser justo y educado al respecto. Por ejemplo, puede dejar saber que entre las 10
am y el mediodía no debe ser molestado, pero de 1 pm a 3 pm su 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. Es probable que se sorprenda
bastante del profundo efecto que puede tener su ayuda. No es que seas mucho
más inteligente que la otra persona, es solo que una nueva perspectiva puede ser un
catalizador profundo para resolver problemas.
Cuando ayudes a alguien, siéntense y escriban código juntos. Planee pasar la mayor
parte de una hora o más. Puede tomar menos que eso, pero no querrás parecer apurado.
Resígnate a la tarea y dale un sólido esfuerzo. Es probable que salga habiendo
aprendido más de lo que dio.
SIENDO AYUDADO
Cuando alguien se ofrezca a ayudarte, sé amable al respecto. Acepta la ayuda
con gratitud y entrégate a esa ayuda. No proteja su territorio. No empuje
74
AYUDA
la ayuda de distancia porque usted está bajo el arma. 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 con un agradecimiento. Recuerde, así como está obligado por su honor a ofrecer
ayuda, está obligado por su honor a aceptarla.
Aprende a pedir ayuda. Cuando esté atascado, confundido o simplemente no pueda entender un
problema, pídale 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. Llamar por ayuda. Una vez más, se trata de una cuestión de ética
profesional. No es profesional quedarse atascado cuando se puede acceder fácilmente a la ayuda.
En este momento, puede que estés esperando que estalle en un coro de Kumbaya mientras los
conejitos peludos saltan sobre las espaldas de los unicornios y todos volamos felizmente
sobre un arcoíris de esperanza y cambio. No, no del todo. Verá, los programadores tienden a ser
introvertidos arrogantes y ensimismados. No nos metimos en este negocio porque nos gusta la
gente. La mayoría de nosotros comenzamos a programar porque preferimos concentrarnos
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, sin tener que interactuar con las complejidades desordenadas de otros . gente.
Sí, esto es un estereotipo. Sí, es una generalización con muchas excepciones. Pero la realidad es
que los programadores no suelen ser colaboradores.6 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, requerimos 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 decir
simplemente que la formación de los programadores menos experimentados es responsabilidad de
los que tienen más experiencia. Los cursos de formación no son suficientes. Los libros no lo cortan.
Nada puede llevar a un joven desarrollador de software a un alto rendimiento más rápido
6. Esto es mucho más cierto para los hombres que para las mujeres. Tuve una maravillosa conversación con @desi (Desi McAdam,
fundadora de DevChix) sobre lo que motiva a las mujeres programadoras. Le dije que cuando lograba que un programa funcionara,
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 un código era
un acto de nutrir la creación.
75
que su propio impulso, y la tutoría efectiva de sus superiores. Por lo tanto, una vez
más, es una cuestión de ética profesional que los programadores senior dediquen tiempo
a proteger a los programadores más jóvenes y asesorarlos. De la misma manera,
esos programadores más jóvenes tienen el deber profesional de buscar esa tutoría de
sus mayores.
BIBLIOGRAFÍA
[Martin09]: Robert C. Martin, Clean Code, Upper Saddle River, Nueva Jersey: Prentice
Sala, 2009.
[Martin03]: Robert C. Martin, Desarrollo de software ágil: principios, patrones y prácticas,
Upper Saddle River, NJ: Prentice Hall, 2003.
76
DESARROLLO
5 PRUEBA IMPULSADA
Han pasado más de diez años desde que Test Driven Development (TDD) hizo su debut en la industria.
Llegó como parte de la ola de programación extrema (XP), pero desde entonces ha sido adoptado
por Scrum y prácticamente todos los demás métodos ágiles.
Incluso los equipos no ágiles practican TDD.
Cuando, en 1998, escuché por primera vez sobre "Probar primero la programación", era escéptico.
¿Quién no lo estaría? ¿ Escribe tus pruebas unitarias primero? ¿Quién haría una tontería como esa?
77
CAPÍTULO 5 DESARROLLO IMPULSADO POR PRUEBAS
Pero para entonces yo había sido un programador profesional durante treinta años, y había visto
las cosas ir y venir en la industria. Sabía que no debía descartar nada de inmediato, especialmente
cuando lo dice alguien como Kent Beck.
Así que en 1999 viajé a Medford, Oregón, para reunirme con Kent y aprender la disciplina de
él. ¡Toda la experiencia fue una sorpresa!
Kent y yo nos sentamos en su oficina y comenzamos a codificar un pequeño problema simple en
Java. Solo quería escribir la tontería. Pero Kent se resistió y me llevó, paso a paso, a través del
proceso. Primero escribió una pequeña parte de una prueba unitaria, apenas lo suficiente para
calificar como código. Luego, escribió el código suficiente para hacer que la prueba se compile.
Luego escribió un poco más de prueba, luego más código.
El tiempo del ciclo estaba completamente fuera de mi experiencia. Estaba acostumbrado a
escribir código durante la mayor parte de una hora antes de intentar compilarlo o ejecutarlo. Pero
Kent estaba literalmente ejecutando su código cada treinta segundos más o menos. ¡Estaba estupefacto!
Además, ¡reconocí el tiempo del ciclo! Era el tipo de tiempo de ciclo que había usado años atrás
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 solo agrega una línea de código y luego
ejecuta. Das la vuelta al ciclo muy rápido. 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
programación tenías que pasar mucho tiempo escribiendo código, y luego mucho más tiempo
compilándolo. Y luego aún más tiempo depurándolo. Yo era un 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, allí estaba Kent, cocinando este programa Java en ciclos de treinta segundos y sin
ningún indicio de que disminuiría la velocidad en el corto plazo. Así que me di cuenta, mientras estaba
sentado en la oficina de Kent, que usando esta simple disciplina podí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.
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
LAS TRES LEYES DE TDD
EL JURADO ESTÁ EN _ _ _
Desde esos 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 tengo que decir esto:
• ¡ El jurado está dentro!
• 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. En los primeros días fueron serios intentos de crítica y comprensión. Hoy en día, sin embargo,
son solo diatribas. 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 puede
saber que todo su código funciona si no lo prueba cada vez que realiza un cambio? ¿Cómo puedes
probarlo cada vez que haces un cambio si no tienes pruebas unitarias automatizadas con una
cobertura muy alta? ¿Cómo puede obtener pruebas unitarias automatizadas con una cobertura muy alta
sin practicar TDD?
Esa última oración requiere alguna elaboración. ¿Qué es TDD?
LAS TRES LEYES DE LA 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 de una prueba unitaria de lo suficiente para fallar, y
no compilar está fallando.
79
3. No se le permite escribir más código de producción que sea suficiente para pasar
la prueba unitaria que falla actualmente.
Estas tres leyes te encierran en un ciclo de, quizás, treinta segundos de duración. Comienza escribiendo
una pequeña parte de una prueba unitaria. Pero dentro de unos segundos debe mencionar el nombre
de alguna clase o función que aún no ha escrito, lo que provoca que la prueba unitaria no se pueda
compilar. Por lo tanto, debe escribir el código de producción que hace que la prueba se compile. Pero
no puede escribir más que eso, así que comienza a escribir más código de prueba de unidad.
Da vueltas y vueltas 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 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 LOS BENEFICIOS
Certeza
Si adopta TDD como disciplina profesional, escribirá docenas de pruebas todos los días, cientos de
pruebas cada semana y miles de pruebas cada año.
Y mantendrá todas esas pruebas a mano y las ejecutará cada vez que realice cambios 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 2200 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 realizo un cambio en cualquier parte de FitNesse, simplemente ejecuto las pruebas unitarias.
Si pasan, estoy casi seguro de que el cambio que hice no rompió nada.
¿Qué tan seguro es “casi seguro”? ¡Lo suficientemente seguro 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. http://fitnesse.org
3. El noventa por ciento es un mínimo. El número es en realidad más grande 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
LAS TRES LEYES DE TDD
Tasa de inyección de defectos
Ahora, 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 envío basándome en nada más
que pasar 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 solo 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 2X,
5X e incluso 10X. Estos 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, debe limpiarse". 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
convierte en tuyo.
Pero, ¿y si pudiera estar seguro de que su limpieza no rompió nada? ¿Qué pasaría si tuvieras
el tipo de certeza que acabo de mencionar? ¿Qué pasaría si pudieras hacer clic en un botón y
saber en 90 segundos que tus cambios no han roto nada y solo han hecho bien?
Este es uno de los beneficios más poderosos de TDD. Cuando tiene un conjunto de pruebas
en las que confía, pierde todo miedo a hacer cambios. Cuando vea un código incorrecto,
simplemente límpielo en el acto. El código se convierte en arcilla que puede 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, más fácil de cambiar y más fácil de extender. Los defectos se convierten
4. http://www.objectmentor.com/omSolutions/agile_customers.html
5. [Maximilien], [George2003], [Janzen2005], [Nagappan2008]
81
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 se ha acostumbrado nuestra industria.
¿Qué programador profesional permitiría que continuara la podredumbre?
Documentación
¿Alguna vez ha utilizado un marco de terceros? A menudo, el tercero le enviará un
manual bien formateado escrito por escritores técnicos. 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 usar ese marco. En la parte posterior, en el apéndice, a menudo hay
una pequeña sección fea que contiene todos los ejemplos de código.
¿Cuál es 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 quiere saber cómo usar el código,
necesita 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 describa cómo crear cada objeto en el sistema,
todas las formas en que se pueden crear esos objetos. Habrá una prueba unitaria que
describa cómo llamar a cada función en el sistema de todas las formas en que esas
funciones pueden llamarse significativamente. Para cualquier cosa que necesites
saber hacer, habrá una prueba unitaria que lo describa en detalle.
Las pruebas unitarias son documentos. Describen el diseño de nivel más bajo
del sistema. Son inequívocos, precisos, escritos en un idioma que la audiencia
entiende y son tan formales que se ejecutan. Son el mejor tipo de documentación
de bajo nivel que puede existir. ¿Qué profesional no aportaría tal 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
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 debe probar el código que está a punto de escribir.
El problema con el código de prueba es que tienes 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, debe
descubrir alguna forma de desacoplar la función de todas las demás. En otras palabras, la
necesidad de probar primero te obliga a pensar en buenas
diseño.
Si no escribe sus pruebas primero, no hay fuerza que le impida unir las funciones en una masa no
comprobable. Si escribe sus pruebas más tarde, podrá 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 primero las pruebas crea una fuerza que lo lleva a
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 puede acercarse a una cobertura alta más
tarde si tiene cuidado al medirla. Pero las pruebas que escribe después del hecho son defensa.
Las pruebas que escribes primero son ofensivas. Las pruebas posteriores a los hechos las
escribe alguien que ya conoce el código y ya 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 potencia
la certeza, el coraje, la reducción de defectos, la documentación y el diseño.
Con todo eso a su favor, podría considerarse poco profesional no usarlo.
LO QUE NO ES TDD
A pesar de todos sus puntos buenos, TDD no es una religión ni una fórmula mágica. Seguir las
tres leyes no garantiza ninguno de estos beneficios. Todavía puede escribir código incorrecto
incluso si escribe sus pruebas primero. De hecho, puedes escribir malas pruebas.
83
De la misma manera, hay momentos en que seguir las tres leyes es simplemente
imprá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", http://collaboration.csc.ncsu.edu/laurie/Papers/
MAXIMILIEN_WILLIAMS.PDF
[George 2003]: B. George y L. Williams, “Una investigación inicial de pruebas
Desarrollo impulsado en la industria”, http://collaboration.csc.ncsu.edu/laurie/
Documentos/TDDpaperv8.pdf
[Janzen2005]: D. Janzen y H. Saiedian, "Conceptos de desarrollo basados en
pruebas, taxonomía y dirección futura", IEEE Computer, volumen 38,
número 9, págs. 43–50.
[Nagappan2008]: Nachiappan Nagappan, E. Michael Maximilien, Thirumalesh Bhat y
Laurie Williams, "Realización de la mejora de la calidad a través del desarrollo
basado en pruebas: resultados y experiencias de cuatro equipos industriales"
Springer Science + Business Media, LLC 2008: http://research.microsoft.
com/enus/projects/esm/nagappan_tdd.pdf
84
6PRACTICAR
Todos los profesionales practican su arte participando en ejercicios de perfeccionamiento.
Los músicos ensayan escalas. Los jugadores de fútbol corren a través de los neumáticos. Los
médicos practican suturas y técnicas quirúrgicas. Los abogados practican argumentos. Los
soldados ensayan misiones. Cuando el rendimiento importa, los profesionales practican. Este
capítulo trata sobre las formas en que los programadores pueden practicar su arte.
85
CAPÍTULO 6 PRÁCTICA
ALGUNOS BAC KG RO UNDON PRACTICANDO
Practicar no es un concepto nuevo en el desarrollo de software, pero no lo reconocimos
como práctica hasta justo 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&RC].
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 idioma. 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 era SQINT, los cuadrados de los números enteros. Lo escribí en ensamblador, BASIC,
FORTRAN, COBOL y un millón de otros lenguajes. Una vez más, 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 uno, como un VIC20 o un Commodore64, o un
TRS80, escribía un pequeño programa que imprimía un flujo infinito de caracteres '\' y '/' en la
pantalla. Los patrones que producía este programa eran agradables a la vista y parecían mucho
más complejos que el pequeño programa que los generaba.
Aunque estos pequeños programas eran ciertamente programas de práctica, los programadores
en general no practicaban. Francamente, la 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 usamos editores de pantalla hasta finales de
los 70. Pasamos gran parte de nuestro tiempo esperando compilaciones o depurando tramos
de código largos y horribles. Todavía no habíamos inventado los ciclos cortos de TDD, por lo
que no necesitábamos el ajuste fino que la práctica podría traer.
86
ALGUNOS ANTECEDENTES SOBRE LA PRÁCTICA
VEINTICINCO CEROS
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 PDP8/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.
Era del tamaño de un refrigerador y consumía una cantidad significativa de energía eléctrica. Tenía
una unidad de disco que podía almacenar 32K de palabras de 12 bits y le hablábamos con un
teletipo de 10 caracteres por segundo. Pensamos que esto 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 1920 ́ 1200 de 17
pulgadas. 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 energía,
ocupa el 1 % del espacio y cuesta una veinticinco parte del precio del PDP 8/I. Hagamos las matemáticas:
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! Esos son los angstroms
que hay entre aquí y Alpha 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 gran, gran número. ¡Y
está sentado en mi regazo, y probablemente también en el tuyo!
¿Y qué estoy haciendo con este aumento de potencia de 22 factores de diez? Estoy haciendo más o
menos lo que estaba haciendo con ese PDP8/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 en 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
TIEMPO DE ENTREGA
Pero la forma en que trabajamos ha cambiado drásticamente. 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 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 compilaciones.1 Los programadores de hoy tienen un poder
tan inmenso bajo sus dedos que pueden girar alrededor del bucle de refactorización rojoverde 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
tiempo medible. Las pruebas parciales requieren segundos. ¡Así que literalmente puedo girar alrededor
del ciclo de compilación/prueba diez veces por minuto!
No siempre es aconsejable ir tan rápido. A menudo es mejor reducir la velocidad y pensar. 2
Pero hay otros momentos en los que girar alrededor de ese bucle lo más rápido posible es muy
productivo.
Hacer cualquier cosa rápidamente requiere práctica. Girar alrededor del ciclo de código/prueba
rápidamente requiere que 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.
Considere dos artistas marciales en combate. Cada uno debe reconocer lo que el otro está intentando
y responder apropiadamente 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 tienes que reaccionar. De hecho, es su cuerpo el que reacciona mientras su
mente está trabajando en una estrategia de nivel superior.
1. El hecho de que algunos programadores esperen las compilaciones es trágico e indicativo de descuido. En el mundo de hoy
los tiempos de compilació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 hamaca.
88
EL DOJO DE CODIFICACIÓN
Cuando gira alrededor del ciclo de código/prueba varias veces por minuto, es su cuerpo el que
sabe qué teclas presionar. Una parte primaria de su mente reconoce la situación y reacciona
en milisegundos con la solución adecuada mientras su 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.
Piensa en un guitarrista como Carlos Santana. La música en su cabeza simplemente sale
de sus dedos. No se enfoca en las posiciones de los dedos o en la técnica de selección. Su
mente es libre para planificar melodías y armonías de nivel superior, mientras que su
cuerpo traduce esos planes en movimientos de dedos de nivel inferior.
Pero para ganar 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.
Desde 2001 he estado realizando una demostración de TDD que llamo The Bowling 3. Es un
Juego. ejercicio pequeño y encantador 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, quizás miles, de veces. ¡Se me dio
muy bien! Podría hacerlo en mi sueño. Minimicé las pulsaciones de teclas, ajusté los nombres
de las variables y modifiqué la estructura del algoritmo hasta que quedó bien. 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 con el
nombre 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 casos. el original es
aquí: http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata.
89
usó TDD para escribir Game of Life de Conway. Lo llamaron “Kata” y acreditaron a “Pragmatic”
Dave Thomas4 con la idea original.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 reunirá y practicará juntos como lo hacen los artistas marciales. En otras
ocasiones, los programadores practicarán solos, nuevamente 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. Observé cómo veinte desarrolladores abrían
sus computadoras portátiles y, tecla por tecla, seguían al líder que estaba haciendo The Bowling
Game Kata.
Hay varios tipos de actividades que tienen lugar en un dojo. Aquí hay algunos:
K ATA
En artes marciales, un kata es un conjunto preciso de movimientos coreografiados que simula un
lado de un combate. El objetivo, que se aborda asintóticamente, es la perfección.
El artista se esfuerza por enseñarle a su cuerpo a hacer cada movimiento a la perfección y
ensamblar esos movimientos en una representación fluida. Los katas bien ejecutados son hermosos
de ver.
Por hermosos que sean, el propósito de aprender un kata no es realizarlo en el escenario. El
propósito es entrenar tu mente y tu cuerpo sobre cómo 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 necesite.
Un kata de programación es un conjunto preciso de pulsaciones de teclas coreografiadas y
movimientos del mouse que simulan la resolución de algún problema de programación. En
realidad, no está resolviendo el problema porque ya conoce la solución.
Más bien, está practicando los movimientos y las decisiones involucradas en la solución del
problema.
4. Usamos el prefijo "Pragmático" para desambiguarlo de "Big" Dave Thomas de OTI.
5. http://codekata.pragprog.com
6. http://codificacióndojo.org/
90
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,
puede descubrir mejoras y eficiencias sutiles, ya sea 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 manera de aprender disciplinas como TDD y
CI. Pero lo que es más importante, es una buena manera de llevar pares comunes de problema/
solución a 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 katas diferentes y
practicarlos regularmente para que no se desvanezcan de la memoria. Muchos katas están
registrados en http://katas.softwarecraftsmanship.org. Otros se pueden encontrar en http://
codekata.pragprog.com. Algunos de mis favoritos son:
• El juego de bolos: http://butunclebob.com/ArticleS.UncleBob.TheBowling
Juego de palabras
• Factores primos: http://butunclebob.com/ArticleS.UncleBob.ThePrimeFactors
Decir
• Ajuste de palabras: http://thecleancoder.blogspot.com/2010/10/craftsman62dark
ruta.html
Para un verdadero desafío, intente aprender un kata tan bien que pueda ponerle música.
Hacer esto bien es difícil.7
JUEGO
Cuando estudié jujitsu, gran parte de nuestro tiempo en el dojo lo pasamos 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 compañero juega el papel de agresor y el otro compañero es el
defensor. Los movimientos se repiten una y otra vez mientras los practicantes intercambian roles.
7. http://katas.softwarecraftsmanship.org/?p=71
91
Los programadores pueden practicar de manera similar usando un juego conocido como
ping 8. Los dos socios eligen un kata, o un problema simple. Un programador pong.
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
están practicando y criticando las técnicas de teclado y mouse de los demás, y qué tan
bien han memorizado el kata. Por otro lado, si los socios 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 una cantidad significativa de poder para establecer restricciones. Por ejemplo, si los
programadores eligen implementar un algoritmo de ordenación, el autor de la prueba
puede imponer fácilmente restricciones en la velocidad y el espacio de memoria que
desafiarán a su compañero. Esto puede hacer que el juego sea bastante competitivo. . . y
diversión.
RANDORI _
Randori es combate de forma libre. En nuestro dojo de jujitsu, establecíamos una variedad
de escenarios de combate y luego los representábamos. A veces se le decía a una persona
que se defendiera, mientras que cada uno 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 a wasa de dos
hombres en el que los socios están resolviendo 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 ensayo y luego se sienta. La siguiente persona pasa la prueba y luego escribe la
siguiente prueba. Esto se puede hacer en secuencia alrededor de la mesa, o las personas
pueden simplemente hacer fila cuando se sientan tan conmovidas. En cualquier caso, estos
ejercicios pueden ser muy divertidos .
8. http://c2.com/cgi/wiki?PairProgrammingPingPongPattern
92
AMPLÍA TU EXPERIENCIA
Es notable cuánto se puede aprender de estas sesiones. Puede obtener una visión inmensa de la forma en
que otras personas resuelven problemas. Estas ideas solo pueden servir para ampliar su propio enfoque y
mejorar su habilidad.
AMPLÍA TU EXPERIENCIA _
Los programadores profesionales a menudo sufren de falta de diversidad en los tipos de problemas que
resuelven. Los empleadores a menudo imponen un solo lenguaje, plataforma y dominio en el que deben trabajar
sus programadores. Sin una influencia de ampliación, esto puede conducir a una reducción muy poco
saludable de su currículum y su forma de pensar. No es raro que tales programadores no se encuentren
preparados para los cambios que periódicamente barren la industria.
CÓDIGO ABIERTO _
Una forma de mantenerse a la vanguardia es hacer lo que hacen los abogados y los médicos: aceptar un 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 le interese a otra persona.
Entonces, si es un programador de Java, contribuya a un proyecto de Rails. Si escribe mucho C++ para su
empleador, busque un proyecto de Python y contribuya a él.
ÉTICA DE LA PRÁCTICA
Los programadores profesionales practican en su propio tiempo. No es el trabajo de su empleador ayudarlo a
mantener sus habilidades en forma para usted. No es el trabajo de su empleador ayudarlo a mantener su
currículum actualizado. Los pacientes no pagan a los médicos para practicar las suturas.
Los fanáticos del fútbol (por lo general) no pagan para ver a los jugadores correr a través de los neumáticos. Los
asistentes al concierto 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 tiene que usar los mismos idiomas o plataformas que usa
con su empleador. Elige cualquier idioma que te guste y mantén afinadas tus habilidades políglotas. Si trabaja
en una tienda .NET, practique un poco de Java o Ruby durante el almuerzo o en casa.
93
CONCLUSIÓN
De una forma u otra, todos los profesionales ejercen. Lo hacen porque les
importa hacer el mejor trabajo posible. Ademá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 estás
ser pagado. Lo haces para que te paguen , y te paguen bien.
BIBLIOGRAFÍA
[K&RC]: Brian W. Kernighan y Dennis M. Ritchie, El lenguaje de
programación C, Upper Saddle River, NJ: Prentice Hall, 1975.
[PPP2003]: Robert C. Martin, Desarrollo ágil de software: principios, patrones
y prácticas, Upper Saddle River, NJ: Prentice Hall, 2003.
94
7PRUEBAS DE ACEPTACIÓN
El papel del desarrollador profesional es tanto un papel de comunicación como de
desarrollo. Recuerde que la entrada/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 el negocio sea precisa y saluda
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 debe funcionar. En realidad, la comunicación
de requisitos es extremadamente difícil y el proceso está plagado de errores.
95
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 usar el editor de texto ED402 para
crear un sistema simple de notificación de problemas.
ED402 era un editor propietario escrito para la computadora M365, que era el clon PDP8
de Teradyne. Como editor de texto, era muy poderoso. Tenía un lenguaje de secuencias de
comandos incorporado que usamos para todo tipo de aplicaciones de texto simple.
Tom no era un 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 podría escribir la aplicación él mismo. En mi
ingenuidad pensé lo mismo. Después de todo, el lenguaje de secuencias de comandos era
poco más que un lenguaje de macros para los comandos de edición, con decisiones muy
rudimentarias y construcciones en bucle.
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
contendría las instrucciones 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
mirando hacia atrás. Mi explicación simplemente no tenía ningún sentido para él.
Esta fue la primera vez que me encontré con esto. Para mí fue algo simple representar
simbólicamente los comandos del editor. Por ejemplo, para representar un comando control
B (el comando que coloca el cursor al comienzo de la línea actual), simplemente escribió
^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 inicialmente pensó, 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.
Así que poco a poco me encontré implementando esta aplicación mientras él se sentaba
y miraba. En los primeros veinte minutos quedó claro que su énfasis había cambiado de
aprender cómo hacerlo él mismo a asegurarse de que lo que hacía era lo que él quería.
96
Nos tomó un día entero. Él describía una función y yo la implementaba mientras él observaba.
El tiempo del ciclo era de cinco minutos o menos, por lo que no había motivo para que se
levantara y hiciera otra cosa. Me pedía que hiciera X, y en cinco minutos tenía X trabajando.
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 ED402, así que propondría otra cosa. Eventualmente acordamos
algo que funcionaría, y luego lo haría funcionar.
Pero luego lo intentábamos y él cambiaba de opinión. Decía algo como, “Sí, eso simplemente
no tiene el flujo que estoy buscando. Intentémoslo de una manera diferente”.
Hora tras hora jugueteamos, pinchamos y empujamos esa aplicación para darle forma.
Probamos una cosa, luego otra y luego otra. Me quedó muy claro que él era el escultor y yo era
la herramienta que manejaba.
Al final, obtuvo la aplicación que estaba buscando, pero no tenía idea de cómo construir la
siguiente por sí mismo. 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 a
menudo no sobrevive al contacto real con el
computadora.
PRECISIÓN PREMATURA
Tanto los empresarios como los programadores se ven tentados a caer en la trampa de la
precisión prematura. Los empresarios quieren saber exactamente lo que van a obtener antes de
autorizar un proyecto. Los desarrolladores quieren saber exactamente lo que 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 desperdiciar 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 se está ejecutando, tienen una mejor idea de lo que realmente quieren y, por lo
general, no es lo que ven.
97
Hay una especie de efecto del observador, o principio de incertidumbre, en juego. Cuando 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 vuelven a medida que se implementa 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 lo hace
En primer lugar, incluso con información perfecta, sus estimaciones tendrán una gran variación.
En segundo lugar, el principio de incertidumbre hace trizas la precisión temprana. Los requisitos
cambiarán haciendo que esa precisión sea discutible.
Los desarrolladores profesionales entienden que las estimaciones pueden y deben realizarse en función de
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
entienda la incertidumbre. (Consulte el Capítulo 10, “Estimación”).
AMBIGUIDAD TARDIA _ _
La solución a la precisión prematura es diferir la precisión tanto como sea posible.
Los desarrolladores profesionales no desarrollan un requisito hasta que están a punto de desarrollarlo. Sin
embargo, eso puede conducir a otra enfermedad: la ambigüedad tardía.
A menudo, las partes interesadas no están de acuerdo. Cuando lo hacen, puede que les resulte más fácil redactar
sortear el desacuerdo en lugar de resolverlo. Encontrarán alguna forma de expresar el requisito con el que todos
puedan estar 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 se necesita una discusión o un desacuerdo para crear ambigüedad.
A veces, las partes interesadas simplemente asumen que sus lectores saben lo que quieren decir.
1. XP Immersion 3, mayo de 2000. http://c2.com/cgi/wiki?TomsTalkAtXpImmersionThree
98
Puede ser perfectamente claro para ellos en su contexto, pero significar algo completamente diferente
para el programador que lo lee. Este tipo de ambigüedad contextual también puede ocurrir cuando los clientes
y los programadores hablan cara a cara.
Sam (parte interesada): “OK, ahora es necesario hacer una copia de seguridad de estos archivos de registro”.
Paula: “OK, ¿con qué frecuencia?”
Sam: "Todos los días".
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. Así que escribiremos el archivo de registro en la copia de seguridad
directorio todos los días. ¿A qué hora?"
Samuel: "Todos los días".
Paula: “No, me refiero a qué hora del día lo quieres escrito?”
Sam: "En cualquier momento".
Paula: "¿Entonces?"
Sam: “No, no durante el horario comercial. La medianoche sería mejor.
Paula: “OK, entonces medianoche”.
Sam: “¡Genial, gracias!”
Paula: “Siempre 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 la medianoche ".
Peter: "OK, ¿qué nombre de archivo deberíamos usar?"
Paula: "log.backup debería hacerlo".
Pedro: "Lo tienes".
99
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. tenemos que volver
a través de todos esos archivos de registro, incluso meses o años después, siempre
que haya una interrupción, un evento o una disputa”.
Sam: “No te preocupes, acabo de hablar con Paula. Guardará los registros en un directorio llamado
copia de seguridad todas las noches a la 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ían guardar el archivo de registro de la noche anterior. Cuando el cliente
busque copias de seguridad de archivos de registro de meses, solo encontrará la de anoche.
En este caso, tanto Paula como Sam dejaron caer la pelota. Es responsabilidad de los desarrolladores
profesionales (y las partes interesadas) asegurarse de que se elimine toda ambigüedad de los requisitos.
Esto es difícil, y sólo hay una forma en que sé cómo hacerlo.
PRUEBAS DE ACEPTACIÓN
El término prueba de aceptación está sobrecargado y usado en exceso. Algunas personas asumen que
estas son las pruebas que los usuarios ejecutan antes de aceptar un lanzamiento. Otras personas
piensan que estas son pruebas de control de calidad. En este capítulo definiremos las pruebas de
aceptación como pruebas escritas por una colaboración de las partes interesadas y los programadores para
definir cuándo se cumple un requisito.
LA DEFINICIÓN DE “ HECHO
”
Una de las ambigüedades más comunes que enfrentamos como profesionales del software es la
ambigüedad de "hecho". Cuando un desarrollador dice que ha terminado con una tarea, ¿qué significa eso?
¿Ha terminado el desarrollador 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
logró que se ejecutara una vez, pero aún no lo ha probado realmente.
100
He trabajado con equipos que tenían una definición diferente para las palabras "hecho" y "completo". Un equipo en
particular usó los términos "hecho" y "hechohecho".
Los desarrolladores profesionales tienen una sola definición de hecho: Hecho significa hecho.
Listo significa que todo el código está escrito, todas las pruebas pasan, QA y las partes interesadas han
aceptado. Hecho.
Pero, ¿cómo puede obtener este nivel de finalización y aun así progresar 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 impulsan 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 de lo hecho.
Sam: "Está bien, ahora es necesario hacer una copia de seguridad de estos archivos de registro".
Paula: “OK, ¿con qué frecuencia?”
Sam: "Todos los días".
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'"?
Tom (probador): “Espera, 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: "¿Quieres decir que hay un archivo de registro activo y muchas copias de seguridad de
archivos de registro?"
101
Samuel: "Por supuesto".
Paula: “¡Ay! Pensé que solo querías una copia de seguridad temporal.
Sam: "No, el cliente quiere quedárselos todos para siempre".
Paula: “Eso es nuevo para mí. OK, me alegro de que hayamos aclarado eso”.
Tom: "Entonces, el nombre del subdirectorio debería decirnos exactamente qué hay en él".
Sam: "Tiene todos los registros antiguos inactivos".
Tom: "Así que llamémoslo old_inactive_logs".
Samuel: "Genial".
Tom: "Entonces, ¿cuándo se crea este directorio?"
Sam: "¿Eh?"
Paula: “Deberíamos crear el directorio cuando se inicia el sistema, pero solo si
el directorio aún no existe.”
Tom: “OK, ahí está nuestra primera prueba. Tendré que iniciar el sistema y ver si se crea el
directorio old_inactive_logs . Luego agregaré un archivo a ese directorio. Luego cerraré
y comenzaré de nuevo, y me aseguraré de que tanto el directorio como el archivo aún
estén allí”.
Paula: “Esa prueba te va a llevar mucho tiempo hacerla. El inicio del sistema ya es de 20
segundos y sigue creciendo. 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 arranque del sistema, el SystemStarter
simplemente le dirá a todos los objetos StartupCommand que se ejecuten. Uno de
esos derivados de StartupCommand creará old_inactive_logs
directorio, pero solo si aún no existe”.
Tom: “Oh, está bien, entonces todo lo que necesito probar es ese derivado de StartupCommand .
Puedo escribir una simple prueba de FitNesse para eso”.
Tom va a la pizarra.
“La primera parte se verá así”:
dado el comando LogFileDirectoryStartupCommand
dado que el directorio old_inactive_logs no existe
102
cuando se ejecuta el comando
entonces debería existir el directorio old_inactive_logs
y debería estar vacío
“La segunda parte se verá así”:
dado que existe el directorio old_inactive_logs
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 debe contener un archivo llamado x
Paula: "Sí, eso debería cubrirlo".
Sam: "Vaya, ¿todo eso es realmente necesario?"
Paula: “Sam, ¿cuál de estas dos declaraciones 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 es más trabajo que escribir un plan de prueba manual. Y es 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 probadores entienden 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 se va a construir.
UNA UTOMACIÓN
Las pruebas de aceptación siempre deben estar automatizadas. Hay un lugar para las pruebas
manuales en otras partes del ciclo de vida del software, pero este tipo de pruebas nunca deben ser
manuales. La razón es simple: costo.
Considere la imagen en la Figura 71. Las manos que ves allí pertenecen al gerente de control de
calidad de una gran empresa de Internet. El documento que sostiene es la tabla de
103
contenidos para su plan de prueba manual . Tiene un ejército de probadores manuales en
ubicaciones en alta mar 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á esperando porque acaba de regresar de una reunión en
la que su gerente le ha dicho que necesitan recortar su presupuesto en un 50%. Su pregunta
para mí es: "¿Qué mitad de estas pruebas no debo ejecutar?"
Figura 71 Plan de prueba manual
Llamar a esto un desastre sería una gran subestimación. 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 ocurra este tipo de situación. 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
Hay 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 pueden leer, comprender e incluso crear.
TRABAJO EXTRA _
El punto de Sam sobre el trabajo es comprensible. Parece mucho trabajo extra escribir pruebas de
aceptación como esta . Pero dada la Figura 71, podemos ver que en realidad no es un trabajo extra.
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 forma 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. Por lo tanto, no considere estas pruebas como un
trabajo adicional. Mírelos como grandes ahorradores de tiempo y dinero. Estas pruebas evitarán que
implemente el sistema incorrecto y le permitirán saber cuándo ha terminado.
QUIÉN ESCRIBE PRUEBAS DE ACEPTACIÓN , ¿Y CUANDO ?
En un mundo ideal, las partes interesadas y el control de calidad colaborarían para escribir 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 sumergirse en el nivel de detalle requerido. Por lo
tanto, a menudo delegan la responsabilidad en analistas comerciales, control de calidad o incluso
desarrolladores. Si resulta que los desarrolladores deben escribir estas pruebas, tenga cuidado de que el
desarrollador que escribe la prueba no sea el mismo desarrollador que implementa la función probada.
Por lo general, los analistas comerciales escriben las versiones de "ruta feliz" de las pruebas, porque esas
pruebas describen las características que tienen valor comercial. El control de calidad generalmente escribe
las pruebas de "ruta infeliz", las condiciones límite, las excepciones y los casos de esquina.
Esto se debe a que el trabajo del control de calidad es ayudar a pensar qué puede salir mal.
Siguiendo el principio de "precisión tardía", las pruebas de aceptación deben escribirse lo más tarde posible,
generalmente unos días antes de que se implemente la función. En los proyectos ágiles, las pruebas se
escriben después de que se hayan seleccionado las funciones para la siguiente iteración o Sprint.
105
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 para el punto medio de la iteración,
algunos desarrolladores tendrán que colaborar para terminarlas. Si esto sucede con frecuencia,
se deben agregar más BA y/o QA al equipo.
EL PAPEL DEL DESARROLLADOR
El trabajo de implementación de una función comienza cuando las pruebas de aceptación para
esa función están listas. Los desarrolladores ejecutan las pruebas de aceptación de la
nueva característica 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 echas una mano con esta historia?”
Peter: “Claro, Paula, ¿qué pasa?”
Paula: “Aquí está la prueba de aceptación. Como pueden ver, está fallando”.
dado que el directorio old_inactive_logs no existe
cuando se ejecuta el comando
entonces debería existir el directorio old_inactive_logs
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: "¿Ya tenemos una operación createCommand ?"
Peter: "Sí, está en CommandUtilitiesFixture que escribí la semana pasada".
Paula: "Está bien, hagamos la prueba ahora".
Peter: (ejecuta la prueba). “Sí, la primera línea es verde, pasemos a la siguiente”.
No te preocupes demasiado por los escenarios y accesorios. Esas son solo algunas de las
conexiones que debe escribir para conectar las pruebas al sistema que se está probando.
106
Baste decir que todas las herramientas proporcionan alguna forma de usar la coincidencia de patrones
para reconocer y analizar las declaraciones de la prueba, y luego llamar a las funciones que alimentan
los datos de la prueba en el 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.
NEGOCIACIÓN DE PRUEBA Y AGRESIÓN PASIVA
Los autores de las 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. Pueden ser demasiado
complicados. Pueden ser incómodos. Pueden contener suposiciones tontas.
O simplemente podrían estar equivocados. Esto puede ser muy frustrante si usted es el
desarrollador que tiene que pasar 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 pasivoagresiva 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 termine 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 solo podemos hacer esa garantía en una estadística
sentido."
Tom: “¿Eh? Eso suena como palabras de comadreja. El requisito es dos
segundos."
Paula: “Correcto, y podemos lograr eso el 99,5% de las veces”.
Tom: “Paula, ese no es el requisito”.
Paula: “Pero es la realidad. No hay forma de que pueda hacer la garantía de otra manera”.
107
Tom: "Sam va a tener un ataque".
Paula: “No, en realidad ya le hablé de eso. Está bien siempre que la experiencia normal del
usuario sea de dos segundos o menos”.
Tom: “OK, 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 ejecute mil operaciones posteriores y me asegure de
que no más de cinco tengan más de dos segundos? Eso es absurdo."
Paula: “No, tardaría casi una hora en ejecutarse. Qué tal si
¿este?"
ejecutar 15 post transacciones 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: “Solo un poco de estadística. Aquí, ¿qué tal esto?
ejecutar 15 post transacciones y acumular tiempos.
asegúrese de que las probabilidades sean del 99,5 % de que el tiempo sea inferior a 2 segundos.
Tom: "Sí, eso 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 pueda verificar las matemáticas si tiene alguna duda.
Tom: "Está bien, eso funciona para mí".
PRUEBAS DE ACEPTACIÓN Y PRUEBAS DE UNIDAD
Las pruebas de aceptación no son pruebas unitarias . Las pruebas unitarias son escritas por programadores para
programadores Son documentos de diseño formal que describen la estructura y el comportamiento
de nivel más bajo del código. La audiencia son los programadores, no los negocios.
Las pruebas de aceptación las escribe la empresa para la empresa (incluso cuando usted, el
desarrollador, termina por escribirlas) . Son documentos de requisitos formales que especifican cómo
debe comportarse el sistema desde el punto de vista del negocio. La audiencia es el negocio y
los programadores.
108
Puede ser tentador tratar de eliminar el “trabajo extra” asumiendo que los dos tipos de pruebas son
redundantes. Si bien es cierto que las pruebas unitarias y de aceptación a menudo prueban las mismas
cosas, no son redundantes en absoluto.
Primero, aunque pueden probar las mismas cosas, lo hacen a través de diferentes mecanismos y
vías. Las pruebas unitarias profundizan en las entrañas del sistema haciendo llamadas a métodos en
clases particulares. Las pruebas de aceptación invocan el sistema mucho más lejos, en la API o, a veces,
incluso en el nivel de la interfaz de usuario. Entonces, las rutas 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
probar. El hecho de que sean pruebas es incidental. Las pruebas unitarias y las pruebas de aceptación
son primero documentos y luego pruebas. Su propósito principal es documentar formalmente el diseño, la
estructura y el 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 Y OTRAS COMPLICACIONES
Es difícil especificar las GUI por adelantado. Se puede hacer, pero rara vez se hace bien. La razón es que
la estética es subjetiva y por lo 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 hace que sea un desafío escribir 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 solo un buen
diseño.
Existe un principio de diseño llamado Principio de Responsabilidad Única (SRP). Este principio establece
que debes separar aquellas cosas que cambian por diferentes razones y agrupar aquellas cosas 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
a pesar de estos cambios. Por lo tanto, al escribir pruebas de aceptación para una GUI,
aprovecha 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 en función de sus posiciones en la página, es posible que pueda hacer
clic en ellos en función de sus nombres. Mejor aún, tal vez cada uno tenga una identificación
única que pueda 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.
Prueba a través de la interfaz correcta
Mejor aún es escribir pruebas que invoquen las funciones 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.
La prueba a través de la GUI siempre es problemática 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 rompe 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 las 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 stubs 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.
CONTINUO I NTEG R Y ON
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
CONCLUSIÓN
Sistema de control de código fuente. Cada vez que alguien confirma un módulo, el sistema de 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 IC funcionando en todo momento. Nunca deben fallar. Si
fallan, entonces todo el equipo debe dejar de hacer lo que están haciendo y concentrarse en lograr que
las pruebas fallidas vuelvan a pasar. Una compilación rota en el sistema CI debe verse como
una emergencia, un evento de "detener las prensas".
He consultado a equipos que no tomaron en serio las pruebas rotas. Estaban "demasiado ocupados"
para arreglar las pruebas rotas, por lo que las dejaron de lado y prometieron arreglarlas más tarde. En
un caso, el equipo eliminó las pruebas rotas de la compilación porque era muy inconveniente verlas fallar.
Más tarde, después de entregar al cliente, se dieron cuenta de que se habían olvidado de volver a
poner esas pruebas en la compilación. Se enteraron de esto porque un cliente enojado los estaba
llamando 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 entiende. Con demasiada frecuencia,
ambas partes están de acuerdo en que entienden y se van con ideas completamente diferentes.
La única forma que conozco de eliminar de manera efectiva los errores de comunicación entre los
programadores y las partes interesadas es escribir pruebas de aceptación automatizadas. Estas
pruebas son tan formales que se ejecutan. Son completamente inequívocos y no pueden perder la
sincronización con la aplicación. Son el documento de requisitos perfecto.
111
8 ESTRATEGIAS DE PRUEBA
Los desarrolladores profesionales prueban su código. Pero las pruebas no son simplemente una
cuestión de escribir algunas pruebas unitarias o algunas 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 pruebas.
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 en el
equipo, desde programadores hasta gerentes, secretarias y administradores de bases de datos, se
sentarían con Rose e intentarían que fallara. Se otorgaron premios a varios tipos de
113
CAPÍTULO 8 PRUEBA DE ESTRATEGIAS
insectos. La persona que encuentre un insecto estrellado podría ganar una cena para dos. La persona
que encuentre la mayor cantidad de 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 separado 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 en un producto, es probable que encuentren algunas. Aún así, cada vez que el control de
calidad encuentra algo, el equipo de desarrollo debe reaccionar con horror. Deben preguntarse cómo
sucedió y tomar medidas para prevenirlo en el futuro.
QA SOY PARTE DEL EQUIPO
La sección anterior podría haber hecho parecer que el control de calidad y el desarrollo están en
desacuerdo entre sí, que su relación es antagónica. Esta 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 rol para la parte del equipo de control de calidad es actuar como especificadores y
caracterizadores.
QA como especificadores
El rol de control de calidad debe ser trabajar con el negocio para crear las 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, el negocio escribe las pruebas del camino feliz, mientras que el control de
calidad escribe las pruebas de la esquina, el límite y el camino infeliz.
QA como Caracterizadores
La otra función del control de calidad es usar la disciplina de las pruebas exploratorias1 para
caracterizar el verdadero comportamiento del sistema en ejecución e informar ese comportamiento.
1. http://www.satisfice.com/articles/what_is_et.shtml
114
LA PIRÁMIDE DE AUTOMATIZACIÓN DE PRUEBAS
volver al desarrollo y los negocios. En este rol, QA no está interpretando los requisitos. Más
bien, están identificando los comportamientos reales del sistema.
Los desarrolladores profesionales emplean la disciplina del desarrollo dirigido por 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 solo una parte de la historia. Tan bueno como es tener un conjunto de pruebas
unitarias y de aceptación, también necesitamos pruebas de mayor nivel para garantizar que el
control de calidad no encuentre nada. La figura 81 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% XUnidad
Figura 81 La pirámide de automatización de pruebas
2. [COHN09] págs. 311–312
115
PRUEBAS DE UNIDAD
En la base de la pirámide están 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 brindan una cobertura tan cercana al 100% como sea práctico. En
general, este número debería estar en algún lugar alrededor de 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 se escriben contra componentes individuales del sistema. Los componentes del
sistema encapsulan las reglas comerciales, por lo que las pruebas para esos componentes son las
pruebas de aceptación para esas reglas comerciales.
Como se muestra en la figura 82, una prueba de componente envuelve un componente. Pasa datos
de entrada al componente y recopila datos de salida de él. Comprueba que la salida coincida
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
ea
noesm r gxenE
di
Figura 82 Prueba de aceptación de componentes
116
Las pruebas de componentes están escritas por QA y Business con la asistencia de desarrollo.
Están compuestos en un entorno de prueba de componentes como FitNesse, JBehave o Cucumber.
(Los componentes de 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 camino infeliz están cubiertos por pruebas unitarias y no tienen sentido a
nivel de pruebas de componentes.
I LAY R ATI ON PRUEBAS
Estas pruebas solo tienen sentido para sistemas más grandes que tienen muchos componentes.
Como se muestra en la Figura 83, estas pruebas ensamblan grupos de componentes y
comprueban qué tan bien se comunican entre sí. Los otros componentes del sistema están
desacoplados como de costumbre con simulacros y dobles de prueba apropiados.
Las pruebas de integración son pruebas de coreografía . No prueban las reglas de negocio. Más
bien, prueban qué tan bien baila el conjunto de componentes juntos. Son pruebas de
plomería que aseguran que los componentes estén correctamente conectados y puedan
comunicarse claramente entre sí.
Componente
Componente
Componente
am
nó ince rga e xetnE
di
Componente
Figura 83 Prueba de integración
117
Las pruebas de integración generalmente las escriben los arquitectos del sistema, o los diseñadores
principales, del sistema. Las pruebas aseguran que la estructura arquitectónica del sistema es
sólida. Es en este nivel que podríamos ver pruebas de rendimiento y rendimiento.
Las pruebas de integración normalmente se escriben en el mismo lenguaje y entorno que las
pruebas de componentes. Por lo general, no se ejecutan como parte de la suite de integración
continua, porque a menudo tienen tiempos de ejecución más largos. En cambio, estas pruebas se
ejecutan periódicamente (todas las noches, semanalmente, etc.) según lo consideren
necesario sus autores.
PRUEBAS DEL SISTEMA
Estas son pruebas automatizadas que se ejecutan contra todo el sistema integrado.
Son las últimas pruebas de integración. No prueban las reglas comerciales directamente.
Más bien, prueban que el sistema se haya conectado correctamente y que sus partes interoperen
de acuerdo con 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. Por lo general,
están escritos en el mismo idioma 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
frecuentes, 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. Las
capas inferiores de la pirámide ya han determinado el comportamiento correcto del código y los
componentes subyacentes.
PRUEBAS E X PLO R ATO RI A MANUALES
Aquí es donde los humanos ponen sus manos en los teclados y sus ojos en las pantallas. Estas
pruebas no están automatizadas ni están programadas. La intención de estas pruebas es explorar
el sistema en busca de comportamientos inesperados mientras se confirman los comportamientos
esperados. Con ese fin, necesitamos cerebros humanos, con creatividad humana, trabajando
para investigar y explorar el sistema. Crear un plan de prueba por escrito para este tipo de
prueba anula el propósito.
118
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 escritores técnicos, "golpeen" el sistema
para ver si pueden hacer que se rompa.
El objetivo no es la cobertura. No vamos a probar todas las reglas comerciales y todas las vías de
ejecución con estas pruebas. Más bien, el objetivo es garantizar que el sistema se comporte bien
bajo la 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 solo parte de una estrategia de prueba total. Para cumplir
con el objetivo de que "el control de calidad no debe encontrar nada", los equipos de desarrollo
deben trabajar mano a mano con el control de calidad para crear una jerarquía de pruebas de
unidades, componentes, integración, sistemas y exploratorias. Estas pruebas deben ejecutarse 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, Tener éxito con Agile, Boston, MA: AddisonWesley,
2009.
119
9 GESTIÓN DEL TIEMPO
Ocho horas es un período de tiempo notablemente corto. Son solo 480 minutos o
28.800 segundos. Como profesional, espera utilizar esos preciosos segundos
de la manera más eficiente y efectiva posible. ¿Qué estrategia puedes usar para
asegurarte de no perder el poco tiempo que tienes? ¿Cómo puedes administrar tu
tiempo de manera efectiva?
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
CAPÍTULO 9 GESTIÓN DEL TIEMPO
los días eran ajetreados con llamadas telefónicas, reuniones improvisadas, problemas de servicio
de campo e interrupciones. Entonces, para poder realizar cualquier trabajo, tuve que adoptar algunas
disciplinas de gestión del tiempo bastante drásticas.
• Me despertaba a las 5 cada mañana y montaba mi bicicleta a la oficina en Bracknell a las 6 am. Eso
_1
me dio 2 comenzó. 2 horas de silencio antes del caos del día
• Al llegar, escribiría un horario en mi pizarra. dividí el tiempo en
incrementos de 15 minutos y completé la actividad en la que trabajaría durante ese bloque de
tiempo.
• Llené por completo las primeras 3 horas de ese horario. A partir de las 9 am comencé a dejar un
espacio de 15 minutos por hora; de esa manera, podría empujar rápidamente la mayoría de las
interrupciones a uno de esos espacios abiertos y continuar trabajando.
• Dejé el tiempo después del almuerzo sin programar porque sabía que para entonces todo el infierno
se habría desatado 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 entrometió, simplemente trabajé en lo más importante
hasta que lo hizo.
Este esquema no siempre tuvo éxito. Despertarme a las 5 a. m. no siempre era factible y, a veces, el
caos rompía todas mis cuidadosas estrategias y consumía mi día. Pero en su mayor parte pude mantener
mi cabeza fuera del agua.
REUNIONES
Las reuniones cuestan alrededor de $ 200 por hora por asistente. Esto tiene en cuenta los
salarios, los beneficios, los costos de las instalaciones, etc. La próxima vez que esté en una
reunión, calcule el costo. Puede que te sorprendas.
Hay dos verdades acerca de las reuniones.
1. Las reuniones son necesarias.
2. Las reuniones son una gran pérdida de tiempo.
A menudo, estas dos verdades describen por igual el mismo encuentro. Algunos de los asistentes
pueden encontrarlos invaluables; otros pueden encontrarlos redundantes o inútiles.
122
REUNIONES
Los profesionales son conscientes del alto costo 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 tiene que asistir a todas las reuniones a las que está invitado. De hecho, no es profesional
ir a demasiadas reuniones. Necesitas usar tu tiempo sabiamente. Así que tenga mucho cuidado
con las reuniones a las que asiste y las que rechaza cortésmente.
La persona que lo invita a una reunión no es responsable de administrar su tiempo. Solo
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á realizando ahora.
A veces, la reunión será sobre algo que le interese, pero que no sea inmediatamente
necesario. Tendrás que elegir si puedes permitirte el tiempo. Tenga cuidado, puede haber más
que suficientes de estas reuniones para consumir sus días.
A veces, la reunión tratará sobre algo en lo que 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 la pena en beneficio de ellos. Esto puede sonar cínico, pero su
responsabilidad es primero con sus proyectos. Aún así, a menudo es bueno que un equipo
ayude a otro, por lo que es posible que desee analizar su participación con su
equipo y gerente.
A veces, alguien con autoridad solicitará su presencia en la reunión, como un ingeniero
de alto nivel en otro proyecto o el gerente de un proyecto diferente. Tendrá que elegir si esa
autoridad pesa más que su horario de trabajo. Una vez más, su equipo y su supervisor pueden
ser de ayuda para 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
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 agregan nuevos temas, o
la manía favorita 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, márchese.
De nuevo, tienes la obligación de administrar bien tu tiempo. Si te encuentras atrapado en una
reunión que no es un buen uso de tu tiempo, necesitas encontrar una manera de salir cortésmente
de esa reunión.
Claramente, no debe salir furioso de una reunión exclamando "¡Esto es aburrido!"
No hay necesidad de ser grosero. Simplemente puede preguntar, en el momento oportuno, si su
presencia sigue siendo necesaria. 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 a tener en cuenta 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. Tiene la obligación de gastar sabiamente el tiempo y el dinero de su empleador, por
lo que no es poco profesional elegir un momento apropiado para negociar su salida.
TENER UNA AGENDA Y UNA META
La razón por la que estamos dispuestos a asumir el costo de las reuniones es que a veces
necesitamos a los participantes juntos en una sala para ayudar a lograr un objetivo específico.
Para usar el tiempo de los participantes sabiamente, la reunión debe tener una agenda clara,
con tiempos para cada tema y una meta establecida.
Si se le pide que vaya 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, debe irse
cortésmente cuando sea posible.
124
REUNIONES
REUNIONES DE PIE _
Estas reuniones son parte del canon Agile. Su nombre proviene del hecho de que se espera que
los participantes estén de pie mientras la reunión está en sesión. Cada participante se turna 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
debe terminar mucho antes de que hayan transcurrido diez minutos.
REUNIONES DE PLANIFICACIÓN DE ITE R ACI Ó N
Estas son las reuniones más difíciles en el canon Agile para hacerlo bien. Si se hacen mal,
toman demasiado tiempo. Se necesita habilidad para que estas reuniones salgan bien, una
habilidad que bien vale la pena aprender.
Las reuniones de planificación de iteraciones están destinadas a seleccionar los elementos
pendientes que se ejecutarán en la siguiente iteración. Las estimaciones ya deberían estar hechas
para los artículos de la fecha del candidato. La evaluación del valor comercial 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 proceder rápidamente con cada elemento del atraso de candidatos discutido
brevemente y luego seleccionado o rechazado. No se deben dedicar más de cinco o diez minutos
a un elemento determinado. Si se necesita una discusión más larga, debe programarse para otro
momento con un subconjunto del equipo.
Mi regla general es que la reunión no debe ocupar 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 terminar en
dos horas.
125
ITE R ACI ÓN RETROSPECTIVA Y DEMO
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 operativas. Se puede abusar gravemente de estas reuniones y consumir
mucho tiempo, así que prográmelas 45 minutos antes de la hora de finalización del último día de
la iteración. Asigne no más de 20 minutos para la retrospectiva y 25 minutos para la
demostración. Recuerda, solo han pasado una semana o dos, así que no debería
haber mucho de qué hablar.
ARGUMENTOS / DESACUERDOS
Kent Beck me dijo una vez algo profundo: “Cualquier argumento que no se pueda resolver
en cinco minutos no se puede resolver discutiendo”. La razón por la que dura tanto tiempo es
que no hay pruebas claras que respalden a ninguno de los lados. El argumento es
probablemente religioso, en oposición a los hechos.
Los desacuerdos técnicos tienden a irse a la estratosfera. Cada parte tiene todo tipo de
justificaciones para su posición pero rara vez algún dato. Sin datos, cualquier argumento que no
forje un acuerdo en unos pocos minutos (entre cinco y treinta) simplemente nunca forjará
un acuerdo. Lo único que hay que hacer es ir a buscar algunos datos.
Algunas personas intentarán ganar una discusión por la fuerza de su carácter. Pueden gritar,
ponerse en tu cara o actuar con condescendencia. No importa; la fuerza de voluntad no resuelve
los desacuerdos por mucho tiempo. Los datos sí.
Algunas personas serán pasivoagresivas. Estarán de acuerdo solo en poner fin a la discusión
y luego sabotearán el resultado al negarse a participar en la solución. Se dirán a sí mismos: "Así
es como lo querían, y ahora van a obtener lo que querían". Este es probablemente el peor tipo
de comportamiento poco profesional que existe. Nunca, nunca hagas esto. Si está de acuerdo,
debe comprometerse .
¿Cómo obtiene los datos que necesita para resolver un desacuerdo? A veces puede realizar
experimentos, o hacer 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
ENFOQUE MANÁ
Si las cosas funcionan, entonces ese camino era factible. Si te metes en problemas, puedes
retroceder e ir por 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 solo un lugar para ventilar un desacuerdo
y reunir apoyo para un lado o el otro. Y evite aquellos en los que solo uno de los argumentadores
esté presentando.
Si realmente se debe resolver una discusión, pida a cada uno de los argumentadores que
presente su caso al equipo en cinco minutos o menos. Luego haga que el equipo vote. Toda
la reunión tomará menos de quince minutos.
ENFOQUE MANÁ
Perdónenme si esta sección parece oler a metafísica New Age, o tal vez a Dungeons & Dragons.
Es solo que esta es la forma en que pienso sobre este tema.
La programación es un ejercicio intelectual que requiere largos períodos de concentración
y atención. El enfoque es un recurso escaso, como el maná.1 Después de haber gastado su
enfoquemaná, debe recargarse realizando actividades no enfocadas durante una hora o más.
No sé qué es este focomaná, pero tengo la sensación de que es una sustancia física (o
posiblemente su carencia) 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 administrar su tiempo para aprovechar su
enfoquemaná. Escribimos código cuando nuestro enfoque es alto; y hacemos otras cosas
menos productivas cuando no lo es.
Focusmanna es también un recurso en descomposición. Si no lo usa cuando está allí, es probable
que lo pierda. Esa es una de las razones por las que las reuniones pueden ser tan
1. El maná es un producto común en 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 una tasa diaria lenta
y fija. Así que es fácil usarlo todo en unas pocas sesiones de lanzamiento de hechizos.
127
devastador. Si gasta todo su maná de enfoque en una reunión, no le 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 le hiciste a tu 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 la mayor concentración de maná después de una
buena noche de sueño. Siete horas de sueño a menudo me darán ocho horas completas de
maná de concentración. Los desarrolladores profesionales gestionan su horario de sueño para
asegurarse de que han completado su maná de concentración para cuando llegan al trabajo por la
mañana.
CAFEÍNA
No hay duda de que algunos de nosotros podemos hacer un uso más eficiente de nuestro
maná de enfoque al consumir cantidades moderadas de cafeína. Pero ten cuidado. La cafeína
también pone un extraño "nerviosismo" en tu enfoque. Demasiado puede desviar tu atención en
direcciones muy extrañas. Un subidón de cafeína realmente fuerte puede hacer que pierdas un
día entero concentrándote demasiado 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 cocacola light con el almuerzo.
A veces doblo esta dosis, pero rara vez hago más que eso.
RECARGA
Focusmanna se puede recargar parcialmente desenfocando. Una buena caminata larga, una
conversación con amigos, un momento para mirar por la ventana, todo puede ayudar a recuperar
el maná de enfoque.
Algunas personas meditan. Otras personas toman una siesta energética. Otros escucharán un
podcast o hojearán una revista.
128
ENFOQUE MANÁ
Descubrí que una vez que se acaba el maná, no puedes forzar el enfoque. Todavía puede
escribir código, pero es casi seguro que tendrá que volver a escribirlo al día siguiente, o vivir con
una masa podrida durante semanas o meses. Así que es mejor tomarse treinta o incluso
sesenta minutos para desenfocar.
ENFOQUE MUSCULAR
Hay algo peculiar en hacer disciplinas físicas como artes marciales, taichi o yoga. Aunque
estas actividades requieren un enfoque significativo, es un tipo de enfoque diferente al de la
codificación. No es intelectual, es músculo. Y de alguna manera el enfoque muscular
ayuda a recargar el enfoque 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.
Mi forma elegida de enfoque físico es andar en bicicleta. Cabalgo durante una hora o dos, a
veces recorriendo veinte o treinta millas. Voy por un sendero paralelo al río Des Plaines, así que
no tengo que lidiar con los autos.
Mientras viajo escucho podcasts sobre astronomía o política. A veces solo 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 sus manos. Tal vez disfruten
de la carpintería, la construcción de maquetas o la jardinería. Cualquiera que sea la
actividad, hay algo acerca de las actividades que se enfocan en los músculos que mejora la
capacidad de trabajar con la mente.
ENTRADA VERSUS SALIDA
Otra cosa que encuentro esencial para el enfoque es equilibrar mi salida con la
entrada adecuada. Escribir software es un ejercicio creativo . Encuentro que soy más creativo
cuando estoy expuesto a la creatividad de otras personas. Así que leo mucha ciencia ficción. La
creatividad de esos autores de alguna manera estimula mis propios jugos creativos para el
software.
129
TIME BOX ING Y TOMATES
Una forma muy efectiva que he usado para administrar mi tiempo y enfoque es usar la conocida
Técnica Pomodoro,2 también conocida como tomates. La idea basica es muy simple. Configura un
temporizador de cocina estándar (tradicionalmente con forma de tomate) durante 25 minutos.
Mientras ese temporizador está funcionando, no dejes que nada interfiera con lo que estás
haciendo. Si suena el teléfono, responda y cortésmente pregunte si puede volver a llamar dentro
de 25 minutos. Si alguien se detiene para hacerte una pregunta, pregunta cortésmente si puedes
responderle en 25 minutos. Independientemente de la interrupción, simplemente aplazarla
hasta que suene el temporizador. ¡Después de todo, pocas interrupciones son tan horriblemente
urgentes que no pueden esperar 25 minutos!
Cuando suena el temporizador de tomate, deja de hacer lo que está haciendo inmediatamente.
Usted se ocupa de las interrupciones que ocurrieron durante el tomate. Luego te tomas un
descanso de cinco minutos más o menos. Luego configura el temporizador para otros 25 minutos y
comienza el siguiente tomate. Cada cuarto tomate tomas un descanso más largo de 30
minutos más o menos.
Hay bastante escrito sobre esta técnica, y le insto a que lo lea.
Sin embargo, la descripción anterior debería proporcionarle la esencia de la técnica.
Usando esta técnica, su tiempo se divide en tomate y tiempo sin tomate.
El tiempo del tomate es productivo. Es dentro de los tomates donde realmente se hace el trabajo.
El tiempo fuera de los tomates son distracciones, reuniones, descansos u otro tiempo que no se
dedica a trabajar en sus tareas.
¿Cuántos tomates puedes hacer en un día? En un buen día, puede hacer 12 o incluso 14 tomates.
En un mal día, es posible que solo hagas dos o tres.
Si los cuenta y los grafica, obtendrá una idea bastante rápida de cuánto de su día pasa productivo y
cuánto gasta lidiando con "cosas".
Algunas personas se sienten tan cómodas con la técnica que estiman sus tareas en tomates y luego
miden su velocidad de tomate semanal. Pero esto es solo 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. http://www.pomodorotechnique.com/
130
CALLEJONES CIEGOS
AVO I BAILO
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 un
agujero de rata ineludible. O tal vez simplemente no quieres hacerlo.
PRIORIDAD I NVERSIÓN
Cualquiera que sea la razón, encuentra formas de evitar hacer el trabajo real. Te convences de que algo
más es más urgente y lo haces en su lugar. Esto se llama inversión de prioridad. Puede aumentar 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 hacer frente a 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 estamos haciendo. Estamos construyendo una defensa para protegernos del juicio de los demás.
Claramente, este es 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á una
decisión y deambulará por un camino técnico que no conduce a ninguna parte.
Cuanto más investido estés en tu decisión, más tiempo vagarás por el desierto. Si te has jugado 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 necesita es darse cuenta rápidamente cuando está
en uno y tener el coraje de retroceder. Esto a veces se llama la regla de los hoyos: cuando estés en
uno, deja de cavar.
131
Los profesionales evitan involucrarse tanto en una idea que no pueden abandonarla y dar la
vuelta. Mantienen una mente abierta sobre otras ideas para que cuando lleguen a un callejón sin
salida todavía tengan otras opciones.
PANTANOS , B Y , MPS SWA , Y OTROS DESORDENES

Peor que los callejones sin salida son los líos. Los líos te ralentizan, pero no te detienen.
Los líos impiden su progreso, pero aún puede progresar a través de la 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 compañías destruidas por problemas de software. He visto
disminuir la productividad de los equipos de un jitterbug a un 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 meterse en un callejón sin salida, es
inevitable. La experiencia y la prudencia pueden ayudarte a evitarlos, pero al final
tomarás una decisión que te llevará al lío.
La progresión de tal desorden es insidiosa. Crea 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 escala bien en la dirección en que se mueven los requisitos.
¡Este es el punto de inflexión! Todavía puede volver atrás y arreglar el diseño. Pero también
puedes seguir avanzando. Retroceder parece costoso porque tendrá que volver a trabajar en el
código existente, pero volver nunca será tan fácil como ahora. Si avanza, conducirá al sistema
a un pantano del que nunca podrá salir.
escapar.
132
CONCLUSIÓN
Los profesionales temen los líos mucho más que los callejones sin salida. Siempre
están al acecho de los líos que empiezan a crecer sin límites, y harán todo el esfuerzo
necesario para escapar de ellos lo antes y lo 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á diciendo que todo
estará bien, cuando en realidad se dirige a una perdición compartida.
CONCLUSIÓN
Los profesionales del software son diligentes en la gestión de su tiempo y su enfoque.
Entienden las tentaciones de la inversión de prioridades y la combaten como una
cuestión de honor. Mantienen sus opciones abiertas manteniendo una mente abierta
sobre soluciones alternativas. Nunca se involucran tanto en una solución que no
puedan abandonarla. Y siempre están atentos a los desordenes crecientes, y los
limpian tan pronto como los reconocen. No hay espectáculo más triste que un equipo
de desarrolladores de software trabajando infructuosamente en un pantano cada vez más profundo.
133
10 ESTIMACIÓN
La estimación es una de las actividades más sencillas, pero a la vez 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 cuña principal que se ha abierto entre los empresarios y los desarrolladores.
Es la fuente de casi toda la desconfianza que rige esa relación.
135
CAPÍTULO 10 ESTIMACIÓN
En 1978, fui el desarrollador principal de un programa Z80 integrado de 32K escrito en lenguaje
ensamblador. El programa se grabó en 32 chips 1K ́ 8 EEprom. Estas 32 fichas se
insertaron en tres tableros, cada uno de los cuales contenía 12 fichas.
Teníamos cientos de dispositivos en el campo, instalados en oficinas centrales telefónicas en
todo Estados Unidos. Cada vez que arreglamos un error o añadimos una función, ¡teníamos
que enviar técnicos de servicio de campo a cada una de esas unidades y hacer que
reemplazaran los 32 chips!
Esto fue una pesadilla. Las fichas y los tableros eran frágiles. Los pines de las fichas podrían
doblarse y romperse. La flexión constante de las placas podría dañar las juntas de soldadura. El
riesgo de rotura y error era enorme. El costo para la empresa era demasiado alto.
Mi jefe, Ken Finder, se me acercó y me pidió que arreglara esto. Lo que quería era una forma de
hacer un cambio en un chip que no requiriera que todos los otros chips cambiaran. Si leyó
mis libros o escuchó mis charlas, sabe que despotrico 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 único ejecutable vinculado. 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 tenía 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 simple
que las encajaba, como un rompecabezas, en cada uno de los chips, dejando
aproximadamente 100 bytes de espacio para la expansión. Al comienzo de cada chip pongo una
tabla de punteros a todas las funciones en ese chip. En el arranque, estos punteros se movieron
a la RAM. Se cambió todo el código del sistema para que las funciones se llamaran solo a
través de estos vectores RAM y nunca directamente.
136
ESTIMACION
Sí, lo tienes. Las fichas eran objetos, con vtables. Todas las funciones se desplegaron
polimórficamente. Y sí, así es como aprendí algunos de los principios de OOD, mucho antes de saber
qué era un objeto.
Los beneficios fueron enormes. No solo podíamos implementar chips individuales, también
podíamos hacer parches en el campo moviendo funciones a la RAM y redirigiendo los
vectores. Esto hizo que la depuración de campos y la aplicación de parches en caliente fueran mucho más fáciles.
Pero yo divago. Cuando Ken vino a mí y me pidió que solucionara este problema, sugirió algo
sobre punteros a funciones. Pasé un día o dos formalizando la idea y luego le presenté un
plan detallado. Me preguntó cuánto tiempo tomaría y le respondí que me tomaría alrededor de un mes.
Tomó tres meses.
Solo me he emborrachado dos veces en mi vida, y realmente solo una vez. Fue en la fiesta de Navidad
de Teradyne en 1978. Tenía 26 años.
La fiesta se llevó a cabo en la oficina de Teradyne, que en su mayoría era un espacio de laboratorio abierto.
Todos llegaron temprano, y luego hubo una gran tormenta de nieve que impidió que la banda y el
servicio 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 contigo.
Estaba sentado con las piernas cruzadas en el suelo con Ken (mi jefe, que tenía 29 años en ese
momento y no estaba borracho) llorando por cuánto tiempo me estaba tomando 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 acerca de 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 ha permanecido clara durante las
siguientes décadas. Él dijo: “Sí, creo que te ha tomado mucho tiempo, pero puedo ver que estás
trabajando duro y progresando bien. Es algo que realmente necesitamos. Entonces, no, no estoy
enojado”.
137
¿QUÉ ESTI M ATO YO ?
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 hacer algo para una fecha
determinada, simplemente tienes que hacerlo para 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 se comprometen a menos que sepan que pueden cumplirlos.
Es realmente tan simple como eso. Si se le pide que se comprometa con algo que no está seguro de poder
hacer, entonces su honor está obligado a declinar. Si se le pide que se comprometa con una cita que sabe que
puede lograr, pero que requeriría muchas horas, fines de semana y vacaciones familiares salteadas,
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 sus compromisos y harán planes basados en
ellos. El costo de incumplir esos compromisos, para ellos y para su reputación, es enorme. Faltar a un
compromiso es un acto de deshonestidad apenas un poco menos oneroso que una mentira abierta.
A N ESTIMATE
Una estimación es una suposición. No se implica ningún compromiso. No se hace ninguna promesa.
Perder una estimación no es de ninguna manera deshonroso. La razón por la que hacemos
estimaciones es porque no sabemos cuánto tiempo tomará algo.
Desafortunadamente, la mayoría de los desarrolladores de software son pésimos estimadores. Esto no se debe
a que haya 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
¿QUÉ ES UN ESTIMADO ?
Mike: "¿Cuál es su estimación para completar la tarea Frazzle?"
Pedro: “Tres días”.
¿Peter realmente va a terminar en tres días? Es posible, pero ¿qué tan probable es?
La respuesta a eso 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é 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é hubiera pasado si Mike le hubiera preguntado a Peter qué tan probable era su estimación
de tres días?
Mike: “¿Qué tan probable es que termines en tres días?
Pedro: "Bastante probable".
Mike: "¿Puedes ponerle un número?"
Peter: “Cincuenta o sesenta por ciento”.
Mike: "Así que hay una buena posibilidad de que te lleve cuatro días".
Peter: “Sí, de hecho podría tardar hasta cinco o seis, aunque lo dudo”.
Mike: “¿Cuánto lo dudas?”
Pedro: “Ay, no 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, solo si todo sale mal. Diablos, si todo va
mal, me podría llevar diez o incluso once días. Pero no es muy probable que
tantas cosas salgan mal”.
Ahora estamos empezando a afinar la verdad. La estimación de Peter es una distribución de
probabilidad. En su mente, Peter ve la probabilidad de finalización como lo que se muestra en
la Figura 101.
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 la mente de Peter, es la duración más probable de la tarea.
Pero Mike ve las cosas de manera diferente. Mira la cola de la derecha del gráfico y le preocupa
que Peter realmente pueda tardar once días en terminar.
139
50%
45%
40%
35%
30%
25%
20%
15%
10%
5%
0%
2 3 4 5 6 7 8 9 10 11
Figura 101 Distribución de probabilidad
¿Mike debería estar preocupado por esto? ¡Por supuesto! Murphy1 se saldrá con la suya con Peter, por lo
que es probable que algunas cosas salgan mal.
COMPROMISOS IMPLICADOS _
Así que ahora Mike tiene un problema. No está seguro del tiempo que le tomará a Peter hacer la tarea. Para
minimizar esa incertidumbre, puede pedirle a Peter un compromiso. Esto es algo que Peter no
está en posición de dar.
Mike: "Peter, ¿puedes darme una fecha concreta cuando hayas terminado?"
Pedro: “No, Mike. Como dije, probablemente estará listo en tres, tal vez cuatro,
días."
Mike: "¿Podemos decir cuatro entonces?"
Pedro: “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
IMPERTINENTE
Mike: "Está bien, Peter, pero ¿puedes tratar de que no dure más de seis días?"
La súplica de Mike suena bastante inocente, y Mike ciertamente no tiene malas intenciones.
Pero, ¿qué es exactamente lo que Mike le está pidiendo a Peter que haga? ¿Qué significa “probar”?
Hablamos de esto antes, en el Capítulo 2. La palabra intentar es un término cargado. Si Peter accede a
“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 forma
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 hacen una distinción clara entre estimaciones y compromisos.
No se comprometen a menos que sepan con certeza que tendrán éxito. Tienen cuidado de no hacer
ningún compromiso implícito . Comunican la distribución de probabilidad de sus estimaciones con la
mayor claridad posible, para que los gerentes puedan hacer los planes apropiados.
IMPERTINENTE
En 1957, se creó la Técnica de Evaluación y Revisión de Programas (PERT) para apoyar el proyecto
submarino Polaris de la Marina de los EE. UU. Uno de los elementos de PERT es la forma en que se
calculan las estimaciones. El esquema proporciona una forma muy simple pero muy efectiva de convertir
estimaciones en distribuciones de probabilidad adecuadas para gerentes.
Cuando estima una tarea, proporciona tres números. Esto se llama análisis trivariante:
• O: Estimación Optimista. Este número es tremendamente optimista. Solo podría hacer 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
1% de probabilidad de que ocurra.2 En el caso de Peter, esto sería 1 día, como se muestra en la
figura 101.
• N: Estimación Nominal. Esta es la estimación con la mayor probabilidad de éxito.
Si tuviera que dibujar un gráfico de barras, sería la barra más alta, como se muestra en la
Figura 101. son 3 dias
• P: Estimación Pesimista. Una vez más, esto es tremendamente pesimista. Debería
incluyen todo excepto huracanes, guerra nuclear, agujeros negros perdidos y otras
catástrofes. Una vez más, las matemáticas solo funcionan si este número tiene menos del 1 %
de posibilidades de éxito. En el caso de Peter, este número está fuera del gráfico de la derecha.
Así que 12 días.
Dadas estas tres estimaciones, podemos describir la distribución de probabilidad de la siguiente
manera:
O + 4N + P
• metro =
6
μ es la duración esperada de la tarea. En el caso de Peter es (1+12+12)/6, o alrededor de 4,2
días. Para la mayoría de las tareas, este será un número algo pesimista porque la cola de la
derecha de la distribución es más larga que la cola de la izquierda.3
P−O
• σ =
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 alrededor de 1,8 días.
Dada la estimación de Peter de 4,2/1,8, Mike entiende que esta tarea probablemente se realizará
dentro de 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 de uno en mil son
probablemente seguro.
3. PERT supone que esto se aproxima a una distribución beta. Esto tiene sentido ya que la duración mínima
porque una tarea es a menudo mucho más segura que el máximo. [McConnell2006] Figura 13.
4. Si no sabe qué es una desviación estándar, debe encontrar un buen resumen de probabilidad y estadística.
tics El concepto no es difícil de entender y te será muy útil.
142
IMPERTINENTE
Pero Mike no solo está administrando 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 101.
Tabla 101 Tareas de Peter
Tarea Optimista Nominal Pesimista metro

pag
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 está bastante confiado al respecto, pero
que algo podría salir mal que lo descarrilaría significativamente.
¿Cómo debería Mike interpretar eso? ¿Cuánto tiempo debe planear Mike para que
Peter complete las tres tareas?
Resulta que, con algunos cálculos simples, Mike puede combinar todas las tareas de Peter y
obtener una distribución de probabilidad para todo el conjunto de tareas. La matemática es
bastante sencilla:
•
metro
secuencia = ∑μtarea
Para cualquier secuencia de tareas, la duración esperada de esa secuencia es la
simple suma de todas las duraciones esperadas de las tareas en esa secuencia. Entonces,
si Peter tiene tres tareas para 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 2 2 1/2
+ +1.3 )
(1.8 2.2 =
1/2
(3,24 2+,48 1,69)
+ =
1/2
9.77 = 3,13
143
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 (1 s) e incluso podrían tomar 20 días (2 s). Incluso podría tomar más tiempo,
pero eso es bastante improbable.
Vuelve a mirar la tabla de estimaciones. ¿Puedes sentir la presión de hacer las tres tareas en
cinco días? Después de todo, las estimaciones del mejor de los casos son 1, 1 y 3. Incluso las
estimaciones nominales solo suman 10 días. ¿Cómo llegamos hasta los 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 agrega realismo al plan.
Si es un programador con más de unos pocos años de experiencia, es probable que haya visto
proyectos que se estimaron de manera optimista y que demoraron de tres a cinco veces más
de lo esperado. El esquema PERT simple que se acaba de mostrar es una forma razonable de
ayudar a prevenir el establecimiento de expectativas optimistas. Los profesionales del software
tienen mucho cuidado de establecer expectativas razonables a pesar de la presión de tratar de ir rápido.
TAREAS DE ESTIMACIÓN
Mike y Peter estaban cometiendo un terrible error. Mike le estaba preguntando a Peter cuánto
tiempo tomarían 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. Pueden ayudarlo a estimar sus tareas con mayor precisión de lo que
puede estimarlas 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. Algunos son formales,
algunos son informales; pero todos tienen una cosa en común: el consenso.
La estrategia es sencilla. 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
TAREAS DE ESTIMACIÓN
El enfoque original esbozado por Boehm involucró varias reuniones y documentos que
implican demasiada ceremonia y gastos generales para mi gusto. Prefiero enfoques simples de bajo
costo como el siguiente.
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 la tarea, qué podría confundirla o complicarla y cómo podría
implementarse. Luego, los participantes colocan sus manos debajo de la mesa y levantan de 0 a
5 dedos según el tiempo que creen que tomará la tarea. El moderador cuenta 123 y todos los
participantes muestran sus manos 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 necesita ser absoluto. Mientras las estimaciones sean cercanas, es lo suficientemente
bueno. Entonces, por ejemplo, un poco de 3 y 4 es acuerdo. Sin embargo, si todos levantan 4 dedos
excepto una persona que levanta 1 dedo, entonces tienen algo de qué hablar.
La escala de la estimación se decide al comienzo de la reunión. Podría ser el número de días para una
tarea, o podría ser una escala más interesante como "dedos por tres" o "dedos al cuadrado".
La simultaneidad de mostrar los dedos es importante. No queremos que las personas cambien sus
estimaciones en función de lo que ven que hacen otras personas.
Planificación de póquer
En 2002, James Grenning escribió un artículo encantador6 que describía la “planificación del póquer”.
Esta variación de Delphi de banda ancha se ha vuelto tan popular que varias compañías diferentes
han usado la idea para hacer obsequios de marketing en forma de mazos de cartas de póquer
de planificación . la Red con equipos distribuidos.
6. [Grenning 2002]
7. http://store.mountaingoatsoftware.com/products/planningpokercards
145
La idea es muy simple. Para cada miembro del equipo de estimación, reparta una mano de cartas
con diferentes números en ellas. 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 les 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 tarjetas.
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 ido tan lejos como para usar tarjetas basadas en una serie de Fibonacci.
Otros han incluido tarjetas para el infinito y el signo de interrogación. Personalmente, creo que
cinco cartas con los números 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 mostrar ninguna estimación. 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 comienzan a clasificar las tarjetas entre sí. Las
tareas que toman más tiempo se mueven a la derecha. Las tareas más pequeñas se mueven
hacia la izquierda.
Cualquier miembro del equipo puede mover cualquier tarjeta en cualquier momento, incluso si
otro miembro ya la ha movido. Cualquier carta movida más de h veces se reserva para discusión.
Eventualmente, la clasificación silenciosa se desvanece y la discusión puede comenzar. Se exploran
los desacuerdos sobre el orden de las tarjetas. Puede haber algunas sesiones de diseño rápidas
o algunos marcos de alambre dibujados a mano para ayudar a lograr un consenso.
146
CONCLUSIÓN
El siguiente paso es dibujar líneas entre las tarjetas que representen los tamaños de los baldes.
Estos cubos 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 única estimación nominal
para una tarea. Pero como dijimos antes, 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 pídale al
equipo que levante las cartas para su estimación pesimista y luego tome la más alta. Haces lo mismo
con la estimación optimista y tomas 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 manejar
el error es aprovechar la Ley de los Números Grandes.8 Una implicación de esta ley es que si divide
una tarea grande en muchas tareas más pequeñas y las estima 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 la subestimación y no a
la sobreestimación, por lo que la integración difícilmente 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 comprender
mejor esas tareas 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 y no asumen compromisos que no están seguros de poder cumplir.
8. http://en.wikipedia.org/wiki/Law_of_large_numbers
147
Cuando los profesionales se comprometen, proporcionan números concretos y luego hacen
esos números. Sin embargo, en la mayoría de los casos los profesionales no asumen tales
compromisos. Más bien, proporcionan estimaciones probabilísticas que describen el tiempo
de finalización esperado 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 gerencia.
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. Estas no son las únicas
técnicas de este tipo y no son necesariamente las mejores. Son simplemente
técnicas que he encontrado que funcionan bien para mí.
BIBLIOGRAFÍA
[McConnell2006]: Steve McConnell, Estimación de software: Desmitificando el negro
Arte, Redmond, WA: Microsoft Press, 2006.
[Boehm81]: Barry W. Boehm, Software Engineering Economics, Upper Saddle River, NJ:
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, http://renaissancesoftware.
net/documentos/14documentos/44planingpoker.html
148
11PRESIÓN
Imagina que estás teniendo una experiencia extracorporal, observándote a ti mismo en una
mesa de operaciones mientras un cirujano te 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
con una fecha límite, una fecha límite literal .
149
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 entrenamiento y se adhiera a sus disciplinas?
¿O lo quieres sudando y maldiciendo? ¿Quieres que golpee y arroje instrumentos? ¿Quieres
que culpe a la gerencia por expectativas poco realistas y que se queje continuamente por el
tiempo? ¿Quieres que se comporte como un profesional o como un desarrollador típico?
El desarrollador profesional es tranquilo y decidido bajo presión. A medida que crece la
presión, se adhiere a su entrenamiento y disciplina, sabiendo que son la mejor manera de
cumplir con los plazos y compromisos que lo presionan.
En 1988 estaba trabajando en Clear Communications. Esta fue una puesta en marcha que
nunca llegó a empezar. Quemamos nuestra primera ronda de financiamiento y luego tuvimos
que buscar una segunda, y luego una tercera.
La visión inicial del producto sonaba bien, pero parecía que la arquitectura del producto
nunca se cimentaba. Al principio, el producto era tanto software como hardware.
Luego se convirtió en software solamente. La plataforma de software cambió de PC a
Sparcstations. Los clientes cambiaron de gama alta a gama baja.
Eventualmente, incluso la intención original del producto se desvió cuando la compañía trató
de encontrar algo que generara ingresos. En los casi cuatro años que pasé allí, no creo que
la empresa haya visto un centavo de ingresos.
No hace falta decir que 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 largo.
Hubo discusiones con gritos e insultos. Hubo intrigas y subterfugios. Había puños que
atravesaban las paredes, bolígrafos arrojados furiosamente a las pizarras blancas,
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 características debían prepararse para ferias
comerciales o demostraciones de clientes. Cualquier cosa que pidiera un cliente, sin importar cuán tonta sea,
la tendríamos lista para la próxima demostración. El tiempo siempre era demasiado corto. El trabajo
siempre estaba atrasado. Los horarios siempre eran abrumadores.
150
EVITAR LA PRESIÓN
Si trabajaras 80 horas a la semana, podrías ser un héroe. Si organizaste un poco de
desorden para una demostración de cliente, podrías ser un héroe. Si lo hiciste lo suficiente,
podrías ser ascendido. Si no lo hacía, podría ser despedido. Era una empresa nueva,
todo se trataba de la "equidad de sudor". Y en 1988, con casi 20 años de experiencia en
mi haber, 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 muchachos 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 la casa. Fui yo quien tiró los bolígrafos y gritó. Hice que despidieran a gente
si no se ponían en forma. Fue horrible. yo era horrible
Luego llegó el día en que mi esposa me obligó a mirarme largamente en el espejo. No
me gustó lo que vi. Me dijo que no era muy agradable estar cerca de mí.
Tuve que estar de acuerdo. Pero no me gustó, así que salí furioso de la casa y comencé
a caminar sin rumbo fijo. Caminé durante treinta minutos más o menos, 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 en el espejo, el pobre idiota que se había estado
haciendo la vida imposible para sí mismo y para 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 escribir funciones C de 3000 líneas.
Decidí que iba a disfrutar de mi carrera haciéndolo bien, no haciéndolo estúpidamente.
Dejé ese trabajo tan profesionalmente como pude y me convertí en consultor. Desde ese
día nunca he llamado a otra persona "jefe".
EVITAR LA PRESIÓN
La mejor manera de mantener la calma bajo presión es evitar las situaciones que provocan
presión. Es posible que esa evitación 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
COMPROMISOS
Como descubrimos en el Capítulo 10, es importante evitar comprometerse 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 al negocio para que puedan gestionarlo adecuadamente. Aceptar
compromisos poco realistas frustra este objetivo y perjudica tanto al negocio como a nosotros
mismos.
A veces se hacen compromisos por nosotros. A veces nos encontramos con que nuestra empresa
ha hecho promesas a los clientes sin consultarnos. Cuando esto sucede, nuestro honor nos obliga
a ayudar a la empresa a encontrar una manera de cumplir con esos compromisos.
Sin embargo, no estamos obligados por el 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 asumidos por la empresa. Al final, si no podemos encontrar la forma 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 está fallando y su cheque de pago se retrasa
debido a compromisos incumplidos, es difícil no sentir la presión. Pero si te has comportado
profesionalmente, al menos puedes mantener la cabeza en alto mientras buscas un nuevo
trabajo.
MANTENERSE LIMPIO
La forma de ir rápido y mantener los plazos a raya es mantenerse limpio. Los profesionales no
sucumben a la tentación de crear un desorden para moverse 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 quiere decir que pasemos interminables horas puliendo código.
Simplemente significa que no toleramos los líos. Sabemos que los líos nos atrasarán,
haciéndonos perder fechas y romper compromisos. Así que hacemos el mejor trabajo que
podemos y mantenemos nuestra producción lo más limpia posible.
152
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 cambias tu
comportamiento en una crisis, entonces realmente no crees en tu comportamiento normal.
Si sigue la disciplina del desarrollo basado en pruebas en tiempos que no son de crisis
pero la abandona durante una crisis, entonces realmente no confía en que TDD sea útil.
Si mantiene su código limpio durante los tiempos normales pero hace líos en una crisis,
entonces realmente no cree que los líos lo ralentizan. Si se emparejan en una crisis pero
normalmente no se emparejan, entonces creen que emparejarse es más eficiente que no
emparejarse.
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 ser
en una crisis.
No cambie su comportamiento cuando llegue el momento crítico. Si sus disciplinas son la
mejor manera de trabajar, entonces deben seguirse incluso en las profundidades 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 toma más tiempo de lo que nadie pensó que tomaría. A
veces, el diseño inicial es simplemente incorrecto y debe volver a trabajarse. A veces se
pierde un miembro del equipo o un cliente valioso. A veces haces un compromiso que
simplemente no puedes cumplir. ¿Y que?
NO ENTRE EN PÁNICO
Maneja tu estrés. Las noches de insomnio no te ayudarán a terminar más rápido. Sentarse e
inquietarse tampoco ayudará. ¡Y lo peor que podrías hacer es apresurarte!
Resiste esa tentación a toda costa. Apresurarte solo te hundirá más en el hoyo.
153
En su lugar, disminuya la velocidad. Piense bien en el problema. Traza un curso hacia
el mejor resultado posible y luego avanza hacia ese resultado a un ritmo razonable y
constante.
COMUNICAR
Hágales saber a su equipo y a sus superiores que está en problemas. Cuéntales tus mejores
planes para salir del apuro. Pídales su opinión y orientación.
Evite crear sorpresas. Nada hace que la gente se enoje más y sea menos racional 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 razon que tienes
disciplinas es brindarle orientación en momentos de alta presión. Son los tiempos de prestar
especial atención a todas tus disciplinas. Estos no son los tiempos para cuestionarlos o
abandonarlos.
En lugar de buscar con pánico algo, cualquier cosa, que lo ayude a terminar más rápido, sea
más deliberado y dedicado a seguir las disciplinas elegidas. Si sigue TDD, escriba aún
más pruebas de lo habitual. Si eres un refactorizador despiadado, entonces refactoriza aún
más. Si mantiene sus funciones pequeñas, entonces manténgalas aún más pequeñas. La
única forma de superar la olla a presión es confiar en lo que ya sabes que funciona: tus
disciplinas.
OBTENGA AYUDA
¡Par! Cuando la temperatura esté encendida, busque un asociado que esté dispuesto a
programar en pareja con usted. Terminará más rápido, con menos defectos. Tu
compañero de pareja te ayudará a mantener tus disciplinas y evitará que entres en pánico. Tu
pareja detectará las cosas que te pierdes, tendrá ideas útiles y tomará el relevo cuando
pierdas la concentración.
154
CONCLUSIÓN
De la misma manera, cuando veas a alguien que está bajo presión, ofrécete a
trabajar con ellos. Ayúdalos a salir del agujero en el que están.
CONCLUSIÓN
El truco para manejar la presión es evitarla cuando puedas y capearla cuando no
puedas. Lo evita gestionando compromisos, siguiendo sus disciplinas y
manteniéndose limpio. Lo supera manteniendo la calma, comunicándose, siguiendo
sus disciplinas y obteniendo ayuda.
155
12 COLABORACIÓN
La mayoría del software es creado por equipos. Los equipos son más efectivos cuando los
miembros del equipo colaboran profesionalmente. No es profesional ser un solitario o un
recluso en un equipo.
En 1974 tenía 22 años. Mi matrimonio con mi maravillosa esposa, Ann Marie, apenas tenía seis
meses. Aún faltaba un año para el nacimiento de mi primera hija, Angela. Y trabajé en una
división de Teradyne conocida como Chicago Laser Systems.
157
CAPÍTULO 12 COLABORACIÓN
Trabajando a mi lado estaba mi compañero de la escuela secundaria, Tim Conrad. Tim y yo
habíamos obrado bastantes milagros en nuestro tiempo. Construimos computadoras juntos en
su sótano. Construimos las escaleras de Jacob en la mía. Nos enseñamos unos a otros
cómo programar PDP8 y cómo conectar circuitos integrados y transistores en calculadoras que
funcionen.
Éramos programadores trabajando en un sistema que usaba láseres para recortar componentes
electrónicos como resistencias y capacitores 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 PDP8 de Teradyne. Escribíamos en
lenguaje ensamblador y nuestros archivos fuente se guardaban en cartuchos de cinta magnética.
Aunque podíamos editar en una pantalla, el proceso fue bastante complicado, por lo que usamos
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 llamó a una función dada o se usó una constante dada. Como se
puede imaginar, esto fue un gran obstáculo.
Entonces, un día, Tim y yo decidimos que escribiríamos 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 era bastante simple 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. Tomó más de una hora procesar nuestro Programa Operativo
Maestro (el MOP).
La razón por la que era tan lento era que teníamos la tabla de símbolos en crecimiento en un solo
búfer de memoria. Cada vez que encontramos una nueva referencia, la insertamos en el búfer,
moviendo el resto del búfer unos pocos bytes hacia abajo 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 ni idea de cómo hacer un algoritmo rápido.
Simplemente sabíamos que lo que estábamos haciendo era demasiado lento.
158
PROGRAMADORES VERSUS PERSONAS
Así que probamos una cosa tras otra. Intentamos poner las referencias en listas enlazadas.
Intentamos dejar huecos en la matriz y solo hacer crecer el búfer cuando se llenaban los huecos.
Intentamos crear listas enlazadas de brechas. Probamos todo tipo de ideas locas.
Nos paramos frente a la pizarra en nuestra oficina y dibujamos diagramas de nuestras
estructuras de datos y realizamos cálculos para predecir el rendimiento. Llegaríamos 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 ralentizaron. 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 se redujera a menos de 15 minutos, que era muy parecido al
tiempo que se tardaba simplemente en leer la cinta de origen. Así que estábamos satisfechos.
No nos convertimos en programadores porque nos gusta trabajar con personas. Por regla general,
encontramos relaciones interpersonales desordenadas 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.
OK, eso es una gran sobregeneralización y hay un montón de excepciones. Hay muchos programadores
que son buenos para trabajar con personas y disfrutan el desafío. Pero el promedio del grupo aún
tiende en la dirección que indiqué. Nosotros, los programadores, disfrutamos de la privación
sensorial leve y la inmersión de enfoque como un capullo.
PROGRAMADORES VERSUS EMPLEADORES
En los años setenta y ochenta, mientras trabajaba como programador en Teradyne, aprendí a ser
realmente bueno en la depuración. Me encantaba el desafío y me lanzaba a los problemas con vigor y
entusiasmo. ¡Ningún bicho podría esconderse mucho tiempo de mí!
159
¡Cuando resolví un error fue como ganar una victoria o matar al Jabberwock!
Acudía a mi jefe, Ken Finder, espada Vorpal en mano, y le describía apasionadamente lo
interesante que era el bicho. Un día Ken finalmente estalló en frustración: “Los errores no
son interesantes. ¡Los errores solo necesitan ser arreglados!”
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 profundamente 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 se beneficiará la empresa que lo
emplea.
Lo peor que puede hacer un programador profesional es enterrarse felizmente en una tumba de
tecnología mientras el negocio se derrumba y se quema a su alrededor. ¡ Tu trabajo es mantener
el negocio a flote!
Entonces, los programadores profesionales se toman el tiempo para entender 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 a corto y largo plazo del equipo.
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. Estaba trabajando
para Outboard Marine Corp. en ese momento. Estaba ayudando a escribir un sistema
de automatización de fábrica que usaba IBM System/7s para monitorear docenas de máquinas
de fundición a presió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, fue competente y motivado.
Mis dos compañeros de equipo de programación fueron agradables y serviciales. teniamos un laboratorio
160
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,
enfocado y estaba a cargo.
Todo debería haber sido genial. El problema era yo. Estaba lo suficientemente entusiasmado
con el proyecto y con la tecnología, pero a la gran edad de 24 años simplemente no podía
preocuparme por el negocio o por su estructura política interna.
Mi primer error fue en mi primer día. Me presenté sin llevar corbata. Había usado uno en mi
entrevista y había visto que todos los demás usaban corbatas, pero no logré hacer la conexión.
Entonces, en mi primer día, Ralph vino a mí y me dijo claramente: “Aquí usamos corbatas”.
No puedo decirte cuánto me molestó eso. Me molestó en un nivel profundo. Usaba 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 podía 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. Yo era fácilmente el mejor programador técnico del equipo. Podí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. Así que las horas y las fechas no importaban mucho
a mi
La decisión de despedirme se tomó un día cuando no me presenté a tiempo para un hito.
Aparentemente, John nos había dicho a todos que quería una demostración de las funciones
operativas el próximo lunes. Estoy seguro de que sabía sobre esto, pero las fechas y las horas
simplemente no eran importantes para mí.
Estábamos en desarrollo activo. El sistema no estaba en producción. No había razón para dejar
el sistema funcionando cuando no había nadie en el laboratorio. Debo haber sido 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 había quedado grabado en mi cerebro.
161
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 idea de la demostración del lunes, pero me di
cuenta por el lenguaje corporal de todos los demás que algo andaba mal. Luego, John se acercó y
me susurró al oído: "¿Y si Stenberg hubiera decidido visitarme?". Luego se alejó disgustado.
Stenberg fue 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 más tarde ese día. Me dijo que tenía que cambiar mi
actitud de inmediato 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í mismo y
a mi trabajo.
¡Y lo hice! Dejé de llegar tarde. Empecé a prestar atención a la política interna. Empecé a
entender 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 era demasiado poco, demasiado tarde. La suerte estaba echada. Recibí una segunda carta
de advertencia un mes después por un error trivial que cometí. Debería haberme dado cuenta en
ese momento de que las cartas eran una formalidad y que ya se había tomado la decisión de
despedirme. Pero estaba decidido a rescatar la situación. Así que trabajé aún más duro.
La reunión de terminación se produjo unas semanas después.
Fui a casa ese día 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.
162
PROGRAMADORES VERSUS PROGRAMADORES
Los programadores a menudo tienen 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 permitían que otros
programadores vieran su código. Esta es una receta para el desastre.
Una vez fui consultor de una empresa que fabricaba impresoras de gama alta. 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 trabajaba en su dispositivo. Un tipo escribiría el código para el alimentador, otro
tipo escribiría el código para la engrapadora. Cada uno de ellos mantuvo su tecnología para sí mismos
y evitó que alguien 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 trabajaba 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 ninguna
cantidad de argumentos de mi parte pudo convencer a los programadores (o al negocio) de cambiar
sus formas. Después de todo, sus revisiones salariales estaban vinculadas 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 revisar
cualquier módulo y hacer los cambios que considere apropiados. Quiero que el equipo sea el
dueño del código, no los individuos.
163
Los desarrolladores profesionales no impiden que otros trabajen en el código. No construyen
muros de propiedad alrededor del código. Más bien, trabajan entre sí en la mayor parte del sistema
que pueden. 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. Encuentro esto
extraño ya que la mayoría de los programadores se emparejarán en emergencias. ¿Por qué?
Porque es claramente la forma más eficiente de resolver el problema. Simplemente se remonta al
viejo adagio: 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?
No te voy a citar estudios, aunque hay algunos que se podrían citar. No os voy a contar
anécdotas, aunque hay muchas que podría contar. Ni siquiera voy a decirte cuánto debes emparejar.
Lo único que te voy a decir es que la pareja de profesionales. ¿Por qué? Porque al menos para
algunos problemas es la forma más eficiente de resolverlos. Pero esa no es la única razón.
Los profesionales también se emparejan porque es la mejor manera de compartir conocimientos
entre ellos. Los profesionales no crean silos de conocimiento. Por el contrario, aprenden las
diferentes partes del sistema y el negocio asociándose entre sí. Reconocen que aunque todos los
miembros del equipo tienen una posición para jugar, todos los miembros del equipo también
deberían poder jugar en otra posición en caso de apuro.
Los profesionales se emparejan porque es la mejor manera de revisar el código. Ningún sistema
debe consistir en 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 efectiva de revisar el código es colaborar en su escritura.
CEREBELOS
Tomé el tren a Chicago una mañana en 2000 durante el apogeo del auge de las punto com.
Cuando bajé del tren al andén, me asaltó un enorme cartel que colgaba sobre las puertas de
salida. El letrero era para un conocido
164
CEREBELOS
empresa de software que estaba reclutando programadores. Decía: Ven a frotar cerebelos
con los mejores.
Inmediatamente me llamó la atención la repugnante estupidez de un cartel como ese.
Estos pobres publicistas despistados estaban tratando de atraer a una población de
programadores altamente técnica, inteligente y bien informada. Este es el tipo de personas que
no soportan la estupidez particularmente bien. Los anunciantes intentaban evocar la
imagen del intercambio de conocimientos con otras personas muy inteligentes.
Desafortunadamente, se refirieron a una parte del cerebro, el cerebelo, que se ocupa del
control de los músculos finos, no de la inteligencia. Entonces, las mismas personas
que estaban tratando de atraer se burlaban de un error tan tonto.
Pero algo más me intrigó sobre ese cartel. Me hizo pensar en un grupo de personas tratando
de frotar cerebelos. Dado que el cerebelo se encuentra en la parte posterior del cerebro, la
mejor manera de frotar los cerebelos es mirarlos uno contra el otro. Me imaginé a un
equipo de programadores en cubículos, sentados en rincones de espaldas, mirando pantallas
mientras usaban audífonos. 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
rincones con auriculares. Así que los quiero sentados en mesas uno frente al otro. Quiero
que seáis capaces de oler el miedo del otro. Quiero que puedas escuchar los murmullos de
frustración de alguien. Quiero una comunicación fortuita, tanto verbal como corporal. Quiero
que se comuniquen como una unidad.
Quizás creas que trabajas mejor cuando trabajas solo. Eso puede ser cierto, pero no
significa que el equipo funcione mejor cuando trabajas solo.
Y, de hecho, es muy poco probable que trabajes mejor cuando trabajas solo.
Hay momentos en que trabajar solo es lo correcto. Hay momentos en los que simplemente
necesita pensar largo y tendido sobre un problema. Hay momentos en 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 los demás y emparejarse con ellos una gran parte del
tiempo.
165
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. Tenemos que trabajar con
nuestro negocio, y tenemos que trabajar con los demás.
Sé que sé. ¿No sería genial si nos encerraran en una habitación con seis pantallas
gigantes, un tubo T3, una matriz paralela 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 debe ser. Si realmente queremos pasar nuestros días
programando, vamos a tener que aprender a hablar con la gente.1
1. Una referencia a la última palabra de la película Soylent Green.
166
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
CAPÍTULO 13 EQUIPOS Y PROYECTOS
¿ SE MEZCLA ? _
He sido consultor de varios bancos y compañías de seguros a lo largo de los años.
Una cosa que parecen tener en común es la forma extraña en que dividen los proyectos.
A menudo, un proyecto en un banco será un trabajo relativamente pequeño que requiere uno o dos
programadores durante algunas semanas. Este proyecto a menudo contará con un gerente de
proyecto, que también está administrando otros proyectos. Contará con un analista comercial, que
también proporcionará los requisitos para otros proyectos. Contará con algunos programadores que
también están trabajando en otros proyectos. Se asignará uno o dos probadores, y ellos también
trabajarán en otros proyectos.
¿Ves el patrón? El proyecto es tan pequeño que no se le puede asignar a ninguna persona a tiempo
completo. Todo el mundo está trabajando en el proyecto al 50, o incluso al 25 por ciento.
Ahora aquí hay una regla: no existe tal cosa como 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
del tiempo al proyecto B, especialmente cuando los dos proyectos tienen dos gerentes de proyecto
diferentes, analistas de negocios diferentes, programadores diferentes y evaluadores diferentes.
¿Cómo en la cocina del infierno puedes llamar equipo a una monstruosidad como esa? Eso no es un
equipo, es algo que salió de una licuadora Waring.
EL EQUIPO GELIFICADO
Lleva tiempo formar un equipo. Los miembros del equipo comienzan a formar relaciones.
Aprenden a colaborar entre ellos. Aprenden las peculiaridades, fortalezas y debilidades de los demás.
Eventualmente, el equipo comienza a solidificarse.
Hay algo realmente mágico en un equipo gelificado. Pueden hacer milagros.
Se anticipan, se cubren, se apoyan y se exigen lo mejor. Ellos hacen que las cosas sucedan.
Un equipo gelificado suele estar formado por una docena de personas. Podrían ser tantos como
veinte o tan pocos como tres, pero el mejor número es probablemente alrededor de doce. El
168
SE MEZCLA ? _
El equipo debe estar compuesto por programadores, evaluadores y analistas. Y debe tener un
director de proyecto.
La proporción de programadores a probadores y analistas puede variar mucho, pero 2:1 es un
buen número. Entonces, un equipo de doce bien formado podría tener siete programadores, dos
evaluadores, dos analistas y un gerente de proyecto.
Los analistas desarrollan los requisitos y escriben pruebas de aceptación automatizadas para ellos.
Los probadores 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 enfocan en el valor
comercial; los probadores 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 gerente de 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 el papel de entrenador o maestro a tiempo
parcial, con la responsabilidad de defender el proceso y las disciplinas del equipo. Actúan como la
conciencia del equipo cuando el equipo se ve tentado a abandonar el proceso debido a la
presión del cronograma.
Fermentación
Se necesita tiempo para que un equipo como este resuelva sus diferencias, llegue a un acuerdo
entre sí y realmente se una. Podría tomar seis meses. Incluso podría tomar un año. Pero una
vez que sucede, es mágico. Un equipo gelificado planificará en conjunto, resolverá problemas
en conjunto, enfrentará los problemas en conjunto y hará las cosas.
Una vez que esto sucede, es ridículo romperlo solo porque un proyecto llega a su fin. Lo
mejor es mantener unido a ese equipo 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 los proyectos. Este
es un enfoque tonto. Los equipos simplemente no pueden gelificarse. Los individuos están sólo en el
169
CAPÍTULO 13 EQUIPOS Y PROYECTOS
proyecto por poco tiempo, y solo por un porcentaje de su tiempo, y por lo tanto nunca aprenden
cómo tratarse unos con otros.
Las organizaciones de desarrollo profesional asignan proyectos a equipos gelificados
existentes, no forman equipos alrededor de proyectos. Un equipo gelificado puede aceptar
muchos proyectos simultáneamente y dividirá el trabajo de acuerdo con sus propias
opiniones, habilidades y capacidades. El equipo gelificado hará los proyectos.
¿ P ERO CÓMO MANEJAS ESO ? _ _ _
Los equipos tienen velocidades.1 La velocidad de un equipo es simplemente la cantidad de
trabajo que puede realizar en un período fijo de tiempo. 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 logran por semana.
La velocidad es una medida estadística. Un equipo puede lograr 38 puntos en una semana, 42
en la siguiente y 25 en la siguiente. Con el tiempo, esto se promediará.
La gerencia puede establecer objetivos para cada proyecto dado a un equipo. Por ejemplo, si la
velocidad promedio de un equipo es 50 y tienen tres proyectos en los que están trabajando, la
gerencia puede pedirle al equipo que divida su esfuerzo en 15, 15 y 20.
Además de tener un equipo capacitado 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; ponga el
100% de su esfuerzo en ese proyecto durante las próximas tres semanas”.
Reasignar prioridades tan rápido es prácticamente imposible con los equipos que salieron de
la licuadora, pero los equipos gelificados que están trabajando en dos o tres proyectos al
mismo tiempo pueden convertirse en un centavo.
EL DILEMA DEL PROPIETARIO DEL PROYECTO
Una de las objeciones al enfoque que defiendo es que los dueños del proyecto pierden algo de
seguridad y poder. Propietarios de proyectos que tienen un equipo dedicado a
1. [RCM2003] págs. 20–22; [COHN2006] Busque en el índice muchas referencias excelentes a la velocidad.
170
BIBLIOGRAFÍA
su proyecto puede contar con el esfuerzo de ese equipo. Saben que como formar y
disolver un equipo es una operación costosa, el negocio no se lo llevará por razones de corto
plazo.
Por otro lado, si los proyectos se entregan a equipos gelificados, y si 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 ser eliminados repentinamente de él.
Francamente, prefiero la última situación. La empresa no debe tener las manos atadas 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 se muevan juntos de un proyecto a otro y puedan asumir más de
un proyecto a la vez. El objetivo de formar un equipo es darle suficiente tiempo para
consolidarse y luego mantenerlo unido como motor para realizar muchos proyectos.
BIBLIOGRAFÍA
[RCM2003]: Robert C. Martin, Desarrollo de software ágil: principios, patrones y prácticas,
Upper Saddle River, NJ: Prentice Hall, 2003.
[COHN2006]: Mike Cohn, Estimación y planificación ágiles, Upper Saddle River,
Nueva Jersey: Prentice Hall, 2006.
171
14
ME NTO ANILLO ,
APRENDIZAJE Y
ARTESANÍA
Siempre me ha decepcionado la calidad de los graduados de informática. No es
que los graduados no sean brillantes o talentosos, es solo que no se les ha
enseñado de qué se trata realmente la programación.
173
CAPÍTULO 14 TUTORÍA, APRENDIZAJE Y ARTESANÍA
GRADOS DE FALLO
Una vez entrevisté a una mujer joven que estaba trabajando en su maestría en informática para una
universidad importante. Estaba solicitando un puesto de pasante de verano. Le pedí que escribiera
algo de código conmigo y me dijo: "Realmente no escribo código".
Lea el párrafo anterior nuevamente y luego salte de este al siguiente.
Le pregunté qué cursos de programación había tomado para obtener su maestría. Dijo que no había
tomado ninguno.
Tal vez le gustaría comenzar desde el principio del capítulo solo para asegurarse de que no ha caído
en un universo alternativo o acaba de despertarse de un mal sueño.
En este punto, es posible que se esté preguntando cómo un estudiante en un programa de maestría
en CS puede evitar un curso de programación. Me pregunté lo mismo en ese momento. Todavía
me pregunto hoy.
Por supuesto, esa 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 a pesar
de la universidad.
Ahora no me malinterpretes. Creo que es posible obtener una excelente educación en una
universidad. Es solo que también creo que es posible pasar por el sistema y obtener un diploma,
y no mucho más.
Y hay otro problema. Incluso los mejores programas de licenciatura en informática no suelen
preparar al joven graduado para lo que encontrará en la industria. Esta no es una acusación
de los programas de grado sino que es la realidad de casi todas las disciplinas.
Lo que aprendes en la escuela y lo que encuentras en el trabajo a menudo son cosas muy diferentes.
MENTORÍA
¿Cómo aprendemos a programar? Déjame contarte mi historia sobre ser mentor.
174
MENTORÍA
DI GI COMP I, MI PRIMERA COMPUTADORA
En 1964, mi madre me regaló una pequeña computadora de plástico para mi duodécimo
cumpleaños. Se llamaba DigiComp I.1. Tenía tres chanclas de plástico y seis compuertas
de plástico . Puede conectar las salidas de los flipflops a las entradas de las compuertas
y . También puede conectar la salida de las compuertas and a las entradas de los flipflops.
En resumen, esto le permitió crear una máquina de estados finitos de tres bits.
El kit venía con un manual que te daba 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 qué hacían los tubos. ¡Encontré esto muy frustrante!
Observé la máquina durante horas y determiné cómo funcionaba en el nivel más bajo; pero
no pude, por mi vida, averiguar 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 me enviarían un manual que me
decía 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 simple 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 encajen en
6 compuertas and.
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 envió escalofríos por mi espina dorsal. 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 lo puso en
un rumbo del que no podía alejarse?
1. Hay muchos sitios web que ofrecen simuladores de esta pequeña y estimulante computadora.
2. Todavía tengo este manual. Ocupa un lugar de honor en una de mis estanterías.
175
No lo descubrí todo por mí mismo. Fui asesorado. Algunas personas muy amables y muy hábiles (con
las que tengo una gran deuda de gratitud) se tomaron el tiempo de escribir un tratado sobre álgebra
booleana que era accesible para 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 permitieron hacer que esa computadora
hiciera lo que yo quería que hiciera.
Acabo de bajar mi copia de ese fatídico manual. Lo guardo en una bolsa ziplock.
Sin embargo, los años han pasado factura al amarillear las páginas y volverlas quebradizas. Aún así, el
poder de las palabras brilla en ellos. La elegancia de su descripción del álgebra booleana consumió tres
escasas páginas. Su recorrido paso a paso de las ecuaciones para cada uno de los programas originales
sigue siendo convincente. Fue un trabajo 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 ECP18 EN LA ESCUELA SECUNDARIA
A la edad de quince años, como estudiante de primer año en la escuela secundaria, me gustaba pasar
el rato en el departamento de matemáticas. (¡Imagínate!) Un día trajeron una máquina del tamaño de una
sierra de mesa. Era una computadora educativa hecha para escuelas secundarias, llamada ECP18.
Nuestra escuela estaba recibiendo una demostración de dos semanas.
Me quedé en un segundo plano mientras hablaban los maestros y los técnicos. Esta máquina tenía una
palabra de 15 bits (¿qué es una palabra?) y una memoria de batería de 1024 palabras. (Sabía lo que
era la memoria de batería para entonces, pero solo en concepto).
Cuando lo encendieron, emitió un zumbido que recordaba el despegue de un avión a reacción. Supuse que
era el tambor girando. Una vez al día, estaba relativamente tranquilo.
La máquina era preciosa. Era esencialmente un escritorio de oficina con un maravilloso panel de
control que sobresalía de la parte superior como el puente de mando de un barco de guerra. 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 encendían cuando se
presionaban y que podía presionarlos nuevamente para apagarlos. También noté que había otros botones
que estaban presionando; botones con nombres como depositar y ejecutar.
176
MENTORÍA
Los botones de cada fila se agruparon en cinco grupos de tres. Mi Digi Comp también
era de tres bits, por lo que podía leer un dígito octal cuando se expresaba en binario.
No fue un gran salto darse cuenta de que estos eran solo cinco dígitos octales.
Mientras los técnicos presionaban los botones, podía escucharlos murmurar para sí mismos.
Presionarían 1, 5, 2, 0, 4, en la fila del búfer de memoria mientras se decían a sí
mismos, "almacenar en 204". Presionarían 1, 0, 2, 1, 3 y murmurarían, "carga 213 en el
acumulador". ¡Había una fila de botones llamada acumulador!
Diez minutos de eso y estaba bastante claro para mi mente de quince años 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 en el 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
y conceptos de instrucciones. Cuando los técnicos se fueron, yo sabía lo básico de
cómo funcionaba esa máquina.
Esa tarde, durante una sala de estudio, entré sigilosamente en el laboratorio de
matemáticas y comencé a jugar con la computadora. ¡Hace mucho tiempo que había
aprendido que es mejor pedir perdón que permiso! Conecté 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!
Conecté 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úpida y afortunada 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 observando
a los técnicos. Me complació haber interpretado las que conocía correctamente y me
emocioné con las demás. Sin embargo, una de las nuevas instrucciones fue HLT. Dio la
casualidad de que la instrucción de alto era una palabra de todo ceros. Y dio la casualidad
de que había puesto una palabra de todos los ceros al final de cada uno de mis programas
para poder cargarlo en el acumulador para borrarlo. El concepto de una parada simplemente
no se me había ocurrido. ¡Me imaginé que el programa se detendría cuando terminara!
177
Recuerdo que en un momento estaba sentado en el laboratorio de matemáticas viendo a
uno de los maestros luchar para que un programa funcionara. Estaba tratando de
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 binario, agregarlos, volver a convertirlos a decimales y codificarlos
nuevamente a caracteres. Y, créame, ¡es mucho peor cuando ingresa el programa en
binario a través del panel frontal!
Observé 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: "¡Guau, 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ágico para
mí. Y nunca me habló mientras yo miraba por encima de su hombro. Efectivamente,
nadie me habló de este ordenador. Creo que me consideraban una molestia para ser
ignorada, revoloteando por el laboratorio de matemáticas como una polilla. Baste decir
que ni el estudiante ni los profesores habían desarrollado un alto grado de habilidad social.
Al final consiguió que su programa funcionara. Ha sido increíble verlo. Tecleaba 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ó alrededor de 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 me enteré. Pero me hizo darme cuenta
de que el enfoque de un problema puede tener un efecto profundo en el usuario. A pesar de
que el programa produjo la respuesta correcta, todavía había algo mal en él.
Esto fue tutoría. Ciertamente no era el tipo de tutoría que podría haber esperado. Hubiera
sido bueno si uno de esos maestros me hubiera tomado bajo su ala y trabajado conmigo.
Pero no importaba, porque yo estaba observando
ellos y aprendiendo a un ritmo vertiginoso.
178
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 las personas que intentaban ignorarme activamente. En ambos casos, el
conocimiento adquirido fue profundo y fundamental.
Por supuesto, también tuve otros tipos de mentores. Estaba el amable vecino que
trabajaba en Teletipo que me trajo a casa una caja de 30 repetidores telefónicos para
jugar. ¡Déjame decirte, dale a un muchacho algunos relés y un transformador de tren
eléctrico y puede conquistar el mundo!
Estaba el amable vecino que era un radioaficionado que me enseñó a usar un multímetro
(que rompí rápidamente). Estaba el dueño de la tienda de suministros de oficina que me
permitió entrar y "jugar" con su calculadora programable muy costosa. Estaba
la oficina de ventas de Digital Equipment Corporation que me permitió entrar y “jugar” con
su PDP8 y PDP10.
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 conocimiento. Me enseñó cómo leer volcados de memoria
y cómo 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 senior a
principios de los años setenta. En todos los demás lugares donde trabajé, era senior. No
había nadie que me ayudara a descubrir qué era la verdadera programación profesional.
No hubo un 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.
K NOCKS DUROS
Como les dije antes, de hecho, me despidieron de ese trabajo de automatización de fábrica
en 1976. Aunque técnicamente era muy competente, no había aprendido a prestar
atención al negocio ni a los objetivos comerciales. Fechas y plazos previstos
179
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 de inmediato o ser
despedido. Esta fue una importante llamada de atención para mí. Reevalué mi vida y mi
carrera y comencé a hacer algunos cambios significativos en mi comportamiento, algunos de
los cuales has estado leyendo en este libro. Pero era demasiado poco, 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 fuerza, 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 tomé algunas lecciones de vida poderosas para mi
próximo trabajo, que tuve durante quince años y que formó la verdadera base de mi carrera
actual.
Al final, sobreviví y prosperé. Pero tiene que haber una mejor manera. Hubiera sido mucho
mejor para mí si hubiera tenido un verdadero mentor, alguien que me enseñara los entresijos.
Alguien a quien podría haber observado mientras lo ayudaba con pequeñas tareas, y que
revisaría y guiaría mi trabajo inicial. Alguien que actúe como un modelo a seguir y me enseñe
valores y reflejos apropiados. Un sensei. Un maestro. Un mentor.
APRENDIZAJE
¿Qué hacen los médicos? ¿Cree que los hospitales contratan a médicos graduados y los
arrojan a los quirófanos para que les hagan una cirugía de corazón 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 que puedan 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
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 que se ha completado 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 de uno a tres años más de beca en la que el estudiante continúa
con una formación especializada y práctica supervisada.
Y luego son elegibles para tomar sus exámenes y obtener la certificación de la junta.
Esta descripción de la profesión médica fue algo idealizada y probablemente muy inexacta.
Pero el hecho es que cuando hay mucho en juego, no enviamos a los graduados a una habitación,
arrojamos 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 significativas. 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 se ha hecho con la idea de que los
programadores son programadores, y que una vez que te gradúas puedes codificar. De hecho, no es
raro que las empresas contraten a niños recién salidos de la escuela, los formen en "equipos" y les
pidan que construyan los sistemas más críticos. ¡Es una locura!
Los pintores no hacen esto. Los plomeros no. Los electricistas no. Demonios, ¡ni siquiera creo
que los cocineros de comida rápida se comporten de esta manera! Me parece que las empresas
que contratan a graduados en informática deberían invertir más en su capacitación de lo que
McDonalds invierte en sus servidores.
No nos engañemos con 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
facturas y acepta nuestros pagos. El software lava nuestra ropa y nos dice la hora. Pone
fotos en la televisión, envía nuestros mensajes de texto, hace nuestras 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 las minucias hasta las 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 introducir a los jóvenes graduados en las
filas del profesionalismo? ¿Qué pasos deben seguir? ¿Qué desafíos deben enfrentar?
¿Qué objetivos deben alcanzar? Trabajemos al revés.
Maestros
Estos son 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
diferentes tipos de sistemas, lenguajes y sistemas operativos.
Saben cómo liderar y coordinar múltiples equipos, son diseñadores y arquitectos competentes,
y pueden codificar círculos alrededor de todos los demás sin sudar. Se les han ofrecido
puestos directivos, pero los han rechazado, han huido después de aceptarlos o los han
integrado con 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".
jornaleros
Estos son 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 por lo general carecen de experiencia con muchos sistemas
diversos. Tienden a conocer un idioma, un sistema, una plataforma; pero están aprendiendo
más. Los niveles de experiencia varían ampliamente entre sus rangos, pero el promedio es
de unos cinco años. Al otro lado de ese promedio tenemos maestros florecientes; en
el lado cercano tenemos aprendices recientes.
182
APRENDIZAJE
Los jornaleros son supervisados por maestros u otros jornaleros de mayor rango.
A los jóvenes jornaleros rara vez se les permite la autonomía. Su trabajo es supervisado de
cerca. Su código es examinado. A medida que ganan en experiencia, crece la autonomía. La
supervisión se vuelve menos directa y más matizada. Eventualmente, pasa a la revisión por
pares.
Aprendices/pasantes
Los graduados comienzan sus carreras como aprendices. Los aprendices no tienen autonomía.
Están supervisados muy de cerca por los jornaleros. Al principio no aceptan ninguna tarea,
simplemente brindan asistencia a los jornaleros. Este debería ser un momento de programación en
pareja muy intensa. Es entonces cuando se aprenden y refuerzan las disciplinas. Aquí es
cuando se crea la base de los valores.
Los jornaleros son los maestros. Se aseguran de que los aprendices conozcan los principios de
diseño, los patrones de diseño, las disciplinas y los rituales. Los jornaleros 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 mediante una entrevista y revisando sus logros. Si los maestros están de acuerdo, el
aprendiz se convierte en oficial.
LA REALIDAD
Una vez más, todo esto es idealizado e hipotético. Sin embargo, si cambia los nombres y
entrecierra los ojos ante las palabras, se dará cuenta de que no es tan diferente de la forma en que
esperamos que funcionen las cosas ahora. Los graduados son supervisados por líderes de equipos
jóvenes, quienes son supervisados por líderes de proyectos, y así sucesivamente. 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 hay supervisión técnica en absoluto. Los programadores obtienen aumentos y eventuales
promociones porque, bueno, eso es exactamente lo que haces con los programadores.
La diferencia entre lo que hacemos hoy y mi programa idealizado de aprendizaje es el enfoque en la
enseñanza técnica, la capacitación, la supervisión y la revisión.
183
La diferencia es la noción misma de que los valores profesionales y la perspicacia técnica
deben enseñarse, nutrirse, nutrirse, mimarse y educarse. Lo que falta en nuestro enfoque
estéril actual es la responsabilidad de los ancianos de enseñar a los
joven.
ARTESANÍA
Así que ahora estamos en condiciones de definir esta palabra: artesanía. ¿Qué es?
Para entender, veamos la palabra artesano. Esta palabra trae a la mente habilidad y calidad.
Evoca experiencia y competencia. Un artesano es alguien que trabaja rápido, pero sin prisas,
que da presupuestos razonables y cumple con 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 que tienen 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 la artesanía se pasa de una persona a otra. Es enseñado por los ancianos 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 atrapas observando a otros y permitiendo que el meme se arraigue.
CONVENCER A LA GENTE
No puedes convencer a la gente de ser artesanos. 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 como 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 solo 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 se muestre tu destreza. Luego deja que el meme haga el resto del trabajo.
184
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ía y orientación a largo plazo.
185
HERRAMIENTAS A
En 1978, estaba trabajando en Teradyne en el sistema de prueba telefónica que describí anteriormente. El
sistema era de aproximadamente 80KSLOC del ensamblador M365. Guardamos el código fuente en
cintas.
Las cintas eran similares a los 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 solo 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 las longitudes de nuestras cintas con criterio.1
1. Estas cintas solo 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 hiciera una copia de seguridad y volviera a leer. Tenías que detener lo que estabas haciendo, enviar la cinta
de regreso al punto de carga y luego comenzar de nuevo. Esto sucedía dos o tres veces al día. Los errores de escritura
también eran muy comunes y la unidad no tenía forma de detectarlos. Así que siempre escribimos las cintas en pares y luego
revisamos los pares cuando terminamos. Si una de las cintas estaba mala, inmediatamente hacíamos una copia. Si ambos
estaban mal, lo cual era muy poco frecuente, comenzábamos toda la operación de nuevo. Así era la vida en los años 70.
187
APÉNDICE A HERRAMIENTAS
Lógicamente, las cintas se subdividían en archivos. Puede tener tantos archivos en una cinta como quepan.
Para encontrar un archivo, cargó la cinta y luego saltó hacia adelante un archivo a la vez hasta que
encontró 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 maestra de origen en una
unidad y una de 10' en blanco en otra. Saltaríamos a través del Maestro
hasta que llegamos al archivo que necesitábamos. Luego copiaríamos ese archivo en la cinta de borrador.
Luego “rebobinamos” ambas cintas y volvemos a colocar el Master en el estante.
Había una lista de directorio especial del Maestro en un tablón de anuncios en el laboratorio.
Una vez que habíamos hecho las copias de los archivos que necesitábamos editar, poníamos un pin de
color en la pizarra junto al nombre de ese archivo. ¡Así es como verificamos los archivos!
Editamos las cintas en una pantalla. Nuestro editor de texto, ED402, 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 era típicamente 50 líneas de código. No podía mirar
hacia adelante en la cinta para ver las páginas que venían, y no podía mirar hacia atrás en la cinta para ver
las páginas que había editado. Así que usamos listados.
De hecho, marcaríamos nuestros listados con todos los cambios que queríamos hacer y luego editaríamos
los archivos de acuerdo con nuestras marcas. ¡ Nadie escribió ni modificó el código en la terminal!
Eso fue suicidio.
Una vez que se realizaron los cambios en todos los archivos que necesitábamos editar, combinaríamos esos
archivos con el maestro para crear una cinta de trabajo. Esta es la cinta que usaríamos para ejecutar
nuestras compilaciones y pruebas.
Una vez que terminábamos de probar 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 Master y quitaríamos los pines del tablero. Si hubiera pines nuevos en el tablero,
quitaríamos los pines y le daríamos nuestra cinta de trabajo a la persona cuyos pines todavía estaban en
el tablero. Tendrían que hacer la fusión.
188
CONTROL DE CÓDIGO FUENTE
Éramos tres, y cada uno de nosotros tenía su propio color de pin, por lo que era fácil para
nosotros saber quién tenía qué archivos desprotegidos. Y dado que todos trabajábamos en el
mismo laboratorio y hablábamos entre nosotros todo el tiempo, mantuvimos el estado del tablero
en nuestras cabezas. Por lo general, la placa era redundante y, a menudo, no la 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 caja de herramientas
personal actual. No he realizado una encuesta completa de todas las demás herramientas que
existen, por lo que esto no debe considerarse una revisión exhaustiva. Esto es justo lo que uso.
Cuando se trata de control de código fuente, las herramientas de código abierto suelen ser su
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 para sí mismos
cuando necesitan algo que funcione.
Hay bastantes sistemas de control de versiones "empresariales" caros y comerciales
disponibles. Encuentro que estos no se venden tanto a desarrolladores como 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 N EMPRESA ” 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í, mis condolencias. Probablemente sea políticamente
inapropiado que andes diciéndoles a todos: "El tío Bob dice que no lo use". Sin embargo, hay 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 más o menos) y usar uno de los sistemas de código abierto
189
en medio de cada iteración. Esto mantiene a todos felices, no viola ninguna regla corporativa y
mantiene su productividad alta.
BLOQUEO PESIMISTA 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 actualización simultánea es serializarlos. Entonces, si estoy
editar un archivo, será mejor que no. De hecho, el sistema de alfileres de colores que usé a finales de
los 70 era una forma de bloqueo pesimista. Si había un pin en un archivo, no lo editó.
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 otros que
necesitan hacer cambios.
Nuestras herramientas han mejorado mucho en la combinación de archivos de origen que se han editado
al mismo tiempo. En realidad, es bastante sorprendente cuando lo piensas. Las herramientas analizan los
dos archivos diferentes y el ancestro 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 los archivos cuando
los revisamos. De hecho, no nos molestamos en verificar archivos individuales en absoluto. Simplemente
verificamos todo el sistema y editamos los archivos que necesitamos.
Cuando estamos listos para verificar nuestros cambios, realizamos una operación de "actualización".
Esto nos dice si alguien más verificó 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
cometemos el código fusionado.
Tendré mucho que decir sobre el papel que juegan 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 verificamos el código que no pasa todas las pruebas.
Nunca jamás.
190
CVS/SVN
El antiguo sistema de control de fuente en espera es CVS. Era bueno para su época, pero ha
crecido un poco para los proyectos de hoy. Aunque es muy bueno para manejar archivos y
directorios individuales, no es muy bueno para renombrar archivos o eliminar directorios. Y el
ático. . . . Bueno, cuanto menos se hable de eso, mejor.
Subversion, por otro lado, funciona muy bien. Le permite comprobar todo el sistema en una sola
operación. Puede actualizar, fusionar y confirmar fácilmente.
Siempre que no se meta en la bifurcación, los sistemas SVN son bastante simples 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 tenía que volver a la línea principal antes del final de la
iteración. De hecho, fui tan austero con la ramificación que rara vez se hizo en los proyectos
en los que estaba involucrado.
Si está utilizando SVN, sigo pensando que es una buena política. Sin embargo, hay algunas
herramientas nuevas que cambian el juego por completo. son los distribuidos
Sistemas de control de fuentes. git es mi favorito de los sistemas de control de código fuente
distribuido. Déjame contarte sobre eso.
git
Empecé a usar git a finales de 2008 y desde entonces ha cambiado todo sobre la forma en que
uso el control del código fuente. Comprender por qué esta herramienta es tan revolucionaria
está más allá del alcance de este libro. Pero comparar la Figura A1 con la Figura A2 debería
valer bastantes de las palabras que no voy a incluir aquí.
La Figura A1 muestra el desarrollo de algunas semanas en el proyecto FitNesse mientras
estaba controlado por SVN. Puedes ver el efecto de mi austera regla de no
ramificación. Simplemente no nos ramificamos. En cambio, hicimos actualizaciones, fusiones
y confirmaciones muy frecuentes en la línea principal.
191
Figura A1 FITNESS bajo subversión
La imagen de la Figura A2 muestra el desarrollo de algunas semanas en el mismo
proyecto usando git. Como puede ver, nos estamos ramificando y fusionando por
todas partes. Esto no fue porque relajé mi política de no ramificación; más bien, simplemente
192
Figura A2 FITNESS 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í
por capricho.
193
Observe también que no puede ver una línea principal verdadera. Eso es porque no hay uno.
Cuando usa 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.
Realizan checkin y checkout de esa copia local y luego la fusionan con otras según sea necesario.
Es cierto que mantengo un repositorio dorado especial en el que inserto 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 algo así como un doblador de mente al principio. Tienes que
acostumbrarte a cómo funciona. Pero te diré esto: git y herramientas como esta son el futuro del
control del código fuente.
IDE / EDITOR
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.
Algunos son inmensamente poderosos y otros han cambiado poco desde los años 70.
NOSOTROS
Uno pensaría que los días de usar vi como el principal editor de desarrollo habrían quedado
atrás. Hay herramientas hoy en día que superan con creces a vi, y a otros editores de texto sencillos
les gusta. Pero la verdad es que vi ha disfrutado de un resurgimiento significativo en popularidad
debido a su simplicidad, facilidad de uso, velocidad y flexibilidad. Es posible que Vi no sea
tan poderoso como Emacs o Eclipse, pero sigue siendo un editor rápido y poderoso.
Habiendo dicho eso, ya no soy un usuario avanzado de vi. Hubo un día en el que se me conocía como
un "dios" vi, pero esos días quedaron atrás. Uso vi de vez en cuando si necesito hacer una edición rápida
de un archivo de texto. Incluso lo he usado recientemente para hacer un cambio rápido a un archivo
fuente de Java en un entorno remoto. Pero la cantidad de codificación verdadera que he hecho en vi
en los últimos 10 años es muy pequeña.
194
IDE/EDITOR
E MACS
Emacs sigue siendo uno de los editores más poderosos que existen, y probablemente
seguirá siéndolo en las próximas décadas. El modelo de ceceo interno lo garantiza. Como
herramienta de edición de propósito general, nada más 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 del día eran juguetes ridículos que ningún desarrollador podía tomar en
serio. Pero a principios de la década de 2000 me presentaron IntelliJ, mi IDE de elección actual,
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 colocan a estos IDE por encima de herramientas como Emacs
son las formas extremadamente poderosas en las que lo ayudan a manipular el código. En
IntelliJ, por ejemplo, puede extraer una superclase de una clase con un solo comando.
Puede cambiar el nombre de las variables, extraer métodos y convertir la herencia en
composición, entre muchas otras características 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, piensa en las próximas transformaciones que debe realizar. En resumen, el
modelo de programación es notablemente diferente y altamente productivo.
195
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. Necesitan muchos recursos
informáticos para ejecutarse.
TEXTO E
TextMate es potente y ligero. No puede hacer las maravillosas manipulaciones que pueden hacer
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 es intuitivo.
Uso TextMate de vez en cuando, especialmente para el C++ ocasional. Yo usaría Emacs para un
gran proyecto de C++, pero estoy demasiado oxidado para molestarme con Emacs para las tareas
cortas de C++ que tengo.
SUEÑO DE SEGUIMIENTO
En este momento estoy usando Pivotal Tracker. Es un sistema elegante y simple de usar. Encaja
muy bien con el enfoque Agile/iterativo. Permite que todas las partes interesadas y los desarrolladores
se comuniquen rápidamente. Estoy muy contento con eso.
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 un wiki. Los wikis están bien para proyectos internos. Le permiten
configurar cualquier esquema que desee. No estás obligado a seguir un determinado proceso o una
estructura rígida. Son muy fáciles de entender y usar.
A veces, el mejor sistema de seguimiento de problemas de todos es un conjunto de tarjetas y un
tablón de anuncios. El tablón de anuncios se divide en columnas como "Por hacer", "En progreso" y
"Terminado". Los desarrolladores simplemente mueven las tarjetas de una columna a la siguiente
cuando corresponde. 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
CONSTRUCCIÓN CONTINUA
sistema manual, tendrá los conocimientos necesarios para seleccionar la herramienta adecuada. Y, de
hecho, la elección adecuada puede ser simplemente continuar usando el sistema manual.
B Y CUENTAS
Los equipos de desarrolladores ciertamente necesitan una lista de problemas en los 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 docenas 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 a clientes
usarlos pero no he tenido la oportunidad de trabajar con ellos directamente. No me opongo a
herramientas como esta, siempre que la cantidad de problemas sea pequeña 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 "vertederos de
problemas" (y, a menudo, también huelen a vertedero).
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 descarga, lo ejecuta, realiza algunas configuraciones
rápidas y sencillas, y ya está listo y funcionando. Muy lindo.
Mi filosofía sobre la compilación continua es simple: conéctelo a su sistema de control de código
fuente. Cada vez que alguien verifica el código, debe compilarse automáticamente y luego informar el
estado al equipo.
El equipo simplemente debe mantener la compilación funcionando en todo momento. Si la compilación
falla, debe ser un evento de "detener las prensas" y el equipo debe reunirse para resolver el problema
rápidamente. Bajo ninguna circunstancia se debe permitir que la falla persista por un día o más.
197
Para el proyecto FitNesse, hago que todos los desarrolladores ejecuten el script de compilación continua antes de
comprometerse. La compilación lleva menos de 5 minutos, por lo que no es onerosa.
Si hay problemas, los desarrolladores los resuelven antes de la confirmación. Por lo tanto, la compilación
automática rara vez tiene problemas. La fuente más común de fallas de 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 DE 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++.
Independientemente de la herramienta de prueba unitaria que elija, hay algunas características básicas que
todas deberían admitir.
1. Debe ser rápido y fácil ejecutar las pruebas. Si esto se hace a través
Los complementos IDE o las herramientas de línea de comandos simples son irrelevantes, siempre que los
desarrolladores puedan ejecutar esas pruebas a su antojo. El gesto para ejecutar las pruebas debe ser trivial.
Por ejemplo, ejecuto mis pruebas CppUTest escribiendo comandoM 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 se aprueban todas las pruebas. JUnit y 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 clara indicación visual de aprobación/rechazo. No importa si se trata de una
barra verde gráfica o un mensaje de consola que dice "Todas las pruebas pasan". El punto es que 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 la salida de dos archivos para saber si se aprobaron las pruebas,
entonces ha fallado en este punto.
3. La herramienta debe brindarle una clara indicación visual del progreso. No importa si se trata de un medidor
gráfico o de una cadena de puntos, siempre y cuando sepa que aún se está progresando y que las pruebas
no se han estancado ni abortado.
198
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 usen 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
ayudarlo 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 hacer que sea muy fácil escribir pruebas. JUnit hace esto proporcionando una
API conveniente para hacer afirmaciones. También utiliza atributos de reflexión y Java 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 conectar suites y crear listas de
pruebas propensas a errores.
HERRAMIENTAS DE PRUEBA DE COMPONENTES
Estas herramientas son para probar componentes a nivel de API. Su función es asegurarse de que el
comportamiento de un componente se especifique en un lenguaje que el personal comercial y de
control de calidad pueda entender. De hecho, el caso ideal es cuando los analistas comerciales y el control
de calidad pueden 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 los medios por los
cuales 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 FÍSICA
Mi herramienta de prueba de componentes favorita es FitNesse. Escribí gran parte de él, y soy el autor
principal. Así que es mi bebé.
FitNesse es un sistema basado en wiki que permite a los analistas comerciales y especialistas en control de
calidad escribir pruebas en un formato tabular muy simple. Estas tablas son similares a Parnas
199
tablas tanto en forma como en intención. Las pruebas se pueden ensamblar rápidamente en suites, y las suites se
pueden ejecutar a su antojo.
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 su calaña.
Slim es un sistema de prueba mucho más simple y portátil que es el favorito de 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 tabular similar
formato a 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 usando puentes apropiados.
• Green Pepper es una herramienta comercial que tiene varias similitudes con FitNesse. Se basa en la popular
wiki de confluencia.
• Cucumber es una herramienta de texto sin formato impulsada por un motor Ruby, pero capaz de
probando muchas plataformas diferentes. El lenguaje de Cucumber es el popular estilo Dado/Cuando/Entonces.
• JBehave es similar a Cucumber y es el padre lógico de Cucumber. Es
escrito en Java.
HERRAMIENTAS DE PRUEBA DE I NTEG R ACI ÓN
Las herramientas de prueba de componentes también se pueden usar 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
UML/MDA
Habiendo dicho eso, hay algunas pruebas que deben pasar por la interfaz de usuario, lo más
importante, las pruebas de la interfaz de usuario. Además, algunas pruebas de extremo a extremo deben
pasar por todo el sistema ensamblado, incluida la interfaz de usuario.
Las herramientas que más me gustan para las pruebas de interfaz de usuario son Selenium y Watir.
UML/MDA
A principios de los 90 tenía muchas esperanzas de que la industria de las herramientas CASE provocaría
un cambio radical en la forma en que trabajaban los desarrolladores de software. Mientras miraba hacia
adelante desde esos días embriagadores, pensé que ahora todo el mundo estaría codificando en diagramas
a un nivel más alto de abstracción y que el código textual sería cosa del pasado.
Chico, estaba equivocado. Este sueño no solo no se ha cumplido, sino que todos los intentos de avanzar en
esa dirección han fracasado abyectamente. No es que no haya herramientas y sistemas que demuestren el
potencial; es solo que esas herramientas simplemente no realizan realmente el sueño, y casi nadie parece
querer usarlas.
El sueño era que los desarrolladores de software pudieran dejar atrás los detalles del código textual
y los sistemas de autor en un lenguaje de diagramas de nivel superior. De hecho, según el sueño, es posible
que no necesitemos programadores en absoluto. Los arquitectos podían crear sistemas completos a
partir de diagramas UML. Los motores, vastos, geniales y poco comprensivos con la difícil
situación de los meros programadores, transformarían esos diagramas en código ejecutable. Tal era
el gran sueño de Model Driven Architecture (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. Éso es lo que hacemos. Especificamos el
comportamiento de los sistemas en el más mínimo detalle. Usamos lenguajes textuales para esto (código)
porque los lenguajes textuales son muy convenientes (considere el inglés, por ejemplo).
201
¿Qué tipo de detalles gestionamos?
¿Conoces la diferencia entre los dos caracteres \n y \r? El primero, \n, es un salto 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 un 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 giraría y se elevaría de modo que el carácter correcto quedara frente al papel, y luego
un pequeño martillo golpearía el cilindro contra el papel. Había una cinta de tinta entre el cilindro y el
papel, y la tinta se transfirió al papel con la forma del carácter.
El cabezal de impresión viajaba en un carro. Con cada carácter, el carro se movería un espacio a la
derecha, llevándose consigo el cabezal de impresión. Cuando el carro llegó al final de la línea de 72
caracteres, tuvo que devolver el carro 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. Al devolver el carro no subió el papel a la siguiente línea. Si
devolvió el carro y no envió un carácter de salto de línea (\n = 0 ́ 0A), la nueva línea se
imprimiría encima de la 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 podía tardar más de 100 ms en regresar. Si envió "\n\r",
entonces el siguiente carácter podría imprimirse cuando el carro regresó, creando así un carácter
manchado en el medio de la línea. Para estar seguros, a menudo rellenamos la secuencia de fin
de línea con uno o dos caracteres rubout3 (0 ́ FF).
2. http://en.wikipedia.org/wiki/ASR33_Teletipo
3. Los caracteres borrados fueron muy útiles para editar cintas de papel. Por convención, se ignoraron los caracteres borrados.
Su código, 0 ́ FF, significaba que cada agujero en esa fila de la cinta estaba perforado. Esto significaba que cualquier
personaje podía convertirse en un borrado si lo golpeaba demasiado. Por lo tanto, si cometió un error al escribir su
programa, puede retroceder y presionar borrar, luego continuar escribiendo.
202
UML/MDA
En los años 70, cuando los teletipos comenzaron a dejar de usarse, los sistemas operativos como
UNIX acortaron la secuencia de fin 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 de origen 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 o colocan doble espacio en el
texto porque los extremos de las líneas 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 clasificar los extremos de línea en
UML!
PARA QUIÉN _ _ , SIN CAMBIO _ _
La esperanza del movimiento MDA era que se pudiera eliminar una gran cantidad de detalles
mediante el uso de diagramas en lugar de código. Esa esperanza hasta ahora ha demostrado ser
desesperada. Resulta que simplemente no hay muchos detalles adicionales incrustados en el código
que puedan eliminarse con imágenes. Además, las imágenes contienen sus propios detalles
accidentales. Las imágenes tienen su propia gramática, sintaxis, reglas y restricciones. Entonces, al
final, la diferencia en los detalles es un lavado.
La esperanza de MDA era que los diagramas demostraran estar en un nivel más alto de abstracción
que el código, al igual que Java está en un nivel más alto que el ensamblador. Pero una vez más, esa
esperanza hasta ahora ha demostrado estar fuera de lugar. La diferencia en el nivel de abstracción
es mínima en el mejor de los casos.
Y, por último, digamos que un día alguien inventa un lenguaje de diagramas verdaderamente
útil. No serán arquitectos dibujando 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 manejan esos detalles.
203
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 salvajes. yo uso git
para control de código fuente, Tracker para gestión de problemas, Jenkins para construcció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 de 2.8Ghz, con pantalla mate de 17 pulgadas, 8GB de ram,
SSD de 512GB, con dos pantallas adicionales.
204
Í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
B
comunicación y, 97 integración continua y,
104–105 Callejones sin salida, 125–126
definición de, 94 rol Bossavit, Laurent, 83
del desarrollador en, 100–101 Juego de bolos, 83
trabajo extra y, 99 Ramificación, 191
GUI y, 103–105 Recuentos de errores, 197
negociación y, 101–102 agresión Objetivos empresariales, 154
pasiva y, 101–102 sincronización de, 99–
100 pruebas unitarias C
y, 102–103 escritores de, 99– cafeína, 122
100 certeza, 74
Roles adversarios, 20–23 Control
Estimación de afinidad, 140–141 de código, 189–194
Ambigüedad, en requisitos, 92–94 propiedad, 157
disculpas, 6 3 AM, 53–54
Aprendices, 183 preocupación, 54–55
Aprendizaje, 180–184 Codificación Dojo, 83–87
Argumentos, en reuniones, 120–121 Colaboración, 14, 151–160
Arrogancia, 16 Propiedad colectiva, 157–158
205
Í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 guiado por pruebas (TDD)
falta de, 42–43 Desacuerdos, en reuniones, 120–121
presión y, 146 Disciplina
Comunicación compromiso y, 47–50 crisis,
pruebas de aceptación y, 147
97 presión y, 148 de Desvinculació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 a función, 5–8 a
Construcción continua, 197–198 estructura, 8–10
Integración continua, 104–105 Conducción, 64
Aprendizaje continuo, 13
Control, compromiso y, 44
E Eclipse, 195–196
Coraje, 75–76
Emacs, 195
Artesanía, 184
Identificación
Entrada creativa, 59–60, 123
de empleador(es) con, 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
dirigido por pruebas, 72
definición de, 132–133
D ley de los grandes números y, 141
plazos nominal, 136
entrega falsa y, 67 optimista, 135–136
esperando y, 65 PERT y, 135–138
horas extras y, 66 pesimista, 136
corriendo y, 65–66 probabilidad y, 133 de
Depuración, 60–63 tareas, 138–141
Tasa de inyección de defectos, 75 trivariado, 141
206
Í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 prueba, 111–112
Fracaso, grados de, 174 herramientas para, 200–201
parto falso, 67 IntelJ, 195–196
Fitnessness, 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
JBehave, 200
GRAMO
Oficiales, 182–183
Gaillot, Emmanuel, 83
Equipo gelificado, 162164 k
Git, 191–194 Palabra, 84–85
Goles, 2023, 118 Conocimiento
Interfaces gráficas de usuario (GUI), 103– del dominio, 15
105 mínimo, 12
Pimiento Verde, 200 ética de trabajo y, 11–13
Grenning, James, 139
L
GUI, 103–105
Retraso, 65–67
H
Ley de los grandes números, 141.
Golpes duros, 179–180 Aprendizaje, ética de trabajo y, 13
Ayuda, 67–70 “Vamos”, 42
dar, 68 Lindström, Lowell, 140
tutoría y, 69–70 presión y, Bloqueo, 190
148–149 recibir, 68–69
METRO
“Esperanza”, 42 Pruebas exploratorias manuales, en estrategia
de prueba, 112–113
Esperando, plazos y, 65
Maestros, 182
Humildad, 16
MDA, 201–203
I Agenda de
IDE/editor, 194 reuniones en, 118
Identificación, con empleador/cliente, Argumentos y desacuerdos en, 120–121
15
Compromisos implícitos, 134–135 declinando, 117
207
ÍNDICE
Reuniones (continuación) PERT (Programa de Evaluación y
demostración, Técnica de revisión), 135–138
120 objetivos Estimación pesimista, 136
en, 118 planificación de Bloqueo pesimista, 190
iteraciones, 119 iteración Actividad física, 123
retrospectiva, Planificación de póquer, 139–140
120 salida, 118 Práctica
standup, 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
Desordenes, 126–127, 146 de respuesta y, 82–83 ética laboral
Métodos, 12 y, 13–14
Arquitectura dirigida por modelos (MDA), Precisión, prematura, en
201–203 requisitos, 91–92
Enfoque muscular, 123 Preparación, 52–55
música, 57 Presión
evitar, 145–147 limpieza
norte
y, 146 compromisos y,
“Necesidad”, 42
146 comunicación y, 148
Negociación, pruebas de aceptación y, 101– manipulación, 147–149 ayuda
102
y, 148–149 líos y, 146
Estimación nominal, 136
pánico y, 147–148
no profesional, 2
inversión de
O prioridad, 125 probabilidad,
133 profesionalidad, 2
código abierto, 87
programadores
Estimación optimista, 135–136
empleadores vs., 153–
Bloqueo optimista, 190
156 personas vs.,
Resultados, lo mejor posible, 20–23
horas extras, 66 153–158 programadores vs.,
código propio, 157 157 Propuesta, proyecto,
31–32
Propiedad, colectiva, 157–158
PAG
Ritmo, 63–64 q
Emparejamiento, 58, 148–149, Garantía de calidad (QA)
158 Pánico, 147– automatizada, 8
148 Pasión, como detectores de
154 Agresión pasiva, 28–30, 101–102 errores, 6 como caracterizadores,
Personas, programadores vs., 153–158 108–109 ideal de, como no encontrar
Problemas personales, 54–55 problemas, 108–109
208
Í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
gelificado, 162–164
R
gestión de, 164 agresión
Randori, 86–87 pasiva y, 28–30 preservación, 163
La lectura, como insumo creativo, 59 proyecto iniciado,
Recarga, 122–123 163–164 dilema del propietario
Reputación, 5 del proyecto con,
Comunicación de 164–165
requisitos de, 89–94 ansiedad intentando y, 26–28
de estimación y, 92 ambigüedad velocidad de, 164
tardía en, 92–94 precisión Beneficios del desarrollo impulsado por
prematura en, 91–92 incertidumbre y, pruebas (TDD) de, 74–
91–92 77 certeza y, 74
Responsabilidad, 2–5 coraje y, 75–76 tiempo
disculpas y, 6 de ciclo en, 72 debut
enfoque de “no hacer daño” y, 5–10 función de, 71–72 tasa de
y, 5–8 estructura y, 8– inyección de defectos y, 75
10 ética de trabajo y, 10– definición de, 7–8
16 diseño y, 76– 77
RobotFX, 200 documentación y, 76
Roles, contradictorio, 20–23 interrupciones y, 58 tres
Corriendo, 34–35, 65–66 leyes de, 73–74 lo que
no es, 77–78
S Prueba
Santana, Carlos, 83 de aceptación
“Debería”, 42 automatizada, 97–99
ducha, 64 comunicación y, 97 integración
Sencillez, 34 continua y, 104–105 definición de,
dormir, 122 94 rol del
Control de código fuente, 189–194 desarrollador en,
Apuestas, 23–24 100–101 trabajo extra y, 99
Reuniones de pie, 119
Estructura GUI y, 103–105
en el enfoque de “no hacer daño”, 8–10 negociación y, 101–102 agresión
flexibilidad y, 9 pasiva y, 101–102 sincronización de, 99–
importancia de, 8 100 pruebas unitarias
SVN, 191–194 y, 102–103 escritores de, 99–
Pruebas del sistema, en estrategia de prueba, 112. 100
209
ÍNDICE
Pruebas (continuación) Estimaciones trivariadas, 141
pirámide de automatización, 109–113 Tiempo de respuesta, práctica y,
componente 82–83
de la estrategia de pruebas, 110–
EN
111 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 exploración 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 EN
estrategia de prueba, 110
nosotros, 194
herramientas para, 198–199
Mate de texto, 196 EN
Tomás, David, 84
Alejándose, 64
Código de las 3 a. m., 53–54 Juego, 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 colaboración y, 14
de, 116 enfoque y, aprendizaje continuo y, 13
121–123 reuniones y,
conocimiento y, 11–13 tutoría
116–121 líos y, 126–127 y, 14–15 práctica y, 13–14
inversión de prioridad y,
125 recarga y, 122–123 técnica de Código de preocupaciones, 54–55
“tomates” para, 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

Programador Limpio

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Programador Limpio

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

Machine Translated by Google

PANTANOS , B Y , MPS SWA , Y OTROS DESORDENES

Tarea Optimista Nominal Pesimista metro

Alfa 1 3 12 4.2 1.8

También podría gustarte