El programador pragmático. Edición especial E-Book

David Thomas

• Herausgeber: ANAYA MULTIMEDIA
• Kategorie: Wissenschaft und neue Technologien
• Serie: TÍTULOS ESPECIALES
• Sprache: Spanisch

Seitenzahl: 542

Veröffentlichungsjahr: 2022

Beschreibung

El programador pragmático es uno de esos raros casos de libros técnicos que se leen, se releen y se vuelven a leer durante años. Tanto si es nuevo en el campo como si es un profesional experimentado, acabará encontrando ideas nuevas cada vez. Dave Thomas y Andy Hunt escribieron la primera edición de este libro tan influyente en 1999 para ayudar a sus clientes a crear software mejor y a redescubrir el placer de escribir código. Estas lecciones han ayudado a una generación de programadores a examinar la propia esencia del desarrollo de software, independientemente de cualquier lenguaje, framework o metodología en particular, y la filosofía pragmática ha sido el germen de cientos de libros, screencasts y audiolibros, además de miles de carreras e historias de éxito. Ahora, más de veinte años después, esta nueva edición reexamina lo que significa ser un programador moderno. Los temas abarcan desde la responsabilidad personal y el desarrollo profesional hasta técnicas de arquitectura para mantener su código flexible y fácil de adaptar y reutilizar. Escrito como una serie de secciones independientes y repleto de anécdotas clásicas y nuevas, ejemplos razonados y analogías interesantes, este libro ilustra los mejores enfoques y los mayores obstáculos de muchos aspectos diferentes del desarrollo de software. No importa si es un novato, un programador con experiencia o un director responsable de proyectos de software, utilice estas lecciones en su día a día y pronto observará mejorías en su productividad personal, exactitud y satisfacción laboral. Aprenderá las habilidades y desarrollará los hábitos y actitudes que forman los cimientos del éxito a largo plazo en su carrera.

Leseprobe

Para Juliet y Ellie,Zachary y Elizabeth,Henry y Stuart

Agradecimientos de la segunda edición

Hemos disfrutado de literalmente miles de conversaciones sobre programación en los últimos 20 años, hemos conocido a muchas personas en conferencias, cursos y, a veces, incluso en el avión. Cada una de ellas ha aportado algo a nuestra comprensión del proceso de desarrollo y ha contribuido a las actualizaciones de esta edición. Gracias a todas esas personas (y seguid avisándonos cuando nos equivoquemos).

Gracias a los participantes en el proceso beta del libro. Vuestras preguntas y comentarios nos han ayudado a explicar las cosas mejor.

Antes de pasar a la fase beta, compartimos el libro con algunos colegas para recibir sus opiniones. Gracias a VM (Vicky) Brasseur, Jeff Langr y Kim Shrier por sus comentarios detallados y a José Valim y Nick Cuthbert por las revisiones técnicas.

Gracias a Ron Jeffries por dejarnos utilizar el ejemplo del sudoku.

Eterna gratitud al personal de Pearson que accedió a dejar que creásemos este libro a nuestra manera.

Un agradecimiento especial a la indispensable Janet Furlow, que domina todo lo que toca y nos mantiene a raya.

Y, por último, una mención a todos los programadores pragmáticos del mundo que han estado haciendo que la programación sea mejor para todo el mundo durante los últimos veinte años. Por otros veinte más.

Sobre los autores

David Thomas y Andrew Hunt son dos de las voces más conocidas y prestigiosas en la comunidad de desarrollo de software. Ponentes y conferenciantes por todo el mundo. Juntos, fundaron la colección Pragmatic Bookshelf, que publica libros de vanguardia galardonados para desarrolladores de software. También fueron dos de los firmantes y autores del Manifiesto Ágil, considerado la biblia de las metodologías ágiles y del desarrollo de software.

Dave actualmente enseña en la universidad, tornea madera y juega con nuevas tecnologías y paradigmas.

Andy escribe ciencia ficción, es un músico activo y le encanta jugar con la tecnología.

Índice

Agradecimientos de la segunda edición

Sobre los autores

Prólogo

Prefacio de la segunda edición

Cómo se organiza el libro

¿Qué hay en un nombre?

Código fuente y otros recursos

Del prefacio de la primera edición

¿Quién debería leer este libro?

¿Qué hace a un programador pragmático?

Pragmatistas individuales, equipos grandes

Es un proceso continuo

1. Una filosofía pragmática

1 Es su vida

Las secciones relacionadas incluyen

2 El gato se comió mi código fuente

Confianza del equipo

Asuma la responsabilidad

Las secciones relacionadas incluyen

Retos

3 Entropía del software

Primero, no haga daño

Las secciones relacionadas incluyen

Retos

4 Sopa de piedras y ranas hervidas

El lado de los aldeanos

Las secciones relacionadas incluyen

Retos

5 Software lo bastante bueno

Implique a sus usuarios en la compensación

Saber cuándo parar

Las secciones relacionadas incluyen

Retos

6 Su cartera de conocimientos

Su cartera de conocimientos

La creación de su cartera

Objetivos

Oportunidades para el aprendizaje

Pensamiento crítico

Las secciones relacionadas incluyen

Retos

7 ¡Comuníquese!

Conozca a su público

Sepa lo que quiere decir

Elija el momento

Elija un estilo

Dele un buen aspecto

Involucre a su público

Sepa escuchar

Responda a la gente

Documentación

Resumen

Las secciones relacionadas incluyen

Retos

2. Un enfoque pragmático

8 La esencia del buen diseño

ETC es un valor, no una regla

Las secciones relacionadas incluyen

Retos

9 DRY: los males de la duplicación

DRY es más que código

Duplicación en el código

Duplicación en la documentación

Duplicación relativa a la representación

Las secciones relacionadas incluyen

10 Ortogonalidad

¿Qué es la ortogonalidad?

Beneficios de la ortogonalidad

Diseño

Herramientas y bibliotecas

Creación de código

Pruebas

Documentación

Vivir con ortogonalidad

Las secciones relacionadas incluyen

Retos

Ejercicios

11 Reversibilidad

Reversibilidad

Arquitectura flexible

Las secciones relacionadas incluyen

Retos

12 Balas trazadoras

Código que brilla en la oscuridad

Las balas trazadoras no siempre dan en el blanco

Código trazador versus creación de prototipos

Las secciones relacionadas incluyen

13 Prototipos y notas en post-its

Cosas para las que puede crear prototipos

Cómo utilizar prototipos

Crear prototipos de arquitectura

Cómo no utilizar prototipos

Las secciones relacionadas incluyen

Ejercicios

14 Lenguajes de dominio

Algunos lenguajes de dominio del mundo real

Características de los lenguajes de dominio

Compensaciones entre lenguajes internos y externos

Un lenguaje de dominio interno de bajo coste

Las secciones relacionadas incluyen

Retos

Ejercicios

15 Estimaciones

¿Cuánta exactitud es suficiente exactitud?

¿De dónde vienen las estimaciones?

Estimar el calendario de los proyectos

Qué decir cuando le pidan una estimación

Las secciones relacionadas incluyen

Retos

Ejercicios

3. Las herramientas básicas

16 El poder del texto simple

¿Qué es el texto simple?

El poder del texto

Mínimo común denominador

Las secciones relacionadas incluyen

Retos

17 Jugar con el intérprete de comandos

Su propio intérprete de comandos

Las secciones relacionadas incluyen

Retos

18 Edición potente

¿Qué significa “fluidez”?

Avanzar hacia la fluidez

Las secciones relacionadas incluyen

Retos

19 Control de versiones

Empieza en la fuente

Ramificaciones

Control de versiones como centro de proyectos

Las secciones relacionadas incluyen

Retos

20 Depuración

Psicología de la depuración

Mentalidad de la depuración

Por dónde empezar

Estrategias de depuración

Programador en tierras extrañas

La búsqueda binaria

El elemento sorpresa

Lista de comprobación de depuración

Las secciones relacionadas incluyen

Retos

21 Manipulación de texto

Las secciones relacionadas incluyen

Ejercicios

22 Cuadernos de bitácora de ingeniería

Las secciones relacionadas incluyen

4. Paranoia pragmática

23 Diseño por contrato

DBC

Implementar DBC

DBC y fallo total temprano

Invariantes semánticas

Contratos dinámicos y agentes

