Software Craftsmanship y profesionalismo

El término artesanía del software o bien software craftsmanship ha ido calando en nuestra industria desde el momento en que, en mil novecientos noventa y nueve se publicara el muy conocido The Pragmatic Programmer: From Journeyman to Master. En este muy interesante libro, se ahonda en la metáfora del programador como artesano en el momento de estudiar su evolución como profesional, de forma muy afín a como se efectuaba en los gremios medievales.

Movimientos siguientes como la publicación del Manifesto por la artesanía del sotware o bien referencias como Software Craftsmanship: The new imperative o bien The Software Craftsman: Professionalism, Pragmatism, Pride, han hecho que este movimiento medre y evolucione de forma continua, incrementando en buena medida el número de profesionales que se identifican con sus principios.

La metáfora del artesano

Para iniciar, debo decir que la metáfora puede resultar un tanto confusa, puesto que cuando charlamos de artesanía no nos referimos a que no sea esencial mecanizar y sistematizar los procesos que hacemos manualmente. En verdad, esta metáfora ha sido adoptada sobretodo por ciertos paralelismos clarísimos 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 por el momento!! Todo esto va sencillamente de hacer las cosas bien y de de qué manera hacerlas todavía mejor :)

¿Ciencia o bien arte?

Ya antes de comprender los principios de la artesanía del software, creo que es de vital relevancia dar contestación a esta pregunta. Para los artesanos del software la contestación está clara, el desarrollo de software es un arte que hay que cultivar (si bien nuestra industria se empeña en lo opuesto). En este sentido, cualquier producto software creado para aportar valor a un cliente del servicio con unas necesidades concretas, he de ser desarrollado a dicho efecto y siguiendo estos principios. Un producto que no se amolda al inconveniente, no aporta verdaderamente valor a los que lo terminan usando.

Como desarrolladores, ¿Es este el género de producto que deseamos generar? Comprendo que habitualmente la contestación es un definitivo NO, mas para lograrlo debemos contar con de las armas convenientes para no caer nuevamente en ese modelo a la primera de cambio. En este sentido, en los principios de la artesanía del software están las claves de como lograrlo. Veamos puesto que en los próximos apartados, qué principios se pueden derivar de la busca del profesionalismo.

Principios básicos

Para examinar estos principios, vamos a valernos del manifiesto de la artesanía del software que os comentaba previamente y, repasando cada uno de ellos de sus enunciados, examinaremos qué prácticas podemos empezar a interiorizar para transformarnos en verdades artesanos.

No solo software que marcha, sino más bien asimismo software bien diseñado

Uno de los conceptos que primero vienen a mi psique leyendo este primer punto, es el de economía del software. Y es que nuestro buen diseño, sobretodo en las unas partes de nuestro software que más impacto o bien más cambio reciben, es lo que nos deja continuar mejorando su estructura sin mudar su comportamiento perceptible. Esto desea decir continuar evolucionando nuestra base de código a través del refactoring, sosteniendo la linearidad del costo de cambio.

No debemos olvidar que si bien el software funcione, en todos y cada pequeño cambio tomamos resoluciones en un corto plazo que pueden condicionar la evolución del mismo en un largo plazo. Muchas de ellas son una consecuencia de los tiempos de entrega o bien de la carencia de información, con lo que no siempre y en todo momento son las más convenientes. En esta situación, estas pequeñas resoluciones que marchan se transforman de manera rápida en deuda técnica.

Hay bastante gente que considera que legacy code o bien código legado es el que escribimos el día de ayer, en tanto que de ahora en adelante debemos sostenerlo, evolucionarlo y liberarlo de la deuda técnica adquirida con técnicas como testing, refactoring o bien cambio paralelamente. En este ciclo progresivo de evolución y mantenimiento, siempre y en todo momento podemos atender a una incesante simple y clara, y es que las necesidades de negocio marcan el ritmo. Es precisamente por esto que invertir en estas unas partes de nuestro sistema nos va a reportar un valor claro a largo plazo, permitiéndonos evolucionar cara un sistema bien desarrollado que absorba mejor el cambio y que nos aporte flexibilidad y contestación al cambio.

