El término artesanía del software o software craftsmanship ha ido calando en nuestra industria desde que, en 1999 se publicara el archiconocido The Pragmatic Programmer: From Journeyman to Master. En este interesantísimo libro, se profundiza en la metáfora del programador como artesano a la hora de estudiar su evolución como profesional, de manera muy similar a como se realizaba en los gremios medievales.
Movimientos posteriores como la publicación del Manifesto por la artesanía del sotware o referencias como Software Craftsmanship: The new imperative o The Software Craftsman: Professionalism, Pragmatism, Pride, han hecho que este movimiento crezca y evolucione de forma continua, aumentando en gran medida el número de profesionales que se identifican con sus principios.
La metáfora del artesano
Para empezar, debo decir que la metáfora puede resultar un poco confusa, ya que cuando hablamos de artesanía no nos estamos refiriendo a que no sea importante automatizar y sistematizar los procesos que hacemos manualmente. De hecho, esta metáfora ha sido adoptada sobretodo por algunos paralelismos muy claros que existen entre principios de calidad y excelencia que rigen el trabajo artesanal y su equivalente en el desarrollo de software. Podéis guardar vuestro formones de momento!! Todo esto va simplemente de hacer las cosas bien y de cómo hacerlas aún mejor :)
¿Ciencia o arte?
Antes de entender los principios de la artesanía del software, creo que es de vital importancia dar respuesta a esta pregunta. Para los artesanos del software la respuesta está clara, el desarrollo de software es un arte que hay que cultivar (aunque nuestra industria se empeña en lo contrario). En este sentido, cualquier producto software creado para aportar valor a un cliente con unas necesidades específicas, debe ser diseñado a tal efecto y siguiendo estos principios. Un producto que no se adapta al problema, no aporta realmente valor a los que lo acaban utilizando.
Como desarrolladores, ¿Es este el tipo de producto que queremos producir? Entiendo que en muchos casos la respuesta es un rotundo NO, pero para conseguirlo debemos disponer de las armas adecuadas para no caer de nuevo en ese modelo a las primeras de cambio. En este sentido, en los principios de la artesanía del software están las claves de como conseguirlo. Veamos pues en los siguientes apartados, qué principios se pueden derivar de la búsqueda del profesionalismo.
Principios básicos
Para examinar estos principios, vamos a valernos del manifiesto de la artesanía del software que os comentaba anteriormente y, repasando cada uno de sus enunciados, examinaremos qué prácticas podemos comenzar a interiorizar para convertirnos en verdades artesanos.
No sólo software que funciona, sino también software bien diseñado
Uno de los conceptos que primero vienen a mi mente leyendo este primer punto, es el de economía del software. Y es que nuestro buen diseño, sobretodo en las partes de nuestro software que más impacto o más cambio reciben, es lo que nos permite seguir mejorando su estructura sin cambiar su comportamiento observable. Esto quiere decir seguir evolucionando nuestra base de código a través del refactoring, manteniendo la linearidad del coste de cambio.
No debemos olvidar que aunque el software funcione, en cada pequeño cambio tomamos decisiones a corto plazo que pueden condicionar la evolución del mismo a largo plazo. Muchas de ellas son una consecuencia de los tiempos de entrega o de la falta de información, por lo que no siempre son las más adecuadas. En esta situación, estas pequeñas decisiones que funcionan se convierten rápidamente en deuda técnica.
Hay mucha gente que opina que legacy code o código legado es el que escribimos ayer, ya que a partir de ahora debemos mantenerlo, evolucionarlo y liberarlo de la deuda técnica adquirida con técnicas como testing, refactoring o cambio en paralelo. En este ciclo continuo de evolución y mantenimiento, siempre podemos atender a una constante simple y clara, y es que las necesidades de negocio marcan el ritmo. Es por esto que invertir en estas partes de nuestro sistema nos va a reportar un valor claro en el largo plazo, permitiéndonos evolucionar hacia un sistema bien diseñado que absorba mejor el cambio y que nos aporte flexibilidad y respuesta al cambio.
No sólo responder al cambio, sino también agregar valor constantemente
Por supuesto, y siguiendo con lo que comentábamos en el apartado anterior, podemos conseguir estar dando respuesta al cambio de una forma efectiva mediante un buen diseño de nuestro software y no estar aportando valor a nuestro cliente. Pero ... ¿Cómo puede ser esto?
Imaginemos que en el producto que estamos desarrollando, queremos poder conocer el flujo de pedidos de un cliente. En muchos sistemas, esto puede ser ofrecido a través de un formulario para la ejecución de informes en el que puedo filtrar por casi todo lo que se almacena en la base de datos y acabo sacando un PDF con la lista de los últimos pedidos de un cliente concreto. No parece un escenario muy raro para cualquier software de gestión, ¿no? Pero en realidad, ¿estamos aportando todo el valor posible a nuestro usuario con esta solución? Muy probablemente no ...
Quizá en estos casos, el planteamiento debería pasar preguntarnos qué tipo de perfil en la aplicación necesita explotar esta información con el fin de proveerle de un interfaz más reducido pero adaptado a sus necesidades, de forma que como resultado pueda obtener una gráfica de evolución del flujo de pedidos del cliente junto a otros productos relacionados que otros clientes han adquirido cuando compraban el mismo producto que ha adquirido nuestro cliente (quizá le resulte de interés si se lo ofrezco la próxima vez que compre ese producto). El enfoque es un poco distinto y pasa siempre por diseñar soluciones para flujos concretos y perfiles concretos dentro de nuestro sistema y no para administrativos que sólo insertan y consultan datos sin ningún valor adicional que la propia persistencia de los mismos.
¿Nuestro producto resuelve un problema concreto o se asemeja más a un Microsoft Access?
No os dejéis engañar por la apariencia de los formularios de esta captura. Este modelo no es exclusivo de los ERP ni de las aplicaciones viejunas cliente/servidor. En las aplicaciones más hipster y molonas desarrolladas con Angular 4 y GraphQL podemos encontrar en muchas ocasiones estos mismos patrones cuando no razonamos sobre la solución en términos de simplicidad o de facilidad de uso para los distintos perfiles de usuario.
No sólo individuos e interacciones, sino también una comunidad de profesionales
Vale vale, ya identifico la necesidad de evolucionar mi producto en base a un buen diseño del software y quiero aportar valor con cada nueva funcionalidad que desarrollo, Pero entonces, ¿Cómo aprendo todo lo necesario para conseguirlo? ¿Cómo me convierto en un verdadero profesional del desarrollo del software?
Una gran pregunta sin duda y un camino largo que recorrer. En mi opinión, el primer paso debería ser aprender a aprender, de esta forma podré conseguir sacar el máximo partido al tiempo que dedique a mi aprendizaje.
El segundo sin duda es descubrir la potencialidad del aprendizaje colaborativo o en grupo. Tenemos el privilegio de ser una de las pocas profesiones que ha interiorizado el concepto de comunidad de desarrollo en la manera de relacionarnos y aprender en nuestro entorno. Ahora mismo, independientemente de en la provincia en que residas, hay decenas de comunidades locales que realizan actividades que nos llevan a seguir evolucionando y ser mejores profesionales: Coding Dojos, Charlas, Code Retreats, Hackatones, proyectos open source y mucho mucho más. En cualquier caso, si cerca de ti no suceden todas estas iniciativas, siempre tienes dos opciones: Abrir tu propio grupo local de lo que quieras o seguir aprendiendo online con el material infinito de que disponemos. La única premisa es compartir para aprender.
El ejemplo más paradigmático que conozco de aprendizaje en grupo es el de la DevScola, la escuela gratuita de programación que tenemos en Valencia y en la que cada año se amplía más y más la comunidad de nuevos desarrolladores que han crecido en un ambiente donde hacer bien las cosas es la única razón de ser.
No sólo colaboración de clientes, sino también asociaciones productivas
Aunque jueguen en otra liga, siempre podemos ver cómo los grandes se siguen asociando para hacer cosas increíbles (FaceBook & Instagram = React). A nuestra escala, cada vez que vamos a una conferencia y haciendo networking hablamos con otros profesionales del sector, estamos aprendiendo y mejorando como profesionales. Si no levantas la cabeza del teclado y sólo piensas en tu producto y en tu entorno, quizá es el momento de abrir miras y ver cómo otros están solucionando los mismos desafíos técnicos a los que tú te enfrentas. Conviertete en speaker, da una charla de cómo hacéis las cosas en tu equipo, recibe feedback y mejora tu proceso/producto. Vete de Desk Surfing a trabajar con otros durante dos semanas y aprende y aporta todo lo que puedas.
Simplemente, no dejes de moverte :)
Conclusión
Ante todo, la artesanía del software es una actitud. Es una manera de plantear tu carrera profesional y de vivirla en el día a día. Es una nueva forma de trabajar en la que a partir de ahora reflexionaremos más sobre el cómo, sobre las ceremonias, sobre la cultura que cultivamos en nuestra profesión y de nuestras relaciones con el resto de profesionales.
Yo llevo intentando caminar esta senda desde que un buen día aparecí por primera vez en una reunión de Agile Levante en la que éramos cuatro personas. Mucho ha llovido desde entonces y mucho he aprendido. En definitiva, lo que más me motiva cada día de esta profesión es lo mucho que me queda por aprender y la suerte que tengo por pertenecer a una comunidad de desarrollo tan sana y que comparte unos valores tan potentes.
