Herman Miller y el desarrollo de software

Cuando se trata de personas, todo tiene que ver con ergonomía. Como dice Peter Morville en su libro “Ambient Findability, la posición de un botón en una máquina, la imagen de una señal de tráfico, la silla Herman Miller que le resolvió su problema de dolor de espalda, todo lo que usamos, todo lo que nos permite trabajar debe ser cómodo, debe ser fácil, debe ser práctico y finalmente, debe ser productivo.

En estos días hemos estado trabajando en un rescate de un proyecto de desarrollo de software. Los rescates son una de esas cosas que no deberían existir, pero que parecen inherentes al medio profesional de los sistemas de información.

Me imagino que hay rescates de todo tipo, pero tengo la creencia de que la gran mayoría tienen su origen en una falta de buenas prácticas y un exceso de malas prácticas.

Existen buenas prácticas que podríamos llamar “sofisticadas” o “exquisitas”, como el uso de metodologías como XP y RUP, el uso de diagramas UML, las métricas de código, etc. De estas hablan muchos libros y muchos blogs, pero todos damos por sentado que las prácticas más básicas están allí de respaldo, esta creencia es tan ingenua como la que tiene un niño en Santa Claus.

Las buenas prácticas elementales son a veces tan generales que son poco discutidas en los libros del tema. Muchas de ellas son aplicables a cualquier persona que trabaja en una oficina, que permanece sentado la mayor parte del tiempo frente a una computadora. Otras se aplican a todos los que trabajamos en entornos colaborativos. Lo cierto es que apenas se les menciona en los manuales de desarrollo de software.

Hoy no voy a hablar de cómo hacer casos de uso o de cómo usar un dashboard de desarrollo, de la integración continua y las pruebas de similitud de código. Hoy quiero reafirmar la importancia de las buenas prácticas más elementales del desarrollo de software.

El síntoma más claro de una mala administración en desarrollo es la ubicuidad de la urgencia. Cuando todos los proyectos urgen, cuando todas las actividades son “para ayer”, las cosas van mal, demasiado mal. En una situación así, la urgencia prioritaria es el replanteamiento gerencial del área, la revisión e implementación de buenas prácticas en toda la organización.

Una vez que nos hemos dado cuenta de la necesidad de una revisión integral de nuestras prácticas, comienza la hora de aplicar las recetas más básicas. Aquí las cosas son aparentemente fáciles, sólo hay que hacer las cosas respecto al libro:

Las sillas y mobiliario. Los desarrolladores realizamos nuestro trabajo la mayor parte del tiempo sentados. Una silla en mal estado no sólo es incómoda, es CANSADA, incluso puede producir problemas lumbares. A pesar del título del post, no pretendo que todos los programadores tengan sillas Herman Miller, pero sí sillas de buena calidad, ergonómicas. El cansancio siempre reduce la productividad. El resto del mobiliario debe apegarse lo más posible a este principio.

Los equipos. Eso de que los altos ejecutivos anden con laptops que podrían correr los últimos videojuegos y que sólo usan para ver su correo, chatear y posiblemente jugar, va bien; pero que los desarrolladores trabajen en computadoras que tardan más en abrir el block de notas de lo que el boiler de mi abuela tarda en calentar el agua… No se trata de que el equipo de desarrollo tenga computadoras que cuesten más que un auto, pero sí que tengan equipos que les permitan realizar su trabajo sin interrupciones innecesarias, sin complicaciones, cómodamente. Nuevamente se trata de una cuestión de ergonomía.

Las licencias. Una cosa es que todo el mundo hable bien o mal de la piratería y otra que no se paguen las licencias del software más elemental. En el caso de los equipos que trabajan con Windows o Macintosh, el pago de licencias de los operativos es obligatorio, y no es que me ponga de moralista con los derechos de autor, pero sí soy pragmático y prefiero contar con la opción de soporte técnico y actualizaciones que ofrecen las compañías de software. Si se trata de Linux, un buen plan de soporte no viene mal, cuando las cosas se ponen difíciles, un servicio técnico especializado nos puede ahorrar muchas horas perdidas.

Los entornos de desarrollo pueden ser otro problema de licencias, pero hay buenas opciones en el software libre como para hacer una obligación la compra de sistemas como el Microsoft Visual Studio. Sin embargo, al momento de la productividad, es importante contrastar la velocidad de desarrollo que se alcanza con entornos como el VS respecto a sus contrapartes gratuitas. En entornos Linux, las opciones OpenSource son las de elección, pero a veces una inversión extra en plugins para Eclipse puede ser una manera de mejorar la productividad.

El versionamiento. No debería haber un solo proyecto de software sin versionamiento de código. Lo repito: No debería haber un solo proyecto de software sin versionamiento de código. La elección de la tecnología de respaldo de código depende de cada organización. Hay de todos los sabores que usted quiera: OpenSource, gratuitos, con licencias por procesador, por persona, etc. El punto es que no se debe realizar un proyecto de desarrollo sin una herramienta que permita respaldar adecuadamente el código y los artefactos del proyecto.

Cumplir con estas mínimas prácticas está muy lejos del ideal, pero coloca al equipo en las condiciones indispensables para realizar su trabajo.

El siguiente paso, que considero también elemental, es la adopción de una metodología. No importa si se trata de RUP, XP o alguna tradicional. Lo importante es contar con una forma organizada de trabajar. La discusión sobre qué metodología se adecúa más a la organización en cuestión ya vendrá después, lo importante es no andar dando palos de ciego en todo momento.

Para contar con un buen compendio de buenas prácticas personales en el desarrollo de software recomiendo la lectura del libro The Pragmatic Programmer de Andrew Hunt y David Thomas. Se trata de un libro indispensable en el librero y en el bagaje de un desarrollador (es más importante leerlo que tenerlo guardadito, pero incluso sólo comprarlo ya es un buen comienzo).

Si se ha decidido por una metodología ágil le recomiendo darse una vuelta por el sito del Three River Institute dirigido por el mismísimo creador de la XP, Kent Beck. Si su elección es por lado más protocolario, una mirada a Rational en IBM le puede dar muchas ideas. Como bono adicional, le recomiendo el blog de Iván Garcerant dedicado principalmente a los artefactos RUP.

El motivo principal de existencia del software es mejorar la productividad de otras áreas de negocios, automatizar procesos, mejorar la predictibilidad, garantizar el monitoreo continuo. Todo esto se puede y se debe aplicar también al desarrollo del software. No se trata sólo de predicar con el ejemplo, sino de mejorar la productividad global de la organización.

4 thoughts on “Herman Miller y el desarrollo de software

  1. Te pasaste, me habria gustado escribirlo, aun que empiezo a conocer las metodologias, lo comparto casi al 100%.

  2. Esta muy bueno… y es todo cierto.. estoy hace tiempo en dando vueltas sobre metodologia.. No me decido por ninguno.. me gustaria contactar contigo.. Lo voy a poner en practica..

  3. Luís, de entrada, gracias por el comentario. Como ya habrás de suponer, me inclino mucho más por las metodologías ágiles, pero no todo es un clavo y no siempre sirve el martillo. O sea, a veces un equipo se adapta mejor a metodologías más protocolarias como RUP. Con gusto me pongo en contacto contigo.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s