Las secciones relacionadas incluyen

Retos

Ejercicios

24 Los programas muertos no mienten

La captura y liberación es para la pesca

Fallo total, no basura

Las secciones relacionadas incluyen

25 Programación asertiva

Aserciones y efectos secundarios

Deje las aserciones activadas

Las secciones relacionadas incluyen

26 Cómo equilibrar los recursos

Anidar asignaciones

Objetos y excepciones

Equilibrio y excepciones

Cuando no podemos equilibrar los recursos

Comprobar el equilibrio

Las secciones relacionadas incluyen

Retos

Ejercicios

27 No vaya más rápido que sus faros

Cisnes negros

Las secciones relacionadas incluyen

5. O se adapta o se rompe

28 Desacoplamiento

Train Wrecks

Los males de la globalización

La herencia añade acoplamiento

De nuevo, todo tiene que ver con el cambio

Las secciones relacionadas incluyen

29 Malabares con el mundo real

Eventos

Máquinas de estados finitos

El patrón Observer

Publish/Subscribe

Programación reactiva, streams y eventos

Los eventos son ubicuos

Las secciones relacionadas incluyen

Ejercicios

30 Transformar la programación

Encontrar transformaciones

¿Por qué es esto tan genial?

¿Qué pasa con el manejo de errores?

Las transformaciones transforman la programación

Las secciones relacionadas incluyen

Ejercicio

31 Impuesto sobre la herencia

Algo de historia

Problema de usar la herencia al compartir código

Las alternativas son mejores

La herencia rara vez es la respuesta

Las secciones relacionadas incluyen

Retos

32 Configuración

Configuración estática

Configuración como servicio

No escriba código dodo

Las secciones relacionadas incluyen

6. Concurrencia

Todo es concurrente

33 Romper el acoplamiento temporal

Buscar la concurrencia

Oportunidades para la concurrencia

Oportunidades para el paralelismo

Identificar oportunidades es la parte fácil

Las secciones relacionadas incluyen

Retos

34 Estado compartido es estado incorrecto

Actualizaciones no atómicas

Transacciones de recursos múltiples

Actualizaciones no transaccionales

Otros tipos de accesos exclusivos

Doctor, me hago daño...

Las secciones relacionadas incluyen

35 Actores y procesos

Los actores solo pueden ser concurrentes

Un actor simple

Sin concurrencia explícita

Erlang prepara el escenario

Las secciones relacionadas incluyen

Retos

36 Pizarras

Una pizarra en acción

Los sistemas de mensajería pueden ser como pizarras

Pero no es tan simple...

Las secciones relacionadas incluyen

Ejercicios

Retos

7. Mientras escribe código

37 Escuche a su cerebro reptiliano

Miedo a la página en blanco

Luche contra sí mismo

Cómo hablar lagarto

¡Hora de jugar!

No solo su código

No solo código

Las secciones relacionadas incluyen

Retos

38 Programar por casualidad

Cómo programar por casualidad

Cómo programar de forma deliberada

Las secciones relacionadas incluyen

Ejercicios

39 Velocidad de los algoritmos

¿Qué queremos decir con estimar algoritmos?

Notación Big O

Estimación con sentido común

Velocidad de los algoritmos en la práctica

Las secciones relacionadas incluyen

Retos

Ejercicios

40 Refactorización

¿Cuándo deberíamos refactorizar?

¿Cómo refactorizamos?

Las secciones relacionadas incluyen

41 Probar para escribir código

Pensar en las pruebas

Escritura de código guiada por pruebas

TDD: necesita saber adónde va

De vuelta al código

Pruebas unitarias

Pruebas en relación con el contrato

Pruebas ad hoc

Construya una ventana de pruebas

Una cultura de pruebas

Las secciones relacionadas incluyen

42 Pruebas basadas en propiedades

Contratos, invariantes y propiedades

Generación de datos de prueba

Encontrar asunciones malas

Las pruebas basadas en propiedades nos sorprenden a menudo

Las pruebas basadas en propiedades también ayudan al diseño

Las secciones relacionadas incluyen

Ejercicios

Retos

43 Tenga cuidado ahí fuera

El otro 90 %

Principios de seguridad básicos

Sentido común vs. criptografía

Las secciones relacionadas incluyen

44 Poner nombre a las cosas

Respetar la cultura

Coherencia

Cambiar nombres es aún más difícil

Las secciones relacionadas incluyen

Retos

8. Antes del proyecto

45 El pozo de los requisitos

El mito de los requisitos

Programar como terapia

Los requisitos son un proceso

Póngase en la piel del cliente

Requisitos frente a política

Requisitos frente a realidad

Documentar requisitos

Sobreespecificación

Solo una cosita más...

Mantenga un glosario

Las secciones relacionadas incluyen

Ejercicios

Retos

46 Resolver rompecabezas imposibles

Grados de libertad

¡No se estorbe a sí mismo!

La suerte favorece a la mente preparada

Las secciones relacionadas incluyen

Retos

47 Trabajar juntos

Programación en pareja

Programación en grupo

¿Qué debería hacer?

48 La esencia de la agilidad

Nunca puede haber un proceso ágil

Entonces, ¿qué hacemos?

Y esto dirige el diseño

Las secciones relacionadas incluyen

Retos

9. Proyectos pragmáticos

49 Equipos pragmáticos

Sin ventanas rotas

Ranas hervidas

Planifique su cartera de conocimientos

Comunique la presencia del equipo

No se repitan

Balas trazadoras en equipos

Automatización

Saber cuándo dejar de añadir pintura

Las secciones relacionadas incluyen

Retos

50 Los cocos no sirven

El contexto importa

La talla única no le queda bien a nadie

El objetivo real

Las secciones relacionadas incluyen

51 Kit pragmático básico

Dirija con el control de versiones

Pruebas despiadadas y continuas

Reforzar la red

Automatización completa

Las secciones relacionadas incluyen

Retos

52 Deleite a sus usuarios

Las secciones relacionadas incluyen

53 Orgullo y prejuicio

Posfacio

La brújula moral

Imagine el futuro que quiere

Bibliografía

Posibles respuestas a los ejercicios

Créditos

Prólogo

Recuerdo cuando Dave y Andy tuitearon por primera vez acerca de la nueva edición de este libro. Fue una gran noticia. Vi como la comunidad de creadores de código respondía con entusiasmo. Mi página de inicio bullía con expectación. Después de más de veinte años, El programador pragmático es tan relevante hoy como lo era entonces.

Es muy significativo que un libro con tanta historia generase semejante reacción. Tuve el privilegio de leer una copia inédita para escribir este prólogo, y entendí por qué había causado tanto alboroto. Aunque se trata de un libro técnico, no es justo llamarlo así. Los libros técnicos a menudo intimidan. Están repletos de palabras imponentes, términos confusos, ejemplos enrevesados que, sin querer, hacen que te sientas estúpido. Cuanto más experimentado es el autor, más fácil es olvidar cómo es aprender conceptos nuevos, ser un principiante.

A pesar de sus décadas de experiencia en programación, Dave y Andy han superado el difícil reto de escribir con el entusiasmo de personas que acaban de aprender estas lecciones. No nos hablan con condescendencia. No asumen que somos expertos. Ni siquiera dan por hecho que hemos leído la primera edición. Nos aceptan como somos, programadores que quieren ser mejores, sin más. Dedican las páginas de este libro a ayudarnos a conseguirlo, paso factible a paso factible.

Para ser justos, ya han hecho esto antes. La publicación original estaba llena de ejemplos tangibles, ideas nuevas y consejos prácticos para ejercitar nuestros músculos y desarrollar nuestro cerebro para la escritura de código que todavía se aplican hoy en día. Pero esta actualización realiza dos mejoras en el libro.

La primera es la más evidente: elimina algunas de las referencias antiguas y los ejemplos desfasados y los sustituye por contenido reciente y moderno. No encontrará ejemplos de ciclos invariantes ni build machines. Dave y Andy han recogido su contenido potente y se han asegurado de que las lecciones todavía se entienden, sin las distracciones de los ejemplos antiguos. Desempolvan viejas ideas, como DRY (don’t repeat yourself, no te repitas) y le dan una mano de pintura fresca, haciendo que brillen.

