Del software

Este documento refleja las influencias más destacadas que he tenido a lo largo de mi día a día como programador, que me han ayudado a tener una visión amplia sobre lo que significa programar, cómo llevar a cabo la gestión del proyecto o cómo desarrollar software que funcione.

  1. Filosofía y valores
  2. Gestión de proyecto
    1. Planificación
    2. Ritmo y ciclos de desarrollo
    3. Liderazgo técnico
  3. Cómo construir software que funcione
    1. Principios
    2. Prácticas
    3. Patrones
  4. Aprender de la experiencia de otros

Filosofía y valores

Code as Design: three essays, Jack W. Reeves [1983]

El mejor paper que he leído sobre la dicotomía diseño/implementación y la ingeniería de software: la unidad básica de diseño es el código – ésta regla sirve para explicar por qué las Java Annotations se usan y otras técnicas externas al código (como UML) no.

The cathedral and the bazaar, Eric S. Raymond [1997]

Este texto no sólo popularizó el software libre, sino que también (conjuntamente con el movimiento agile) ayudó a dar forma a una nueva manera de desarrollar software.

Agile manifesto y sus principioss, 17 programadores inteligentes [2001]

Todavía válido a día de hoy.

The Simplest Thing that Could Possibly Work, Bill Berners entrevista a Ward Cunnigham [2004]

Sobre el estilo de resolución de problemas (y programación) de Cunningham: «So when I asked [KentBeck], What’s the simplest thing that could possibly work? I wasn’t even sure. I wasn’t asking, What do you know would work? I was asking, What’s possible? What is the simplest thing we could say in code, so that we’ll be talking about something that’s on the screen, instead of something that’s ill-formed in our mind. I was saying, Once we get something on the screen, we can look at it. If it needs to be more, we can make it more.»

Inventing on principle, Bret Victor [2012]

Inspiradora charla, enfocada en el rol del feedback en el proceso creativo, como herramienta para entender el avance pero también para tener en la mente el objetivo global: desarrollar un producto que se use.

Gestión de proyecto

Planificación

Extremme Programming Explained: embrace change, Kent Beck [1999]

Uses o no XP para gestionar tus proyectos, este libro presenta metáforas claras sobre lo que es realmente importante en el desarrollo de software. Muy útil también para clarificar los roles e incentivos de los actores que participan en un proyecto.

Planning Extremme Programming, Martin Fowler & Kent Beck [2001]

Una ligera y útil introducción a la planificación del proyecto siguiendo las directrices XP.

User Stories applied, Mike Cohn [2004]

Cómo planificar mediante historias de usuario. Aunque algunas partes del libro son prescindibles, la revisión general de otros métodos de recogida de requisitos y los trucos a la hora de usar historias de usuario para planificar me han sido útiles.

Ritmo y ciclos de desarrollo

Toyota Production System, Taichii Ohno [1980]

Una revisión muy general de cómo Toyota producía coches en los 70/80 y por qué era revolucionario en su momento.

A rational design process: how and why to fake it, David Parnas & Paul Clements [1986]

«The picture of the software designer deriving his design in a rational, error-free way from a statement of requirements is quite unrealistic. No system has ever been development in that way, and probably none ever will. Event the small program developments shown in textbooks and papers are unreal. They have been revised and polished until the author has shown us what he wishes he had done, not what actually did happen.»

Software G Forces: the effects of acceleration, Kent Beck [2011]

Analiza cómo el tiempo que tarda una versión en salir a mercado, afecta a cómo cómo planificar, testear, desplegar y vender software. Cuanto más rápido sea el time-to-market, más necesitarás automatización en todos los pasos y más se orientará tu modelo de negocio hacia los servicios.

Continuous delivery: reliable software releases through build, test and deployment automation, Jezz Humble & David Farley [2011]

Libro de referencia para revisar cuando estés listo para el siguiente paso en la automatización de tu pipeline. Desarrolla el concepto de deployment pipeline.

Big transitions in small steps, Kent Beck [2012]

Sobre las estrategias a tener en cuenta para evolucionar estructuras de datos, código o cambios en la arquitectura de tu aplicación.

Is TDD Dead?, Kent Beck, David Heinemeier Hansson & Martin Fowler [2014]

Una serie de conversaciones iniciadas por  la keynote de David Heinemeier en la RailsConf (y después elaborada en su blog: TDD is dead. Long live testing) que criticaba el uso de TDD por parte de la comunidad Rails. Una gran oportunidad para ver a 3 maestros hablando sobre ciclos de feedback y cómo enfocan el diseño de software.

