Ingeniería vs Artesanía (de Software)

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…

6 comentarios en “Ingeniería vs Artesanía (de Software)

  1. Hola. Tengo casi 42 años. Empecé a programar con 14. Me dedico profesionalmente a esto desde los 20. Soy de esa generación que en España empezó con un spectrum y no fue a la universidad.
    Hace mucho tiempo, quizás más de 7 u 8 años que me considero un artesano del software. Fue una idea que se me ocurrió a mi solito, sin ninguna influencia externa. Siempre me resultan extremadamente curiosas las ideas que surgen en gente que están desconectados.

    Dicho de otra forma: suscribo vuestra opinión 100%.

    Me gusta

    • Gracias por tu comentario! Te puedo decir que a mi no se me ocurrió, pero en el momento en que leí de ello muchas cosas que no encontraba como asimilar hicieron sentido depronto: Siempre he visto como muchos tratan de introducir metodologías o procesos esperando que corrijan las cosas pero nunca sirven de mucho. Ahora puedo decir por qué: La programación es una práctica humana, no una ciencia que pueda ser enseñada con un libro. Dichas metodologías pueden servir, no lo descarto, pero se corre el peligro de crear la ilusion de que son una solución a los problemas en la industria de desarrollo.
      Casi todas las profesiones se pueden ver como teoría+aplicación y de aquí viene esta tendencia tan generalizada de querer ver a la programación así.

      Me gusta

  2. Creo que todos quieren moverse de programador a otro puesto porque ven que hay mejores salarios en esos puestos… el programador muchas veces esta infra-valorado en las empresas tanto por gente ajena a TI como por los mismos, es comuy oir que antiguos programadores q dicen… “pero ya no programo” de una manera como dando a entender que ya estan mejor que antes. La industria del software ha crecido en el ultimo siglo como ninguna otra, pero de una forma bastante desordenada…

    Me gusta

  3. Pues… en cuanto su faceta creadora coincido en que la programación se parece mucho a la artesanía. En cuanto al desarrollo de la habilidad técnica pienso que es más parecida a las artes marciales, sólo que la tecnología y los paradigmas evolucionan más rápidamente que éstas.

    Me gusta

  4. Pingback: Píldoras metodológicas para mentes ágiles y posmodernas « xmunch.com

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s