La segunda, sin embargo, es la que hace este lanzamiento realmente emocionante. Después de escribir la primera edición, tuvieron la oportunidad de reflexionar sobre lo que estaban intentando decir, con lo que querían que se quedasen los lectores y cómo estaba percibiéndose. Recibieron feedback sobre esas lecciones. Vieron qué calaba, qué había que perfeccionar, qué se entendía mal. En los veinte años en los que este libro ha pasado por las manos y los corazones de programadores de todo el mundo, Dave y Andy han estudiado esta respuesta y han formulado nuevas ideas, nuevos conceptos.

Han aprendido la importancia de la capacidad de acción y han reconocido que podría decirse que los desarrolladores tienen más capacidad de acción que muchos otros profesionales. Empiezan este libro con un mensaje sencillo, pero profundo: “Es su vida”. Nos recuerda nuestro propio poder en nuestra base de código, en nuestros empleos, en nuestras carreras. Marca el tono del resto del libro; es más que otro libro técnico lleno de ejemplos de código.

Lo que hace que destaque de verdad en las estanterías de los libros técnicos es que entiende lo que significa ser programadores. La programación trata sobre intentar hacer el futuro menos doloroso, sobre hacer cosas mal y ser capaz de recuperarse, sobre crear buenos hábitos, sobre entender tu conjunto de herramientas. La creación de código es solo una parte del mundo de los programadores, y este libro explora ese mundo.

Paso mucho tiempo pensando en el viaje de la creación de código. Yo no crecí creando código. No lo estudié en la universidad. No me pasé la adolescencia jugueteando con la tecnología. Entré en el mundo del código a los veintitantos y tuve que aprender lo que significaba ser programadora. Esta comunidad es muy diferente de otras de las que he formado parte. Hay una dedicación única al aprendizaje y la practicidad es al mismo tiempo refrescante e intimidante.

Para mí, fue como entrar en un mundo nuevo. O, al menos, una nueva ciudad. Tuve que conocer a los vecinos, elegir un supermercado, encontrar las mejores cafeterías. Me llevó un tiempo familiarizarme con el terreno, encontrar las rutas más eficientes, evitar las calles con más tráfico, saber cuándo era probable que hubiese atascos. El clima era diferente, necesitaba un fondo de armario nuevo.

Las primeras semanas, incluso los primeros meses, en una ciudad nueva, pueden ser aterradores. ¿No sería maravilloso tener un vecino amable y bien informado que lleve un tiempo viviendo allí? ¿Alguien que pueda enseñarte el lugar, decirte cuáles son esas cafeterías? ¿Una persona que lleve ahí el tiempo suficiente para conocer la cultura, entender el ritmo de la ciudad, de forma que no solo ayude a que te sientas en casa, sino también a que te conviertas en un miembro que contribuye a la comunidad? Dave y Andy son esos vecinos.

Como recién llegada relativa, es fácil sentirse desbordada, no por el acto de programar, sino por el proceso de convertirse en programadora. Es necesario que se produzca un cambio de mentalidad completo, un cambio en los hábitos, los comportamientos y las expectativas. El proceso de conversión en mejores programadores no ocurre solo porque sepamos escribir código; debe haber también intención y práctica deliberada. Este libro es una guía para convertirse en programadores mejores de manera eficiente.

Pero no se equivoque: no le dice cómo debería ser la programación. No es filosófico ni sentencioso. Dice, de manera llana y simple, qué es un programador pragmático, cómo trabaja, cómo enfoca el código. Dejan a su elección si quiere ser uno. Si siente que eso no le va, no le guardan rencor. Pero, si decide que le interesa, son los vecinos amables que están ahí para mostrarle el camino.

—Saron Yitbarek.

Fundadora y directora ejecutiva de CodeNewbie.

Presentadora de Command Line Heroes.

Prefacio de la segunda edición

En los años noventa, trabajábamos con empresas cuyos proyectos estaban teniendo problemas. Nos dimos cuenta de que estábamos diciendo lo mismo todo el tiempo: quizá debería probar eso antes de enviarlo; ¿por qué el código solo se construye en el ordenador de Mary? ¿Por qué nadie ha preguntado a los usuarios?

Para ahorrar tiempo con los nuevos clientes, empezamos a tomar notas. Y esas notas se convirtieron en El programador pragmático. Para nuestra sorpresa, pareció calar hondo, y ha seguido siendo popular durante los últimos 20 años.

Pero más de dos décadas son varias vidas cuando hablamos de software. Traiga a un desarrollador de 1999 y métalo en un equipo actual, y verá los apuros que pasa en este mundo nuevo y extraño. Pero el mundo de los noventa es igual de raro para los desarrolladores de hoy. Las referencias de este libro a cosas como CORBA, herramientas CASE y bucles indexados eran como mucho pintorescas y, probablemente, confusas.

Al mismo tiempo, 20 años no han afectado para nada al sentido común. La tecnología ha cambiado, pero las personas no. Las prácticas y los enfoques que eran buena idea entonces siguen siéndolo ahora. Esos aspectos del libro han envejecido bien.

Así pues, cuando llegó la hora de crear esta edición por el 20º aniversario, tuvimos que tomar una decisión. Podíamos repasar y actualizar las tecnologías a las que hacemos referencia y santas pascuas, o podíamos reexaminar los supuestos que había detrás de las prácticas que recomendábamos a la luz de las dos décadas de experiencia adicionales.

Al final, hicimos las dos cosas.

Como resultado, este libro es una especie de paradoja del barco de Teseo.1 Alrededor de un tercio de los temas del libro son completamente nuevos. Del resto, la mayoría se ha reescrito, de manera parcial o total. Nuestra intención era hacer que las cosas fuesen más claras, más relevantes y, de alguna manera, atemporales.

Hemos tomado decisiones difíciles. Hemos desechado el apéndice “Recursos”, porque sería imposible mantenerlo actualizado y porque es más fácil que busque lo que quiera. Hemos reorganizado y reescrito temas relacionados con la concurrencia, dada la abundancia actual de hardware paralelo y la escasez de buenas maneras de tratar con él. Hemos añadido contenido que refleja actitudes y entornos cambiantes, desde el movimiento del desarrollo ágil que ayudamos a iniciar hasta la aceptación cada vez mayor de modismos en la programación funcional y la necesidad creciente de tener en cuenta la privacidad y la seguridad. Sin embargo, resulta interesante que hubiese bastante menos discusión entre nosotros sobre el contenido de esta edición que cuando escribimos la primera. Los dos sentíamos que todo aquello que era importante era más fácil de identificar. En cualquier caso, este libro es el resultado. Por favor, disfrútelo. Puede adoptar, quizá, algunas prácticas nuevas. Tal vez decida que algunas cosas de las que sugerimos están mal. Involúcrese en su oficio. Denos su opinión.

Pero, sobre todo, recuerde divertirse con esto.

Cómo se organiza el libro

Este libro está escrito como una colección de temas cortos. Cada tema es independiente y gira en torno a una idea central específica. Encontrará numerosas referencias cruzadas, que le ayudarán a situar cada tema dentro de un contexto. Puede leer los temas en cualquier orden, no es necesario que los lea tal y como aparecen.

De manera ocasional, se encontrará con un cuadro titulado Truco nn (como Truco 1, “Preocúpese por su oficio”). Además de enfatizar puntos del texto, creemos que los trucos tienen vida propia, influyen en nuestra vida a diario.

Hemos incluido ejercicios y retos donde es pertinente. Los ejercicios suelen tener respuestas relativamente directas, mientras que los retos son más abiertos. Para que se haga una idea de nuestra forma de pensar, hemos incluido nuestras respuestas a los ejercicios al final del libro, pero muy pocos tienen una única solución correcta. Los retos pueden servir como base para debates o para un ensayo acerca de los cursos de programación avanzados. También hay una breve bibliografía que incluye los libros y artículos a los que hacemos referencias explícitas.

¿Qué hay en un nombre?

—Cuando yo uso una palabra —insistió Humpty Dumpty con un tono de voz más bien desdeñoso— quiere decir lo que yo quiero que diga..., ni más ni menos.

—Lewis Carroll, A través del espejo.

