Hace poco la bonilista trataba sobre el coste de las herramientas desarrollo y quién debe asumirlo y, como era de esperar, generó un entretenido debate en twitter con argumentos en un sentido u otro.

Que hay que pagar por las herramientas que usamos es algo que nadie discute, al menos públicamente. Otra cosa es lo que ocurre realmente, que esto es España y ya sabemos como funciona: cuando el político roba nos escandalizamos, pero si podemos “ahorrarnos” pagar la seguridad social de la asistenta, mejor.

Donde discrepo más en el coste de esas herramientas deba asumirlas cada uno y no la empresa que le contrata, o que el modelo de suscripción sea un avance (una oportunidad como lo define David) frente al modelo de licencias tradicional.

Con respecto a quién debe pagar las herramientas, todos hemos oído alguna vez el argumento de que muchos profesionales se costean sus propias herramientas.

Es verdad, un buen amigo mío es carpintero (y muy bueno, por cierto) y siempre se ha preocupado de tener su herramienta de calidad, sin depender de lo que le pudieran proporcionar en su empresa. Sin embargo, no creo que eso sea tan extrapolable a otras profesiones. Sí, es cierto que un carpintero tiene sus propias herramientas, pero también es cierto que un policía debe llevar el uniforme y la pistola reglamentaria, no puede llevar su propio chandal y un AK47, sólo porque así es más productivo.

¿En qué posición nos encontramos los desarrolladores?

Más que plantearse quién paga por las herramientas, habría que empezar por plantearse si es bueno que cada desarrollador elija sus herramientas.

A priori, podría parecer que sí. A fin de cuentas, si algo me hace más productivo, por qué no usarlo. Nadie en su sano juicio querría tener desarrolladores menos productivos.

El problema es que no todas las herramientas son iguales.

Hay herramientas que funcionan de forma muy aislada y autónoma, y hay herramientas que condicionan la forma de trabajar.

Por ejemplo, que cada uno elija el cliente de correo que quiera, no parece que sea muy grave y si quiero usar Mail Pilot en lugar del webmail de turno, no condiciono a nadie más.

Lo mismo pasa si quiero usar un editor de texto y prefiero vim o emacs o sublime. Cada uno es diferente, pero probablemente el resto del mundo ni siquiera se entere de qué tipo de editor estoy usando (bueno, mentira porque si estoy usando vim o emacs seguro que me encargaré de repetirlo un millón de veces para que todo el mundo lo sepa).

Otras herramientas son mucho más invasivas, y no es algo que deba elegir un desarrollador de forma independiente. Un caso extremo sería un sistema de control de código fuente: si yo quiero usar Perforce porque soy muy productivo con él, estoy imponiendo al resto del equipo que lo usen.

Tampoco hace falta irse tan lejos, incluso herramientas más “inofensivas” acaban condicionando el desarrollo. Una suite de controles para aplicaciones web, un motor de informes, un generador de código para capa de acceso a datos… Son cosas que te hacen más productivo, pero que acoplan tu desarrollo a las herramientas.

Con todo este tipo de herramientas ya no es tan razonable la idea de llegar como un mercenario de élite, con tu lanzagranadas licencia de lo que sea debajo del brazo y decir «voy a usar esto que me hace más productivo». Porque afecta a todo el equipo y la decisión corresponde a todo el equipo.

Lo importante es la productividad global del equipo, no la de un desarrollador individual. Un ejemplo claro lo tenemos a la hora de elegir una de las herramientas más importantes: el lenguaje de programación. De nada sirve que un desarrollador sea ultraproductivo con Scheme si para el resto del equipo es un lastre.

Desde esa perspectiva, decidir qué herramientas utilizar debería ser algo consensuado por el equipo de desarrollo, ya que cuando un buen día desaparezcas de allí, alguien tendrá que seguir modificando el script de compilación que hiciste con tu (perfectamente licenciada y pagada por ti) copia de FinalBuilder, almacenado en un formato propietario y que sólo puede modificarse con esa herramienta.

