Los programadores por naturaleza afrontamos muy mal aquellas tareas que más nos cuestan y casi siempre comenzamos por las que más nos gustan o aquellas que más nos apetecen en el momento, esto es así porque tenemos la opción de elegir qué hacer de entre todo el trabajo que tenemos por delante.

Un desarrollador neófito o júnior comienza siempre por lo divertido, mientras que un programador profesional elige siempre en primer lugar lo más difícil o aquello que le causa especial incertidumbre. Las consecuencias de esta elección son evidentes.

El primero comienza el trabajo divirtiéndose en aquello que más le apetece, pero sin darse cuenta de que va a ir acumulando tareas y problemas para más adelante sin sospechar que estos siempre van en aumento: al final se verá agobiado y lo que es más difícil de resolver terminará por hacerlo rápido (y seguramente mal).

No obstante, el profesional sabe que esto es así, de modo que lo primero que evita es que los problemas se acumulen a medida que se termina el tiempo estimado para realizar el trabajo: por esa razón afronta siempre lo más difícil o aquello que aún no sabe bien cómo resolver al principio del sprint o la fase de trabajo.

Esta es una cualidad más del desarrollador profesional: la experiencia le ha mostrado que nunca es buena idea dejar para el final la incertidumbre; si esta se elimina justo al principio se afrontarán el resto de tareas de una manera mucho más tranquila y relajada, estados mentales imprescindibles para realizar un desarrollo de calidad.

Por lo menos a mí me pasa, no puedo trabajar con un mínimo de tranquilidad si tengo ese ronroneo mental continuo con aquello que aún no sé cómo hacer o esa otra parte del trabajo que todavía no tengo ni idea de cómo voy a resolver.

"Un buen desarrollador siempre busca trabajar con tranquilidad; para ello, la incertidumbre hay que eliminarla al comienzo, no dejarla para el final"

Cualquier proyecto software comienza cargado de problemas e incertidumbres, se desarrolla con problemas e incertidumbres y se entrega con... pues eso.

Cuando programamos estamos resolviendo problemas, al menos algunos de los que conocemos y nos agobiamos precisamente por aquellos que desconocemos.

Todo sería un poquito más fácil si asumiéramos que cualquier proyecto software tiene en su naturaleza tres verdades que al conocerlas bien nos pueden hacer nuestro trabajo más asumible y cómodo. Son las siguientes.

No hay ningún proyecto software que recoja completamente los requisitos al principio.

Nos han enseñando que como primera parte de un proyecto se debe afrontar una toma de requisitos. Esto en sí mismo ya es un tema de estudio profundo y empresarialmente un tema que casi siempre comienza mal: en ocasiones quienes recogen esos requisitos no poseen las competencias necesarias para trasladarlos al papel para que sean entendibles por el equipo que implementa el proyecto; en otras quien se encarga de esta tarea no está comprometido con el proyecto, por lo que le da igual especificar bien, cuando no pocas veces entender lo que el cliente quiere es más un tema de psicología que de tecnología.

En cualquier caso, por una razón u otra la realidad es que recibir requisitos completos es una utopía y cuanto antes aprehendamos esto nuestro trabajo podrá ser enfocado con un mayor grado de flexibilidad. No entramos aquí en técnicas ágiles que afrontan esta laguna inicial con reconsideraciones continuas del catálogo de requisitos, lo cual es la manera correcta de enfocar el problema, pero en muchos casos el contexto laboral te impide poner en práctica una metodología ágil.

Por muchos requisitos que se haya conseguido obtener al principio, éstos cambiarán con total seguridad.

No podemos basar completamente las decisiones de diseño que se toman e implementan en requerimientos iniciales: cualquier proyecto software va a ver modificado lo que se espera de él con el tiempo. En cuantas ocasiones he vivido eso por parte de un cliente igual que los "pues ya que...", sin entender las consecuencias desastrosas que puede tener para la solución software el esperar que un vehículo de cuatro ruedas ahora tenga que volar...

Sólo si aceptamos que en cierta medida nuestro software se debe adaptar a cambios entonces programaremos con un enfoque más abierto: modularizaremos mejor, desacoplaremos bien las partes funcionales del producto, nos esforzaremos mejor por hacer clean code, permitiremos un alto grado de configuración y particularización, etc.; sólo podremos hacer esto si nos inculcamos el hábito de programar para el cambio.

Cualquier software que no permita evolucionar ni ser modificado se tirará a la basura más pronto que tarde.

Siempre habrá muchas más cosas que hacer de las que nos permite el tiempo y el dinero.

A medida que avanzamos en la ejecución del proyecto las posibilidades de desarrollo, mejora e ideas se irán abriendo y ampliando en forma de árbol: exponencialmente.