Esparcidos por el libro encontrará varios ejemplos de jerga, bien palabras perfectamente correctas en nuestro idioma que se han corrompido para que signifiquen algo técnico, bien palabras inventadas horribles a las que han asignado significados algunos científicos de la computación que se la tienen jurada a la lengua. La primera vez que usemos alguna de estas palabras de jerga, intentaremos definirla o, al menos, dar alguna pista sobre su significado. Sin embargo, estamos seguros de que algunas han pasado inadvertidas y otras, como “objeto” y “base de datos relacional”, tienen un uso bastante común que hace que añadir una definición sea aburrido. Si se encuentra con un término que no ha visto antes, por favor, no lo ignore sin más. Tómese un tiempo para buscarlo, quizá en la web o tal vez en un libro de texto de ciencias de la computación. Y, si tiene ocasión, escríbanos un correo electrónico y quéjese para que añadamos una definición en la siguiente edición.

Dicho esto, hemos decidido vengarnos de los científicos de la computación. A veces, hay palabras de jerga perfectamente válidas para conceptos, palabras que hemos decidido ignorar. ¿Por qué? Porque la jerga existente suele restringirse al dominio de un problema particular o una fase concreta del desarrollo. Sin embargo, una de las filosofías básicas de este libro es que la mayoría de las técnicas que recomendamos son universales: la modularidad se aplica al código, los diseños, la documentación y la organización de los equipos, por ejemplo. Cuando queríamos usar la palabra de jerga convencional en un contexto más amplio, resultaba confuso; parecía que no podíamos deshacernos del bagaje que llevaba consigo el término original. Cuando ha ocurrido eso, hemos contribuido al declive de la lengua inventando nuestros propios términos.

Código fuente y otros recursos