No solo contestar al cambio, sino más bien asimismo añadir valor constantemente

Evidentemente, y siguiendo con lo que comentábamos en el apartado precedente, podemos lograr estar dando contestación al cambio de una manera eficaz a través de un buen diseño de nuestro software y no estar aportando valor a nuestro usuario. Mas … ¿De qué manera puede ser esto?

Supongamos que en el producto que estamos desarrollando, deseamos poder conocer el flujo de pedidos de un cliente del servicio. En muchos sistemas, esto puede ser ofrecido mediante un formulario para la ejecución de informes en el que puedo filtrar por prácticamente todo cuanto se guarda en la base de datos y acabo sacando un PDF con la lista de los últimos pedidos de un cliente del servicio específico. No semeja un escenario rarísimo para cualquier software de administración, ¿no? Mas realmente, ¿estamos aportando todo el valor posible a nuestro usuario con esta solución? Muy seguramente no …

Quizás en estos casos, el planteamiento debería pasar preguntarnos qué género de perfil en la aplicación precisa explotar esta información con el objetivo de proveerle de una interfaz más reducido mas amoldado a sus necesidades, de manera que como resultado pueda conseguir una gráfica de evolución del flujo de pedidos del cliente del servicio al lado de otros productos relacionados que otros clientes del servicio han adquirido cuando adquirían exactamente el mismo producto que ha adquirido nuestro usuario (quizás le resulte de interés si se lo ofrezco la próxima vez que adquiera ese producto). El enfoque es un tanto diferente y pasa siempre y en todo momento por diseñar soluciones para flujos específicos y perfiles específicos en nuestro sistema y no para administrativos que solo introducen y consultan datos sin valor auxiliar que la propia persistencia de exactamente los mismos.

¿Nuestro producto soluciona un inconveniente específico o bien se semeja más a un Microsoft Access?

No os dejéis mentir por la apariencia de los formularios de esta atrapa. 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 cuatro y GraphQL podemos hallar muchas veces estos patrones cuando no razonamos sobre la solución en concepto de simplicidad o bien de sencillez de empleo para los diferentes perfiles de usuario.

No solo individuos y también interactúes, sino más bien asimismo una comunidad de profesionales

Vale vale, ya identifico la necesidad de evolucionar mi producto basándonos en un buen diseño del software y deseo aportar valor con cada nueva funcionalidad que desarrollo, Mas entonces, ¿De qué forma aprendo todo lo preciso para lograrlo? ¿De qué forma me transformo en un auténtico profesional del desarrollo del software?

Una enorme pregunta indudablemente y un camino largo que recorrer. En mi entender, el paso inicial habría de ser aprender a aprender, así voy a poder lograr sacar el máximo partido al paso que dedique a mi aprendizaje.

El segundo indudablemente es descubrir la potencialidad del aprendizaje colaborativo o bien en conjunto. Tenemos el privilegio de ser una de las pocas profesiones que ha interiorizado el término de comunidad de desarrollo en la forma de relacionarnos y aprender en nuestro ambiente. Ya, con independencia de en la provincia en que radiques, hay decenas y decenas de comunidades locales que efectúan actividades que nos llevan a proseguir evolucionando y ser mejores profesionales: Coding Dojos, Hablas, Code Retreats, Hackatones, proyectos open source y mucho considerablemente más. En todo caso, si cerca de ti no suceden todas y cada una estas ideas, siempre y en todo momento tienes 2 opciones: Abrir tu conjunto local de cuanto quieras o bien proseguir aprendiendo on-line 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 conjunto es el de la DevScola, la escuela gratis de programación que tenemos en Valencia y en la que de año en año se amplía cada vez más y más la comunidad de nuevos desarrolladores que han crecido en un entorno donde hacer bien las cosas es la única razón de ser.

No solo cooperación de clientes del servicio, sino más bien asimismo asociaciones productivas

Si bien jueguen en otra liga, siempre y en toda circunstancia podemos ver de qué manera los grandes se prosiguen asociando para hacer cosas increíbles (FaceBook