Desde hace mucho tiempo me he preguntado continuamente cuál es el problema con la industria de software. Cualquiera que lleve un tiempo trabajando en ella sabe lo complicado que es, la cantidad de proyectos que no llegan nunca a nada y la cantidad exagerada de dinero y tiempo que es desperdiciada en ellos. Sinceramente, ha llegado a preocuparme la situación. He llegado a pensar, por ejemplo, que tarde o temprano las empresas en México se van a dar cuenta de lo incapaz que es la industria de software Mexicana de producir buen software y eventualmente van a dejar de contratar los servicios de desarrolladores mexicanos. Sin embargo, he concluido que dicha preocupación es infundada pues solo hace falta informarse un poco para darse cuenta que en todo el mundo sucede lo mismo. Así que realmente no tienen opciones.

Una y otra vez, veo el mismo escenario: arquitectos que no programan desde hace años; Managers que, como no son técnicos, realmente no tienen idea de que ocurre; expertos en procesos y metodologías que no saben como hacer las cosas pero que sí saben como hacerlas mejor; programadores inexpertos que cuestionan poco pero trabajan mucho y milagrosamente terminan logrando que el sistema “funcione”.

He visto, al mismo tiempo, gente con ganas de hacer las cosas bien, poniendo toda su fe en procesos de moda en la industria, trabajando para obtener certificaciones, etc. Pero nada parece funcionar. De vez en cuando y espontáneamente, sin embargo, hay destellos: Buenos equipos que realizan un excelente trabajo. Lo que no ocurre es que dichos equipos duren indefinidamente o que puedan ser recreados. Pareciera que de pronto aparece gente capaz pero que las empresas, en general, son incapaces de retenerla y muchas veces siquiera de identificarla.

Encuentro dos causas profundamente ligadas: Incompetencia y cultura.

1. Incompetencia. Parece ser demasiado obvio y fácil decir que el problema viene de la cantidad de gente incompetente en la industria. Lo que es interesante es discutir como es que los proyectos y las empresas de desarrollo se llenan de gente incompenente tan fácilmente, pero la razón es sencilla: programar es difícil. Es difícil pues requiere -continuamente- de mucho tiempo de práctica y estudio. Esto a la vez de que es vista como mano de obra y como tal casi nadie quiere permanecer mucho tiempo ahí. La mayoría de las personas que hoy programan en 10 años ya no lo harán, muchos estarán ocupando puestos administrativos o gerenciales, otros serán analistas de negocio y otros más simplemente habrán abandonado la industria. Como resultado, las empresas de desarrollo están llenas de personas que no saben de desarrollo.

2. Cultura. La industria ve a los proyectos de desarrollo como proyectos tradicionales: cree que es posible apegarse a un proceso o modelo de proyecto, implementar mejores prácticas, hacer a, b y c y obtener resultados con total control y predictibilidad. La industria se centra en el proceso, en la estructuración jerárquica del equipo y trata a los trabajadores como intercambiables, tal cuál como se hace en todos lados. Esta cultura falla fundamentalmente en dos puntos: 1. El desarrollo, incluso de sistemas simples, no es una labor monótona; es una actividad que requiere constantemente de buen juicio e inteligencia, por lo que no se le puede tratar simplemente como mano de obra ni se le puede hacer predecible y repetible únicamente a través de “procesos” o “buenas prácticas”. 2. Las personas que carecen de un buen nivel técnico activo, aportan un valor limitado a los proyectos: carecen de perspectiva para tomar decisiones importantes, las decisiones se deben llevar acabo aprovechando el conocimiento del equipo entero. Hay una, y solo una razón, por la cuál la industria no colapsa con esta cultura: el 70% de los proyectos son una versión de ABC (Altas, Bajas y Cambios) (y aún en estos casos los proyectos salen llenos de bugs, con problemas de seguridad, desempeño y retrasos).

No soy el único que ve esto así.

Recientemente me he estado encontrando cada vez más seguido dos ideas: “Hacker Centric Culture” (tienen que leer este ensayo de Paul Graham) y “Software craftmanship”. Las dos, en mi opinión, tienen la misma base aunque la “artesanía de software” es una propuesta con más forma (hasta tienen un manifiesto).

Ambas ideas tratan de darle importancia al buen desarrollador (i.e. Hacker). La artesanía de software ve a la formación de un programador como un proceso gradual de desarrollo de habilidades y adquisición de conocimientos; ve al desarrollo más como un arte emergente y menos como una ciencia exacta: Valora a la práctica como la mejor forma de aprender.

Ambas se centran en el hacker; en el practicante; en el “artesano”; y no en una ciencia o ingeniería que es capaz de dictar cómo hacer las cosas.

Desde mi punto de vista, este es el enfoque correcto. Y vale la pena darles forma e incluso firmar un manifiesto.

¿Y cómo podría la industria de desarrollo adoptar esta cultura? Simplemente concentrándose en identificar y retener a los buenos “artesanos” y dejar de ver a los desarrolladores como trabajadores intercambiables. Despues de todo, ya hay empresas que hacen esto. Paul Graham nos nombra algunas: Microsoft, Google, Facebook.

El problema es que la mayoría de las empresas de desarrollo necesitan de esta cultura solo para dejar de ser mediocres pero no para sobrevivir. Y por lo tanto no tenemos garantía de que eso algún día suceda…