La mayor parte del código que se muestra en este libro se ha extraído de archivos fuente compilables, que se encuentran disponibles en la página web de Anaya Multimedia (http://www.anayamultimedia.es). Vaya al botón Selecciona Complemento de la ficha del libro, donde podrá descargar el código fuente.

También dispone de estos archivos en la página web del libro original en https://pragprog.com/titles/tpp20. Ahí también encontrará enlaces a recursos útiles, además de actualizaciones del libro original y otras noticias en inglés.

1 Si a lo largo de los años se sustituyen todos los componentes de un barco, ¿la nave resultante es el mismo barco?

Del prefacio de la primera edición

Este libro le ayudará a convertirse en un desarrollador mejor.

Puede que sea un desarrollador solitario, un miembro de un equipo grande para proyectos o un asesor que trabaja con muchos clientes a la vez. No importa; este libro le ayudará, como individuo, a hacer un trabajo mejor. No se trata de un libro teórico; nos centramos en temas prácticos, en que utilice su experiencia para tomar decisiones mejor fundamentadas. La palabra “pragmático” viene del latín pragmaticus (“hábil en asuntos”), que a su vez deriva del griego πραγματικός, que significa “adecuado para el uso”.

Este libro va de “hacer”.

La programación es un oficio artesano. En su forma más simple, se reduce a conseguir que un ordenador haga lo que queremos que haga (o lo que nuestros usuarios quieran que haga). Como programador, es en parte oyente, en parte consejero, en parte intérprete y en parte dictador. Intenta capturar requisitos imprecisos y encontrar una manera de expresarlos de forma que una simple máquina pueda hacerles justicia. Intenta documentar su trabajo para que otros puedan entenderlo, e intenta diseñar su trabajo de forma que otras personas pueda construir sobre él. Es más, trata de hacer todo eso mientras se enfrenta al paso inexorable del tiempo marcado para un proyecto. Hace pequeños milagros todos los días.

Es un trabajo difícil.

Hay mucha gente que le ofrece ayuda. Distribuidores de herramientas promocionan los milagros que realizan sus productos. Gurús de las metodologías prometen que sus técnicas garantizan resultados. Todo el mundo afirma que su lenguaje de programación es el mejor y que cada sistema operativo es la respuesta a todos los males concebibles.

Por supuesto, nada de esto es cierto. No hay respuestas fáciles. No hay una “mejor solución”, ya sea una herramienta, un lenguaje o un sistema operativo. Solo puede haber sistemas que son más apropiados en un conjunto de circunstancias determinado.

Aquí es donde entra el pragmatismo. No debería aferrarse a una tecnología concreta, sino tener una base de fondo y experiencia lo bastante amplia para que le permita elegir soluciones buenas en situaciones particulares. Ese fondo surge de un entendimiento de los principios básicos de la ciencia de la computación, y su experiencia viene de una amplia gama de proyectos prácticos. La teoría y la práctica se combinan para hacerle más fuerte.

Debe ajustar su enfoque para adaptarse a las circunstancias y el entorno actuales. Juzgue la importancia relativa de todos los factores que afecten a un proyecto y use su experiencia para generar las soluciones apropiadas. Haga esto de manera continua a medida que progresa el trabajo. Los programadores pragmáticos acaban el trabajo, y lo hacen bien.

¿Quién debería leer este libro?

Este libro va dirigido a quienes quieran ser programadores más efectivos y más productivos. Quizá se sienta frustrado porque le parece que no está aprovechando su potencial. Puede que se fije en colegas que parecen usar herramientas que les hacen más productivos que usted. Tal vez su trabajo actual utiliza tecnologías antiguas y quiere saber cómo pueden aplicarse ideas más nuevas a lo que hace.

No fingimos tener todas (ni siquiera la mayoría de) las respuestas, ni todas nuestras ideas son aplicables en todas las situaciones. Lo único que podemos decir es que, si sigue nuestro enfoque, ganará experiencia con rapidez, aumentará su productividad y tendrá un mejor entendimiento del proceso completo de desarrollo. Y escribirá software mejor.

¿Qué hace a un programador pragmático?

Cada programador es único, con puntos fuertes y débiles, preferencias y antipatías individuales. Con el tiempo, cada uno elabora su propio entorno personal. Ese entorno reflejará la individualidad del programador con tanta claridad como sus aficiones, su ropa o su corte de pelo. Sin embargo, si es un programador pragmático, compartirá muchas de las siguientes características:

■Primero en adoptar/se adapta con rapidez.

Tiene buen instinto para las tecnologías y las técnicas y le encanta probar cosas. Cuando le dan algo nuevo, enseguida le coge el tranquillo y lo integra con el resto de sus conocimientos. Su confianza nace de la experiencia.

■Inquisitivo.

Tiende a hacer preguntas. “Eso está muy bien, ¿cómo lo has hecho? ¿Tienes problemas con esa biblioteca? ¿Qué es esa informática cuántica de la que he oído hablar? ¿Cómo se implementan los enlaces simbólicos?” Es un coleccionista de hechos, cada uno de los cuales puede afectar a sus decisiones dentro de unos años.

■Pensador crítico.

Rara vez da las cosas por sentadas sin estudiar primero los hechos. Cuando un colega dice: “Porque así es como se hace” o un distribuidor promete la solución a todos sus problemas, huele un desafío.

■Realista.

Intenta entender la naturaleza subyacente de cada problema al que se enfrenta. Este realismo le da una impresión bastante exacta de lo difíciles que son las cosas y cuánto tiempo llevarán. Una comprensión profunda de que un proceso debería ser difícil o tardará bastante en completarse le proporciona la resistencia para seguir trabajando en ello.

■Versátil.

Se esfuerza por familiarizarse con una amplia variedad de tecnologías y entornos y trabaja para mantenerse al día con los nuevos desarrollos. Aunque puede que su trabajo actual requiera que sea un especialista, siempre será capaz de pasar a nuevas áreas y nuevos retos.

Hemos dejado las características más básicas para el final. Todos los programadores pragmáticos las comparten y son lo bastante básicas para expresarse como trucos:

Truco 1. Preocúpese por su oficio.

Nos parece que no tiene sentido desarrollar software a menos que nos preocupemos por hacerlo bien.

Truco 2. ¡Piense! En su trabajo.

Para ser un programador pragmático, le desafiamos a pensar en lo que está haciendo mientras lo está haciendo. No se trata de una inspección única de prácticas actuales, sino de una valoración continua de cada decisión que toma, cada día y en cada proyecto. No avance nunca con el piloto automático puesto. Debe pensar constantemente y ser crítico con su trabajo en tiempo real. El antiguo eslogan corporativo de IBM, THINK! (¡PIENSA!), es el mantra del programador pragmático.

Si le parece que esto es difícil para usted, entonces está mostrando el rasgo realista. Esto le va a llevar algo de tiempo valioso, tiempo que es probable que ya esté bajo una presión enorme. La recompensa es una implicación más activa en un trabajo que le gusta, una sensación de dominio de una variedad cada vez mayor de temas y el placer de un sentimiento de mejora continua. A largo plazo, la inversión de tiempo dará sus frutos cuando usted y su equipo se vuelvan más eficientes, escriban código más fácil de mantener y pasen menos tiempo en reuniones.

Pragmatistas individuales, equipos grandes

Algunas personas sienten que no hay sitio para la individualidad en equipos grandes o proyectos complejos. Dicen que el software es una disciplina de ingeniería que se descompone si los miembros individuales del equipo empiezan a tomar decisiones por su cuenta.

No estamos de acuerdo en absoluto.

Debería haber ingeniería en la creación del software. Sin embargo, eso no excluye la artesanía individual. Piense en las grandes catedrales construidas en Europa durante la Edad Media. Cada una de ellas necesitó miles de años-hombre de esfuerzo, distribuidos a lo largo de muchas décadas. Las lecciones aprendidas se transmitían a la siguiente generación de constructores, que hacían avanzar el estado de la ingeniería estructural con sus logros. Pero los carpinteros, los canteros, los tallistas y los vidrieros eran artesanos, e interpretaban los requisitos de ingeniería para producir un conjunto que trascendía el aspecto puramente mecánico de la construcción. Su fe en sus contribuciones individuales era lo que sustentaba los proyectos: los que cortamos solo simples piedras debemos visualizar catedrales.

Dentro de la estructura general de un proyecto, siempre hay espacio para la individualidad y la artesanía. Esto es cierto en particular si se tiene en cuenta el estado actual de la ingeniería de software. Dentro de cien años, puede que nuestra ingeniería parezca tan arcaica como las técnicas usadas por los constructores de catedrales medievales pueden parecer a los ingenieros actuales, mientras que se seguirá honrando nuestra artesanía.

Es un proceso continuo

Un turista que visitaba el Eton College en Inglaterra preguntó al jardinero cómo lograba que el césped fuese tan perfecto.

—Es fácil. Solo hay que retirar el rocío todas las mañanas, cortar cada dos días y pasar el rodillo una vez a la semana —respondió el jardinero.

—¿Eso es todo? —preguntó el turista.

—Desde luego —respondió el jardinero—. Hágalo durante 500 años y también tendrá un césped así de bonito.

Los buenos céspedes necesitan pequeñas cantidades de cuidados diarios, y lo mismo ocurre con los buenos programadores. A los consultores de gestión les gusta meter la palabra kaizen en las conversaciones. “Kaizen” es un término japonés que captura el concepto de hacer muchas mejoras pequeñas de manera continua. Se consideró que fue una de las principales razones para la espectacular ganancia en productividad y calidad en la fabricación japonesa y se copió por todo el mundo. El kaizen se aplica también a los individuos. Trabaje cada día para perfeccionar sus habilidades y para añadir nuevas herramientas a su repertorio. A diferencia del césped de Eton, empezará a ver resultados en cuestión de días. Con los años, le impresionará ver cuánto ha florecido su experiencia y cuánto han crecido sus habilidades.

1

Una filosofía pragmática

Este libro es sobre usted.

No se confunda, es su carrera y, lo que es más importante, “Es su vida”. Le pertenece. Está aquí porque sabe que puede convertirse en un desarrollador mejor y ayudar a otros a ser mejores también. Puede convertirse en un programador pragmático.

¿Qué distingue a los programadores pragmáticos? Consideramos que es una actitud, un estilo, una filosofía sobre la forma de abordar los problemas y sus soluciones. Piensan más allá del problema inmediato, lo sitúan en un contexto más grande y buscan el panorama general. Al fin y al cabo, sin ese contexto más grande, ¿cómo podemos ser pragmáticos? ¿Cómo podemos llegar a acuerdos inteligentes y tomar decisiones bien fundadas?

Otra clave para su éxito es que los programadores pragmáticos asumen la responsabilidad de todo lo que hacen, algo que veremos en “El gato se comió mi código fuente”. Al ser responsables, los programadores pragmáticos no van a sentarse tranquilamente a ver cómo sus proyectos se vienen abajo por negligencias. En “Entropía del software”, le explicamos cómo mantener sus proyectos impolutos. A la mayoría de la gente le resulta difícil el cambio, unas veces por buenas razones y otras por una simple cuestión de inercia. En “Sopa de piedras y ranas hervidas”, echamos un vistazo a una estrategia para instigar el cambio y (por el interés del equilibrio) presentamos el cuento admonitorio de un anfibio que ignoraba los peligros del cambio gradual.

Uno de los beneficios de entender el contexto en el que trabajamos es que se vuelve más fácil saber lo bueno que tiene que ser nuestro software. A veces, “casi perfecto” es la única opción posible, pero, a menudo, hay que sacrificar algo a cambio. Exploramos esto en “Software lo bastante bueno”.

Por supuesto, necesita tener una amplia base de conocimiento y experiencia para sacar todo esto adelante. El aprendizaje es un proceso continuo y en desarrollo. En “Su cartera de conocimientos”, vemos algunas estrategias para mantener el ímpetu.

Por último, ninguno de nosotros trabaja en el vacío. Todos pasamos gran parte del tiempo interactuando con otras personas. “¡Comuníquese!” muestra una lista de maneras en que podemos hacer esto mejor. La programación pragmática surge de una filosofía de pensamiento pragmático. Este capítulo determina la base para esa filosofía.

1 Es su vida

No estoy en este mundo para cumplir tus expectativas, y tú no estás en este mundo para cumplir las mías.

—Bruce Lee.

Es su vida. Le pertenece. Usted la dirige. Usted la crea.

Muchos desarrolladores con los que hablamos se sienten frustrados. Sus preocupaciones son variadas. Algunos sienten que están estancándose en su trabajo, otros que la tecnología ha pasado de largo a su lado. Hay personas que sienten que están infravaloradas, que están mal pagadas o que sus equipos son tóxicos. A lo mejor quieren mudarse a Asia o Europa, o trabajar desde casa.

Y la respuesta que les damos es siempre la misma.

“¿Por qué no puedes cambiarlo?”.

El desarrollo de software debe aparecer cerca de lo más alto en cualquier lista de carreras en las que tenemos control. Hay demanda para nuestras habilidades, nuestros conocimientos cruzan fronteras geográficas, podemos trabajar de manera remota. Nos pagan bien. Realmente podemos hacer lo que queramos.

Pero, por alguna razón, los desarrolladores parecen resistirse al cambio. Se apoltronan y esperan que las cosas mejoren. Se quedan mirando con pasividad mientras sus habilidades se quedan anticuadas y se quejan de que sus empresas no les ofrecen formación. Se fijan en los anuncios de destinos exóticos mientras van en el autobús y, después, salen a la lluvia heladora y caminan con pesadez hasta el trabajo.

Así pues, aquí está el truco más importante del libro.

Truco 3. Tiene capacidad de acción.

¿Su entorno laboral es un asco? ¿Le aburre su trabajo? Intente arreglarlo, pero no se pase la vida intentándolo. Como dice Martin Fowler, “puede cambiar su organización o cambiar su organización”.1

Si le parece que la tecnología está pasando de largo respecto a usted, saque tiempo (a su propio ritmo) para estudiar cosas nuevas que parezcan interesantes. Está invirtiendo en usted mismo, así que es razonable que lo haga fuera de su horario laboral.

¿Quiere trabajar de manera remota? ¿Lo ha pedido? Si le dicen que no, busque a alguien que diga que sí.

Esta industria ofrece un conjunto notable de oportunidades. Sea proactivo y aprovéchelas.

Las secciones relacionadas incluyen

■Tema 4, “Sopa de piedras y ranas hervidas”.

■Tema 6, “Su cartera de conocimientos”.

2 El gato se comió mi código fuente

La mayor debilidad de todas es el miedo a parecer débil.

—J.B. Bossuet, Política deducida de las palabras propias de la Sagrada Escritura, 1709.

Una de las piedras angulares de la filosofía pragmática es la idea de asumir la responsabilidad por nosotros mismos y nuestras acciones en lo que respecta al avance de nuestra carrera, nuestro aprendizaje y nuestra educación, nuestro proyecto y nuestro trabajo diario. Los programadores pragmáticos se hacen cargo de su propia carrera y no tienen miedo de admitir el desconocimiento o el error. No es el aspecto más agradable de la programación, desde luego, pero ocurrirá, incluso en los mejores proyectos. Pese a las pruebas exhaustivas, la buena documentación y la automatización sólida, hay cosas que salen mal. Las entregas se retrasan. Surgen problemas técnicos imprevistos.

Estas cosas pasan e intentamos lidiar con ellas de la forma más profesional posible. Eso significa ser honestos y directos. Podemos estar orgullosos de nuestras habilidades, pero debemos asumir la responsabilidad sobre nuestros defectos, nuestra ignorancia y nuestros errores.

Confianza del equipo

Por encima de todo, su equipo necesita poder confiar en y depender de usted, y usted necesita sentirse cómodo dependiendo de cada uno de ellos también. Confiar en un equipo es esencial para la creatividad y la colaboración, según muestran diversos trabajos de investigación.2 En un entorno sano basado en la confianza, podemos decir lo que pensamos de forma segura, presentar nuestras ideas y depender de los miembros del equipo, que a su vez pueden depender de nosotros. Si no hay confianza, bueno...

Imagine un equipo de ninjas sigilosos con alta tecnología que se infiltra en la guarida de un villano. Tras meses de planificación y perfecta ejecución, han llegado al lugar. Ahora, es su turno para activar la cuadrícula de guía láser: “Lo siento, chicos, no tengo el láser. El gato estaba jugando con el puntito rojo y lo he dejado en casa”.

Ese tipo de traición de la confianza debe ser difícil de arreglar.

Asuma la responsabilidad

La responsabilidad es algo a lo que accedemos de manera activa. Adquirimos un compromiso para garantizar que algo se hace bien, pero tenemos necesariamente un control directo sobre cada aspecto de ello. Además de dar lo mejor de nosotros mismos, debemos analizar la situación para detectar riesgos que quedan fuera de nuestro control. Tenemos derecho a no asumir una responsabilidad sobre una situación imposible, o una en la que los riesgos son demasiado grandes, o las implicaciones éticas son demasiado sospechosas. Tendrá que tomar la decisión en función de sus propios valores y su criterio.

Cuando acepte la responsabilidad sobre un resultado, debería esperar tener que responder por él. Cuando cometa una equivocación (como hacemos todos) o un error de juicio, admítalo con honestidad e intente proponer opciones.

No culpe a otra persona ni circunstancia, ni se invente excusas. No eche la culpa a un distribuidor, a un lenguaje de programación, al director o a sus compañeros. Puede que todas esas cosas hayan influido, pero depende de usted ofrecer soluciones, no excusas.

Si existía un riesgo de que el distribuidor le fallase, debería haber tenido un plan de contingencia. Si su unidad de almacenamiento masivo se estropea (y con ella se pierde todo su código fuente) y no tiene una copia de seguridad, es culpa suya. Decirle a su jefe “el gato se ha comido mi código fuente” no servirá.

Truco 4. Ofrezca opciones, no se invente excusas pobres.

Antes de acercarse a alguien a decirle por qué algo no puede hacerse, va con retraso o está estropeado, pare y escúchese. Hable con el patito de goma de su monitor o con el gato. ¿Su excusa suena razonable o estúpida? ¿Cómo va a sonarle a su jefe?

Repase la conversación en su mente. ¿Qué es probable que diga la otra persona? ¿Le preguntará si ha probado esto o ha considerado aquello? ¿Cómo responderá usted? Antes de ir a darle a esa persona la mala noticia, ¿hay algo más que pueda probar? A veces, ya sabe lo que van a decirle, así que ahórreles la molestia.

En vez de excusas, ofrezca opciones. No diga que no puede hacerse; explique qué puede hacerse para resolver la situación. ¿Hay que eliminar código? Dígaselo y explique el valor de la refactorización (véase el tema 40, “Refactorización”).

¿Necesita dedicar tiempo a crear un prototipo para determinar la mejor manera de proceder (véase el tema 13, “Prototipos y notas en post-its”)? ¿Tiene que introducir pruebas mejores (véase el tema 41, “Probar para escribir código” y “Pruebas despiadadas y continuas” en el capítulo 9) o automatización para evitar que vuelva a ocurrir?

Quizá necesite recursos adicionales para completar esta tarea. ¿O tal vez necesite pasar más tiempo con los usuarios? Quizá la cuestión sea usted mismo: ¿necesita aprender alguna técnica o tecnología en mayor profundidad? ¿Le ayudaría algún libro o curso? No tenga miedo de pedir o de admitir que necesita ayuda.

Intente olvidar las malas excusas antes de decirlas en voz alta. Si no le queda más remedio que usarlas, dígaselo primero a su gato. Al fin y al cabo, si el pequeño Calcetines va a cargar con la culpa...

Las secciones relacionadas incluyen

■Tema 49, “Equipos pragmáticos”.

Retos

■¿Cómo reacciona cuando alguien (el cajero del banco, el mecánico del taller o un dependiente) le pone una mala excusa? ¿Qué piensa de esa persona y de su empresa como resultado?

■Cuando se oiga a sí mismo decir: “No lo sé”, asegúrese de añadir después: “Pero lo averiguaré”. Es una manera genial de admitir lo que no sabe, pero asumiendo después la responsabilidad como un profesional.

3 Entropía del software

Aunque el desarrollo de software es inmune a casi todas las leyes de la física, el inexorable incremento de la entropía nos afecta de pleno. La entropía es un término de física que se refiere a la cantidad de “desorden” en un sistema. Por desgracia, las leyes de la termodinámica garantizan que la entropía en el universo tienda hacia el máximo. Cuando aumenta el desorden en el software, lo denominamos “pudrición del software”. Algunas personas prefieren utilizar el término más optimista “deuda técnica”, con la noción implícita de que la pagarán algún día. Es probable que no lo hagan.

En cualquier caso, al margen del nombre, tanto la deuda como la pudrición pueden extenderse sin control.

Existen muchos factores que pueden contribuir a la pudrición del software. El más importante parece ser la psicología, o la cultura, que se emplea en un proyecto. Incluso si somos un equipo de uno, la psicología de nuestro proyecto puede ser una cuestión muy delicada. A pesar de la planificación escrupulosa y las personas más adecuadas, un proyecto puede deteriorarse y arruinarse durante su vida. Y, por otra parte, hay otros proyectos que, pese a las enormes dificultades y los contratiempos constantes, luchan con éxito contra la tendencia natural hacia el desorden y consiguen llegar a buen puerto.

¿Qué marca la diferencia?

En el centro de las ciudades, algunos edificios son bonitos y están limpios, mientras que otros son armatostes deteriorados. ¿Por qué? Los investigadores en el campo del crimen y el deterioro urbano descubrieron un mecanismo desencadenante fascinante, uno que convierte con rapidez un edificio limpio, intacto y habitado en uno ruinoso y abandonado.3

Una ventana rota.

Una ventana rota que se deje sin reparar durante un periodo de tiempo considerable infunde en los habitantes del edificio una sensación de abandono, una sensación de que a los responsables no les importa el edificio. Así que se rompe otra ventana. La gente empieza a tirar basura. Aparecen grafitis. Comienza a producirse un daño estructural serio. En un periodo de tiempo relativamente corto, el edificio queda demasiado dañado para que el propietario quiera arreglarlo, y la sensación de abandono se convierte en una realidad.

¿Qué marcaría una diferencia? Varios psicólogos han realizado estudios4 que demuestran que la desesperanza puede ser contagiosa. Piense en el virus de la gripe en espacios cerrados. Ignorar una situación que está claro que va mal refuerza la idea de que quizá nada puede arreglarse, que no le importa a nadie, que todo está abocado al fracaso; son todo pensamientos negativos que se extienden por los miembros del equipo, lo que genera un círculo vicioso.

Truco 5. No viva con ventanas rotas.

No deje “ventanas rotas” (malos diseños, decisiones equivocadas o código pobre) sin reparar. Arregle cada una en cuanto la descubra. Si no hay tiempo suficiente para arreglarla de forma adecuada, tápela con tablas de manera temporal. Quizá pueda comentar el código irritante, mostrar un mensaje que diga “Sin implementar” o sustituir con datos dummy. Haga algo para evitar más daños y para demostrar que está por encima de la situación.

Hemos visto sistemas limpios y funcionales que se deterioran con bastante rapidez una vez que las ventanas empiezan a romperse. Hay otros factores que pueden contribuir a la pudrición del software, los veremos más adelante, pero la negligencia acelera la pudrición más que ningún otro factor.

Puede que esté pensando que nadie tiene tiempo de andar limpiando todos los cristales rotos de un proyecto. Si es así, más vale que empiece a planear hacerse con un contenedor de basura o mudarse a otro vecindario. No deje que la entropía gane.

Primero, no haga daño

Andy tenía un conocido que era obscenamente rico. Su casa estaba inmaculada, llena de antigüedades de valor incalculable, obras de arte tridimensionales y cosas así. Un día, un tapiz que estaba colgado demasiado cerca de una chimenea empezó a arder. Los bomberos llegaron corriendo para salvar la situación y la casa. Pero, antes de arrastrar las mangueras grandes y sucias por el interior, se detuvieron (con las llamas propagándose) para extender una alfombra entre la puerta principal y el origen del incendio.

No querían estropear la moqueta.

Sí, suena bastante exagerado. Desde luego, la máxima prioridad de los bomberos es sofocar el incendio, y al cuerno con los daños colaterales. Pero estaba claro que habían evaluado la situación, confiaban en su capacidad para controlar el fuego y tuvieron cuidado de no infligir un daño innecesario a la propiedad. Eso es lo que debe hacerse con el software: no causar daños colaterales solo porque hay algún tipo de crisis. Una ventana rota ya son demasiadas.

Una ventana rota (una porción de código mal diseñada, una mala decisión de la dirección con la que el equipo debe vivir mientras dure el proyecto) es lo único que hace falta para comenzar el declive. Si se da cuenta de que está trabajando en un proyecto con bastantes ventanas rotas, es demasiado fácil adoptar la mentalidad de que “todo el resto de este código es una porquería, voy a seguir en esa línea, sin más”. No importa si el proyecto ha ido bien hasta ese punto. En el experimento original que llevó a la teoría de las ventanas rotas, un coche abandonado se quedó sin tocar durante una semana. Pero, en cuanto se rompió una sola ventana, el coche fue desmantelado en cuestión de horas.

Del mismo modo, si se encuentra trabajando en un proyecto en el que el código es bonito y prístino (escrito con limpieza, bien diseñado y elegante), es probable que ponga especial cuidado en no estropearlo, igual que los bomberos. Incluso aunque haya un incendio (fecha límite, fecha de lanzamiento, demostración para una feria comercial, etc.), no querrá ser el primero que haga un lío y cause un daño adicional.

Solo dígase: “Nada de ventanas rotas”.

Las secciones relacionadas incluyen

■Tema 10, “Ortogonalidad”.

■Tema 40, “Refactorización”.

■Tema 44, “Poner nombre a las cosas”.

Retos

■Ayude a fortalecer a su equipo haciendo un sondeo en el vecindario de su proyecto. Elija dos o tres ventanas rotas y hable con sus compañeros de cuáles son los problemas y qué podría hacerse para arreglarlos.

■¿Se da cuenta cuando se rompe una ventana por primera vez? ¿Cuál es su reacción? Si ha sido a causa de la decisión de otra persona o de una orden del director, ¿qué puede hacer usted al respecto?

4 Sopa de piedras y ranas hervidas

Tres soldados volvían a casa hambrientos tras la guerra. Cuando vieron un pueblo en la lejanía, se les levantó el ánimo; estaban seguros de que los aldeanos les ofrecerían una comida. Sin embargo, al llegar allí, se encontraron las puertas y las ventanas cerradas. Después de muchos años de guerra, los alimentos escaseaban y los aldeanos hacían acopio de lo que tenían.

Lejos de desistir, los soldados pusieron a hervir una cazuela con agua y metieron con cuidado tres piedras. Los asombrados aldeanos se acercaron a mirar.

—Esto es sopa de piedras —explicaron los soldados.

—¿Eso es todo lo que lleva? —preguntaron los aldeanos.

—¡Desde luego! Aunque algunos dicen que sabe incluso mejor con unas zanahorias...

Un aldeano se fue corriendo y volvió enseguida con una cesta de zanahorias de su reserva.

Unos minutos después, los aldeanos volvieron a preguntar:

—¿Eso es todo?

—Bueno —dijeron los soldados—, un par de patatas le dan cuerpo.

Otro aldeano salió corriendo.

En la siguiente hora, los soldados hicieron una lista con más ingredientes que mejorarían la sopa: carne, puerros, sal y hierbas aromáticas. Cada vez, un aldeano diferente iba corriendo a buscar en su despensa personal.

Al final, tenían una gran cazuela de sopa humeante. Los soldados quitaron las piedras y se sentaron con el resto del pueblo para disfrutar la primera comida decente que cualquiera de ellos había probado en meses.

Hay un par de moralejas en la historia de la sopa de piedras. A los aldeanos los engañan los soldados, que utilizan la curiosidad de los aldeanos para conseguir comida de ellos. Pero lo que es más importante es que los soldados actúan como catalizador, uniendo al pueblo para que todos juntos puedan producir algo que no podrían haber hecho solos, un resultado sinérgico. Al final, todo el mundo gana.

De vez en cuando, quizá le convenga emular a los soldados.

Puede que esté en una situación en la que sepa con exactitud lo que es necesario hacer y cómo hacerlo. El sistema entero aparece ante sus ojos; sabe que está bien. Pero, si pide permiso para abordarlo todo, se encontrará con retrasos y miradas confusas. Se formarán comités, habrá que aprobar presupuestos y las cosas se complicarán. Todo el mundo se guardará sus propios recursos. Esto se denomina a veces “fatiga de arranque”.

Es hora de preparar la sopa de piedras. Determine qué puede pedir de forma razonable. Desarróllelo bien. Una vez que lo tenga, enséñeselo a otras personas y deje que se maravillen. Después, diga: “Por supuesto, estaría mejor si añadiésemos...”. Finja que no es importante. Siéntese y espere a que empiecen a pedirle que añada la funcionalidad que quería desde el principio. A la gente le resulta más fácil unirse a un éxito en curso. Enséñeles una muestra del futuro y conseguirá su apoyo.5

Truco 6. Sea un catalizador para el cambio.

El lado de los aldeanos

Por otra parte, la historia de la sopa de piedras también habla de un engaño sutil y gradual. Tiene que ver con concentrarse demasiado en algo. Los aldeanos piensan en las piedras y se olvidan del resto del mundo. Todos caemos en esa trampa, todos los días. Las cosas nos acechan.

Todos hemos visto los síntomas. Los proyectos van escapándose por completo de nuestro control de forma lenta e inexorable. La mayoría de los desastres de software empiezan siendo demasiado pequeños para que los notemos, y la mayoría de los costes adicionales en los proyectos se producen día a día. Los sistemas van alejándose de sus especificaciones funcionalidad a funcionalidad, mientras se añade un parche tras otro a una porción del código hasta que ya no queda nada del original. A menudo, esa acumulación de cosas pequeñas es la que acaba con la moral y con los equipos.

Truco 7. Recuerde el panorama general.

Nunca hemos probado esto, de verdad, pero dicen que, si coges una rana y la sueltas en agua hirviendo, saltará fuera del recipiente. Sin embargo, si la dejas en una cazuela con agua fría y después vas calentándola de manera gradual, la rana no notará el aumento lento de la temperatura y se quedará quieta hasta que esté cocinada.

Observe que el problema de la rana es diferente al de las ventanas rotas que hemos visto en el tema 3, “Entropía del software”. En la teoría de las ventanas rotas, la gente pierde la voluntad de luchar contra la entropía porque percibe que a nadie más le importa. La rana no nota el cambio, sin más.

No sea como la rana imaginaria. No pierda de vista el panorama general. Revise constantemente lo que pasa a su alrededor, no solo lo que está haciendo usted a nivel individual.

Las secciones relacionadas incluyen

■Tema 1, “Es su vida”.

■Tema 38, “Programar por casualidad”.

Retos

■Mientras revisaba un borrador de la primera edición, John Lakos planteó la siguiente cuestión: los soldados engañaron a los aldeanos de manera progresiva, pero el cambio que catalizaron fue bueno para todos. Sin embargo, al engañar a la rana de forma progresiva, le hacemos daño. ¿Puede determinar si está haciendo sopa de piedras o sopa de ranas cuando intenta catalizar un cambio? ¿Es la decisión subjetiva u objetiva?

■Rápido, sin mirar, ¿cuántas luces hay encima de usted? ¿Y cuántas hay en la sala? ¿Cuánta gente? ¿Hay algo fuera de contexto, algo que parezca que no debería estar ahí? Este es un ejercicio de consciencia situacional, una técnica practicada a menudo por personas que van desde Boy y Girl Scouts a los SEAL de la Armada de EE. UU. Acostúmbrese a prestar atención y a ser consciente de lo que pasa a su alrededor. Después, haga lo mismo en su proyecto.

5 Software lo bastante bueno

Lo bueno se malogra queriendo mejorarlo.

—Shakespeare, El rey Lear 1.4.

Hay un chiste (un poco) viejo sobre una empresa que hace un pedido de 100.000 CI a un fabricante japonés. Parte de la especificación era la tasa de defectos: un chip de cada 10.000. Unas semanas después, llega el pedido: una caja grande que contiene miles de CI y una caja pequeña que contiene solo diez. Pegada en la caja pequeña hay una etiqueta que dice: “Estos son los diez defectuosos”.

Ojalá tuviésemos de verdad este tipo de control sobre la calidad. Pero el mundo real no nos deja producir mucho que sea realmente perfecto, sobre todo software libre de errores. El tiempo, la tecnología y el temperamento conspiran contra nosotros.

Sin embargo, esto no tiene por qué ser frustrante. Como describió Ed Yourdon en un artículo en IEEE Software, When good-enough software is best [You95], puede disciplinarse para escribir software que sea lo bastante bueno, para sus usuarios, para las personas que tendrán que mantenerlo en el futuro y para su propia tranquilidad. Descubrirá que es más productivo y sus usuarios están más contentos. Y puede que descubra que sus programas son en realidad mejores por su incubación más corta.

Antes de seguir, tenemos que matizar lo que vamos a decir. La frase “lo bastante bueno” no implica código chapucero o mal producido. Todos los sistemas deben cumplir los requisitos de sus usuarios para tener éxito, y deben ajustarse a unos estándares básicos de rendimiento, privacidad y seguridad. Lo que defendemos es que se dé a los usuarios la oportunidad de participar en el proceso de decidir si lo que hemos producido es lo bastante bueno para sus necesidades.

Implique a sus usuarios en la compensación

Por lo general, escribirá software para otras personas. A menudo, se acordará de averiguar lo que quieren.6 Pero ¿les pregunta alguna vez lo bueno que quieren que sea su software? A veces, no habrá opción. Si está trabajando en marcapasos, sistemas de piloto automático o una biblioteca de bajo nivel que va a divulgarse ampliamente, los requisitos serán más rigurosos y sus opciones serán más limitadas.

Sin embargo, si está trabajando en un producto totalmente nuevo, tendrá restricciones diferentes. Los responsables del marketing tendrán promesas que cumplir, los usuarios finales pueden haber hecho planes en función de una fecha de entrega y, desde luego, su empresa tendrá restricciones respecto al flujo de caja. Sería poco profesional ignorar los requisitos de estos usuarios solo para añadir funcionalidades nuevas al programa o para pulir el código una vez más. No estamos abogando por el pánico: sería igual de poco profesional prometer plazos imposibles y recortar elementos de ingeniería básicos para cumplir esos plazos.

El alcance y la calidad del sistema que producimos deberían describirse como parte de los requisitos de ese sistema.

Truco 8. Convierta la calidad en una cuestión de los requisitos.

A menudo, se verá en situaciones en las que se requiere una compensación. Sorprendentemente, muchos usuarios preferirían utilizar software sin pulir del todo hoy que esperar un año para tener la versión brillante y con toda la parafernalia (y, en realidad, puede que lo que necesiten de aquí a un año sea totalmente diferente, de todas formas). Muchos departamentos de TI con presupuestos muy ajustados estarán de acuerdo. A menudo, un software genial hoy es preferible a la fantasía de un software perfecto mañana. Si da a sus usuarios algo con lo que jugar pronto, con frecuencia su feedback le llevará a conseguir una solución final mejor (véase el tema 12, “Balas trazadoras”).

Saber cuándo parar

En algunos aspectos, programar es como pintar. Empezamos con un lienzo en blanco y determinadas materias primas básicas. Utilizamos una combinación de ciencia, arte y oficio para determinar qué hacer con ellas. Esbozamos una forma general, pintamos el entorno subyacente y, después, añadimos los detalles. Damos un paso atrás todo el tiempo con ojo crítico para ver lo que hemos hecho. De vez en cuando, desechamos un lienzo y empezamos otra vez.

Pero los artistas dirán que todo el trabajo duro se verá arruinado si no sabemos cuándo parar. Si añadimos capa tras capa, detalle tras detalle, el cuadro se pierde en la pintura.

No arruine un buen programa tratando de embellecerlo o refinarlo en exceso. Siga adelante y deje que su código se mantenga por sí mismo durante un tiempo. Puede que no sea perfecto. No se preocupe: nunca podría ser perfecto. (En el capítulo 7, “Mientras escribe código”, veremos filosofías para desarrollar código en un mundo imperfecto).

Las secciones relacionadas incluyen

■Tema 45, “El pozo de los requisitos”.

■Tema 46, “Resolver rompecabezas imposibles”.

Retos

■Fíjese en las herramientas de software y los sistemas operativos que utiliza con regularidad. ¿Puede encontrar cualquier prueba de que estas organizaciones o desarrolladores se sienten cómodos enviando software que saben que no es perfecto? Como usuario, ¿preferiría (1) esperar a que eliminen todos los errores, (2) tener un software complejo y aceptar algunos errores o (3) optar por un software más simple con menos errores?

■Considere el efecto de la modularización en la entrega de software. ¿Llevaría más o menos tiempo conseguir un bloque de software monolítico con acoplamiento fuerte para la calidad requerida en comparación con un sistema diseñado como módulos de microservicios con acoplamiento muy débil? ¿Cuáles son las ventajas y las desventajas de cada enfoque?

■¿Se le ocurre algún software popular que tenga un exceso de funcionalidades innecesarias? Es decir, un software que contenga muchas más funcionalidades de las que se usarán jamás, cada una de ellas generando más posibilidades de que haya errores y puntos débiles en la seguridad, y haciendo que las funcionalidades que sí se usan sean más difíciles de encontrar y gestionar. ¿Corre usted mismo el peligro de caer en esta trampa?

6 Su cartera de conocimientos

Invertir en conocimientos produce siempre los mejores beneficios.

—Benjamin Franklin.

Ah, el viejo Ben Franklin, siempre con una homilía concisa a mano. Bueno, si pudiésemos irnos pronto a la cama y madrugar, seríamos magníficos programadores, ¿no? Según un proverbio inglés, el pájaro madrugador se lleva el gusano, pero ¿qué pasa con el gusano madrugador?

Sin embargo, en este caso, Ben da en el clavo. Nuestro conocimiento y nuestra experiencia son nuestros activos profesionales más importantes en el día a día.

Por desgracia, son activos con fecha de caducidad.7 Nuestros conocimientos se quedan obsoletos a medida que se desarrollan técnicas, lenguajes y entornos nuevos. Las fuerzas del mercado cambiante pueden hacer que nuestra experiencia quede desfasada o sea irrelevante. Teniendo en cuenta el ritmo cada vez más veloz del cambio en nuestra sociedad tecnológica, esto puede ocurrir con bastante rapidez.

A medida que disminuye el valor de nuestro conocimiento, también se reduce nuestro valor para nuestra empresa o nuestro cliente. Queremos evitar que eso suceda.

Nuestra capacidad para aprender cosas nuevas es nuestro activo estratégico más importante. Pero ¿cómo aprendemos a aprender, y cómo sabemos qué aprender?

Su cartera de conocimientos

Nos gusta pensar que todos los hechos que los programadores saben acerca de la informática, los dominios de aplicación en los que trabajan y toda su experiencia son como sus carteras de conocimientos. Gestionar una cartera de conocimientos es muy similar a gestionar una cartera de valores:

1.Los inversores serios invierten con regularidad, como costumbre.

2.