Liderazgo técnico

3 flavors of leadership, Don Gray & Dan Starr [2001]

Diferencias entre 3 estilos de liderazgo.

Who needs an architect?, Martin Fowler [2003]

Qué significa el liderazgo técnico.

Maker’s schedule, Manager’s schedule, Paul Graham [2009]

«The manager’s schedule is […] embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour. [Maker], like programmers and writers, generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.»

Driving technical change, Terrence Ryan [2010]

Sobre patrones de comportamiento. Me atrevería a llamarlos «patrones de resistencia»: las razones por qué alguna gente se resiste al cambio. El liderazgo -hacer que las ideas y acciones de la gente se muevan de un sitio a otro- requiere entender sus miedos, ilusiones e incentivos.

Cómo desarrollar software que funcione

Principios

La principal tarea del programador es gestionar la complejidad.

On the criteria to be used in decomposing a system into modules, David Parnas [1972]

El primer paper que pone sobre la mesa por qué es una buena idea a la hora de crear módulos (funciones, clases, etc) centrarse en ocultar la complejidad en vez de centrarse en modelar el flujo secuencial de operaciones. Esta regla aplica a todos los niveles de diseño: methods, class, packages, etc.

A laboratory to teach Object-oriented programming, Beck & Cunningham [1989]

Paper en  OOPSLA’89 donde por vez primera se menciona la técnica de Class-Responsibility-Collaborators para modelar objetos.

4 rules of simple design en «The White Book», Kent Beck [2000]

La lógica general de diseño descrita en Xtremme Programming Explained: Passes the tests + Reveals intention + No duplication + Fewest elements.

Code complete, Steve McConnell [2004]

Un libro de referencia muy bueno, además de contener enlaces a las fuentes y papers originales.

Implementation patterns, Kent Beck [2008]

Este libro me ayudó a entender las decisiones que se toman diariamente para escribir código legible y mantenible: desde trucos para nombrar variables a cómo gestionar el crecimiento de software a nivel de diseño.

Cohesion, coupling & abstraction – Tim Ottinger & Jeff Langr (PragProg magazine)

La idea básica de OOP es que las clases son tipos de datos abstractos personalizados.

Prácticas

Refactoring: improving the design of existent code, Martin Fowler [1999]

Libro de referencia cuando se busca cómo cambiar el diseño.

Test-Driven development: by example, Kent Beck [2003]

Introducción ligera a TDD. Complementario a estos podcasts.

Patrones

Design Patterns:  Elements of Reusable Object-Oriented Software, Gang of Four [1995]

Tódolos programadores a nivel global han crecido con este vocabulario.

Patterns of entreprise application architecture, Martin Fowler [2003]

Libro de referencia para buscar inspiración en los momentos de diseño up-front.

Entreprise Integration Patterns, Gregor Hope & Bobby Woolf [2004]

Libro de referencia sobre cómo diseñar la comunicación entre sistemas.

Don’t make me think, Steve Krug [2006]

Aunque enfocado en usabilidad web, es altamente recomendado para cualquier programador que trabaje con interfaces de usuario.

Aprender de la experiencia de otros

Who killed the Virtual Case File, Harry Goldstein [2005]

Un fracaso famoso, el Virtual Case File, aplicación de gestión de expedientes del FBI. «Lesson #1 of IT project management: faster, cheaper, better. Pick two, but you can´t have all three

An agile approach to a legacy system, Chris Stevenson & Andy Pols (ThoughtWorks)

Cuenta la historia de cómo un pequeño equipo, siguiendo las directrices XP, reescribió un sistema antiguo y devolvió la fé en los programadores.

Keep your crisis small (y resumen), Ed Catmull (presidente de Pixar) [2007]

El proceso detrás del desarrollo de Toy Story.

Lean from the trenches, Henrik Kniberg [2011]

Cómo se construyó el PUST “Polisens mobila Utrednings Stöd”, una aplicación de ámbito nacional para la policía sueca.

How tripadvisor organized their work, Andy Gelfond [2011]

Cómo trabajan en TripAdvidor.

Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds (PDF), Henrik Kniberg & Anders Ivarsson [2012]

Cómo trabajan en Spotify.

The year without pants, WordPress.com and the future of work, (página del libro) Scott Berkun [2013].

Cómo Automattic -la compañía detrás de WordPress- organiza su día a día. Es una poco habitual experiencia de «periodismo embebido». Obligatorio si estás interesado en cómo el teletrabajo y la autogestión pueden funcionar juntos.