Si me pongo en la piel de “la empresa” y pienso en la continuidad del proyecto (y más si se trata de un producto) por encima de las personas que están actualmente trabajando en él, la decisión de las herramientas a emplear se convierte en algo estratégico, y veo razonable que el coste de esas herramientas recaiga recaiga sobre la empresa.

Esto no implica que uno no pueda pagar por sus propias herramientas, o al menos por algunas de ellas. Igual que es frecuente pagarte el transporte hasta la empresa o el teléfono móvil en el que de vez en cuando recibes un correo o consultas stackoverflow para temas laborales, que tengas tu licencia de X y quieras usarla me parece estupendo y admirable, pero personalmente nunca decidiré contratar o dejar de contratar a alguien en función de las herramientas que se haya comprado, y trataré de proporcionarle las mejores herramientas para el proyecto que tenga que realizar, pensando, insisto, en la productividad global del equipo.

Un caso diferente es el de los desarrolladores freelances autónomos que trabajan para distintos clientes los cuales, en general, no tienen nada que ver con la tecnología. Si voy a desarrollar una aplicación de control de calidad para una empresa de viveros, no parece muy normal que les exija pagarme una suscripción a la MSDN. Ahí sí veo más sentido a la analogía con el carpintero, pero es que en ese caso no sólo soy el carpintero, soy la empresa completa.

Que nadie me malinterprete, no estoy diciendo que debamos trabajar con herramientas obsoletas o renunciar a todo aquello que nos pueda hacer más productivos, pero cuando se trabaja en equipo hay decisiones que deben ser consensuadas. Una vez que el equipo (en el que no se incluye sólo la parte técnica) decide usar una herramienta, desde mi punto de vista lo lógico es que sea la empresa quien te la proporcione y quien posea la herramienta para poder dar continuidad al desarrollo más allá de los desarrolladores actuales.

Al final, el tema subyacente, al menos desde el punto de vista de empresa, es una cuestión de dependencia. De decidir qué dependencias se van a asumir y los riesgos que implican. Dejar en manos de cada desarrollador elegir sus propias herramientas hace que se pierda cierto control sobre el futuro del proyecto y que arriesgarse a tener que mantener un proyecto que depende de herramientas que no poseemos o que no conocemos lo suficiente.

Es un problema similar al que ocurre con las herramientas que usan un modelo de suscripción o pago por servicio. Más allá de que conlleven un incremento o una reducción de costes, suponen un cambio importante en el tipo de dependencia.

Cuando adquieres una licencia de uso perpetua, la dependencia con el proveedor es mucho más débil. Puedes quedarte (y te quedarás) sin mantenimiento y sin actualizaciones, pero normalmente puedes alargar su vida útil mucho más allá de ese punto. Todos conocemos casos de herramientas antediluvianas que siguen en producción y cumplen con su trabajo sin problemas.

Si se trata de un modelo de pago por servicio, estás en manos del proveedor de la herramienta. Si decide cambiar las condiciones de servicio, modificar los precios, descontinuar la herramienta… te vas a ver afectado y no tienes mucho margen de maniobra.

Por eso, en general, si puedo elijo herramientas, por este orden: open source (no necesariamente gratis), con licencia perpetua y, en último recurso, con modelo de suscripción.

Reconozco que el tema de open source tiene un punto ingenuo porque no es fácil ser capaz de mantener todas las herramientas que utilizas, pero no deja de ser una posibilidad, o al menos abre la puerta a encontrar a alguien al que puedas pagar para hacerlo por ti.

El pago por servicio ayuda a rebajar los costes de entrada y hay escenarios en los que realmente es un modelo muy ventajoso para todos, pero también hay otros en los que supone unos riesgos que tal vez no merezca la pena asumir.

Centrar el debate en si los desarrolladores estamos dispuestos o no a pagar 20 euros al mes por los productos de JetBrains es quedarse en la superficie del problema. No se trata de pagar 20 euros al mes, se trata de asumir una dependencia mucho más fuerte sobre una tercera empresa al pasar de “comprar” a “alquilar”.

Por cierto, excelente el ejemplo que ha dado JetBrains escuchando a sus usuarios y ofreciéndoles una alternativa más ajustada a sus peticiones.