Tenemos que asumir que siempre vamos a tener más cosas de las que realmente podemos afrontar y hacer. Si aceptamos que esto es así entonces podremos priorizar mejor y determinar qué es lo importante para el proyecto y qué lo accesorio, nos evitará divagar entre tareas sin terminar sin cerrar niguna al 100% y nos evitará ir dejando una technical debt que nos pase factura meses más tarde.

Simple pero efectivo: tres verdades sencillas de entender pero que tantas veces he visto totalmente incomprendidas en muchos de los proyectos que he participado.

Fuente (aparte del sentido común), el valiosísimo libro de Jonathan Rasmusson The Agile Samurai: How Agile Masters Deliver Great Software.

Las reglas para desarrollar buen software son en ocasiones de un total sentido común y están al alcance casi de cualquiera que se proponga realizar su trabajo en condiciones.

No hace mucho re-descubrí un conjunto de sencillas preguntas que nos dicen si tenemos un buen equipo de trabajo y trabajamos desarrollando software con un mínimo de calidad: es el test de Joel que resumo a continuación y que no es más que sentido común aplicado a nuestra actividad diaria:

  1. ¿Usas un repositorio de código?
  2. ¿Puedes realizar la compilación de tu aplicación en un único paso?
  3. ¿Realizas compilaciones diarias?
  4. ¿Trabajas con una lista o herramienta de gestión de errores?
  5. ¿Corrijes errores pendientes antes de escribir nuevo código?
  6. ¿Trabajas con una planificación actualizada?
  7. ¿Tienes una especificación de lo que tienes que hacer?
  8. ¿Tienes lo programadores unas condiciones de trabajo convenientes?
  9. ¿Usas las mejores herramientas que te puedas permitir con tu presupuesto?
  10. ¿Tienes testers en el equipo o, en su defecto, existe al menos tal rol?
  11. En las entrevistas de nuevos candidatos, ¿escriben código?
  12. ¿Compruebas la usabilidad del código que desarrollas con la opinión de otros desarrolladores?

Lo ideal, según el autor de este sencillo test, es responder a todo con un SÍ, pero si respondemos a diez o menos de estas preguntas afirmativamente, entonces tenemos serios problemas en nuestra manera de enfocar el desarrollo de software.

Podemos cumplir más o menos con la lista de preguntas del test o la podemos cumplir horriblemente mal, y, al mismo tiempo, podemos entregar una aplicación que funciona, nuestro jefe estará contento y seguramente nuestro cliente también, pero... ¿a qué coste?. ¿Cuánto tiempo habremos perdido resolviendo compilaciones rotas?, ¿cuánto tiempo habremos dedicado a resolver este error que surgió hace dos semanas?, ¿será nuestro código mantenible cuando el mismo cliente nos pida nueva funcionalidad?, ¿podremos recuperar la versión X de una clase porque hemos introducido cambios desastrosos?, ¿trabajamos eficientemente sin una mínima planificación?, ¿sabemos exactamente qué hay que hacer si no existe una especificación clara?. ¿Somos productivos si no tenemos un entorno de trabajo productivo?.

La mayoría de estas cuestiones las deben resolver y responder los responsables, coordinadores y jefes de los desarrolladores y no éstos, aunque sí es fundamental que los mismos programadores alerten de estas carencias a sus responsables de equipo.

A las preguntas del clásico test de Joel, yo añadiría además las siguientes:

  1. ¿Está el código suficientemente respaldado por pruebas?
  2. ¿Existe una correcta gestión de la configuración?
  3. ¿Se sigue algún tipo de metodología?
  4. ¿Se esfuerza el equipo por simplificar y mejorar continuamente la estructura y el diseño de la aplicación?
  5. ¿Es el código que se desarrolla suficientemente simple?
  6. ¿Es bajo el esfuerzo que tendría que hacer un nuevo miembro del equipo para realizar código nuevo de producción?

¡Hola a tod@s!

Hoy es un día importante porque esta web queda publicada; la edición de este libro es un proyecto personal que comencé en el verano de 2012.

Ahora sí. En aquellos meses, y dado que desde hace mucho me gusta escribir y reflexionar sobre ciertos temas que afectan a nuestra profesión, me pregunté ¿y por qué no pongo todo esto en un libro que pueda compartir con la gente?.

Así nació esta idea y así se está desarrollando; aunque mucho de los capítulos y apartados del libro los tengo escritos desde hace mucho, con esta web quiero compartirlos y darles una forma más o menos definitiva antes de su publicación.

Pero, ¿de qué trata el libro?

Páginas

Mis libros en todas las tiendas:

Amazon
Google Play
Apple
Kobo
Barnes and Noble
Scribd
Smashwords
Payhip
Gumroad

Rafael Gómez Blanes Rafael Gómez Blanes
¿Hablamos?

 

Trabajo en...

Archivo

Mis novelas...