Bueno, a lo mejor el error está en las premisas de partida y confundimos las herramientas con los objetivos.
Nos creemos que nuestro objetivo es hacer TDD, ATDD, BDD, DDD, … porque algún fulano lo ha dicho en un libro, pero eso son meras herramientas que en cada caso, y en cada equipo, habrá que ver si nos interesa usar o no.
Nuestro verdadero objetivo es proporcionar el valor que quiere negocio, de forma rápida (o lo más rápida posible) y segura (libre de errores, porque sino tampoco sería rápida).
Fijaos que en la introducción en ningún sitio hablo de “calidad”. De hecho por lo pronto yo dejaría de hablar de “calidad” y desterraría esa palabra de nuestro vocabulario de desarrolladores porque ¿qué es “calidad”?
En sus dos primeras acepciones:
- Conjunto de propiedades inherentes a una cosa que permite caracterizarla y valorarla con respecto a las restantes de su especie: de buena calidad; de mala calidad; esta fruta es de una calidad excelente.
- Superioridad o excelencia de algo o de alguien.
Es decir la “calidad» sirve para compararme con otros, y el código no queremos compararlo con otros códigos (a no ser que tengamos un problema de ego y queramos ir fardando por los bares).
Yo empezaría a hablar de “mantenibilidad del código”, hacer “código mantenible”, “código que se puede mantener». Pero nuevamente ¿qué es “mantener”?.
Ponemos algunas de sus acepciones:
- Proporcionar el alimento o lo necesario para vivir.
- Hacer que una cosa continúe en determinado estado, situación o funcionamiento.
- Estar [una persona] durante un período de tiempo en determinada situación o realizando una acción o actividad.
“Mantener” queda claramente ligado a tener algo vivo durante el mayor tiempo posible. Y esta sí es una característica necesaria en el código, puesto que si llega un momento en que nuestro código “muere” dejaremos de cumplir el objetivo de aportar valor al negocio. Con lo que será el momento perfecto para que nos despidan y le den el proyecto a otros.
¿Es necesario hacer TDD, ATDD, BDD, DDD, … para que nuestro código sea “mantenible”? Efectivamente y NO. O por lo menos no es necesario usar todas las herramientas a la vez, todas las veces, y hasta su última consecuencia.
Todos esos acrónimos y palabros con los que se nos suele llenar la boca (ya estamos otra vez fardando en los bares) no son más que herramientas que no sirven para otra cosa que aportarnos «grados de confianza” sobre nuestro código (siempre grande @eferro).
Y de nuevo tiramos de diccionario ¿qué es “confianza”?
Su primera acepción nos viene al pelo:
- Esperanza firme que una persona tiene en que algo suceda, sea o funcione de una forma determinada, o en que otra persona actúe como ella desea.
Es decir nosotros como desarrolladores con cada incremento que hacemos en el código tenemos la esperanza firme de que todo siga funcionando y no se rompa nada. Es decir perseguimos el objetivo de seguir aportando valor al negocio.
De esta manera podríamos concluir que para aportar valor al negocio tendremos que usar sólo aquellas herramientas que en cada caso nos den la confianza suficiente para poder mantener vivo el código. Sin olvidar que el valor hay que aportarlo de forma rápida y segura.
Así que si alguna herramienta, aunque nos dé mucha confianza y seguridad, rompe con el requisito de “rápida” puede que no sea la mejor opción para esa situación y que tengamos que buscar otras herramientas que nos permitan ser más “rápidos» aportándonos la misma confianza.
Esto que estoy contando no es nada nuevo, por ejemplo llevamos años con la famosa “Pirámide de Tests”, donde los tests de Sistema o UI se colocan en la cima. Esto se debe a que, si bien son tests que nos aportan mucha confianza, son los más lentos de desarrollar y mantener (sí, los tests también tienen que ser “mantenibles”) y por lo tanto rompen el requisito de aportar valor de forma rápida, costándonos mucho dinerito tanto de forma directa, porque se tarda más en desarrollarlos, como de forma indirecta, porque al aportar valor al negocio de forma más lenta podemos estar perdiendo oportunidades de negocio.
Cómo yo no soy nadie, os dejo una referencia al siempre querido por todos Martin Fowler donde ya hablaba de esto en el 2012 (https://martinfowler.com/bliki/TestPyramid.html).
Conclusión
La “calidad” es una excusita que nos hemos inventado los técnicos para golpear a negocio y sentir que somos importantes y que nuestro trabajo es vital, sin querer entender que el negocio es lo realmente importante y que deberíamos gastar nuestro tiempo en entenderlo para poder aportarle el mayor valor posible de la forma más rápida posible.
Todo lo demás son simplemente problemas de autoestima ya que somos incapaces de aceptar que somos una mera herramienta para el negocio (si chiquitín, eres una llave inglesa) y que el día que encuentren una forma más barata o más rápida o más cómoda de hacer este trabajo, vamos todos a la calle.
Espero haber removido algunas conciencias, porque sólo está en al mano de cada uno el no confundir las herramientas con los objetivos.
Lo he tenido que leer dos veces porque no me podía creer lo que estaba leyendo.
Por favor, ya que mencionas a Martin Fowler, (que me parece muy bien) te dejo por aquí un link.
https://martinfowler.com/bliki/TradableQualityHypothesis.html
El Sr. Fowler aborda el tema con la distinción de Kent Beck (en mi opinión, muy acertada) entre calidad interna y externa. En la calidad externa, donde la percepción de negocio es crítica, es necesario llegar a compromisos claros que consigan aportar el máximo valor en el mínimo tiempo. En la calidad interna, la percepción de negocio no influye. Claro, lo que les influye es el tiempo. Pues bien, lo que dice el Sr. Fowler es que «reducir la calidad interna nos hace ir más lento».
Me parece muy relevante señalar que a Martin Fowler no se le puede tachar de ser un defensor ferviente del «Software Craftsmanship» al estilo de Robert C. Martin (Uncle Bob). Al final del artículo, de hecho, se lamenta de que predicando la metáfora del SC estamos perjudicándonos porque precisamente el negocio siempre estará dispuesto a quitar un poco -o un mucho- de «Craftsmanship» para alcanzar sus objetivos. En mis propias palabras, el SC aplica estupendamente cuando estamos hablando de hacer software porque nos gusta, sin nadie preocupado por su cuenta de resultados. Sólo en ese contexto podemos darnos el gusto de dejarnos llevar y dedicar el tiempo que consideremos necesario porque estamos creando una obra de arte. _Nuestra_ obra de arte.
Me voy a quedar con que lo que querías decir en este artículo es eso, que el «Software Craftsmanship» difícilmente encaja en el mundo real. Así, se entiende. Ahora bien, pongamos las cosas en contexto porque eso no está reñido con hacer software que internamente tiene la calidad suficiente. En mi experiencia, ese término medio normalmente basta para satisfacer nuestras aspiraciones naturales de hacer «Software Craftsmanship» en el día a día.
Espero y deseo que esta aportación sea de ayuda porque os lee mucha gente (yo incluido). En especial, me preocupa la gente que empieza.
Quizás lo tengas que leer una tercera porque creo que justo has interpretado al revés el mensaje. Pido disculpas porque no soy un buen escritor y no he debido de transmitir bien el mensaje.
Simplemente es una «llamada de atención» a no perdernos en el camino y no olvidar cuál es el objetivo real.
Efectivamente en tu casa sí te puedes permitir el convertir la herramienta en el objetivo, porque como bien dices lo haces por placer. Y de hecho es hasta deseable porque eso es entrenamiento que te vendrá muy bien para la otra parte.
Saludo y muchas gracias porque por supuesto toda aportación ayuda.
Me ha gustado mucho el artículo, es una buena llamada de atención. Pero no incluiría DDD como palabro de bares y moda a seguir porque lo haya dicho algún libro ya que DDD ayuda mucho a entender a negocio, no hay que quedarse solamente con la parte friki que a todos nos encanta, los patrones de diseño (entidades por aquí, repositorios por allá) sino con el lenguaje ubicuo y empezar a hablar todos el mismo idioma de negocio para aportar valor.
A todos nos gusta jugar con herramientas nuevas o que están de moda, pero aportar valor siempre debería estar por encima de todo aunque sea aburrido muchas veces,
DDD está ahí a posta precisamente por eso. Es una herramienta buenísima (a mi por ejemplo me encanta), pero como todas si la «pervertimos» nos cargamos su valor y perdemos el objetivo.
De ahí la crítica que he intentado hacer en el artículo.
Me uno al club de los que se han quedado un poco perplejos al leer esto. Sobre la calidad, la primera acepción de calidad según la RAE es:
Propiedad o conjunto de propiedades inherentes a algo, que permiten juzgar su valor.
No sé dónde aparece aquí el sesgo comparativo. En cualquier caso decir que la calidad es algo para compararnos con otros me parece tergiversar bastante el asunto. Particularmente la entiendo cómo algo que me permite comparar una versión temporal del código (valorar sus propiedades) con otra posible versión del mismo donde no se hayan aplicado buenas prácticas.
Con esto en mente… ¿Como buenos profesionales debemos preocuparnos de que nuestro trabajo sea de buena calidad? Creo que la pregunta se responde sola y no se restringe a los que nos dedicamos a la informática. ¿Es esto siempre compatible con las necesidades de velocidad del negocio? En muchos casos no y nuestro valor como profesionales será argumentarlo.
Ojo porque nunca he dicho que hay que hacer las cosas mal. De hecho es la parte que veo que se está entendiendo peor del artículo porque intento decir justo lo contrario.
Sólo digo dejar de usar la palabra «calidad» en favor de «mantenibilidad», para precisamente significar que si hago las cosas mal no será mantenible y si no es mantenible no conseguire adaptar el sistema a las necesidades del negocio. Y para hacer las cosas bien tendremos que buscar las herramientas que mejor cuadran con el negocio, el equipo, …
Estimado Alejandro,
Para nada has de pedir disculpas y tampoco creo que seas mal escritor. Para nada. El artículo en mi opinión está bien escrito, tiene un principio, un desarrollo y conclusión coherente. Todo muy bien.
La «llamada de atención» es totalmente válida y procedente. Creo que hoy en día se nos está yendo un poco la pinza con los lenguajes, los nuevos estilos de programación y con las nuevas técnicas de diseño y de pruebas. Por este lado, ningún problema. Por esto mismo digo al final lo de que la conclusión sería más o menos como que el SC no encaja en el mundo real. O al menos, no el SC puro, quiero decir.
Ahora bien, estoy frontalmente en desacuerdo con dos cosas:
1. Con la afirmación: ‘yo dejaría de hablar de “calidad” y desterraría esa palabra de nuestro vocabulario de desarrolladores’. Lo siento pero esto nos desprovee de un atributo básico para el resto de profesiones. Para mí, esto va en contra de la profesión. Hablar de calidad no debería ser tabú y menos cuando se explica bien (interna, externa, mantenibilidad, etc.).
2. La conclusión es demoledora, descorazonadora, desmotivadora… «eres una llave inglesa» 🙁
No tenemos por qué estar de acuerdo. Esto da para un debate que va mucho más allá y no quiero enrrollarme pero tu enfoque es mecanicista y eso nos trae deshumanización… not my cup of tea. Tampoco soy yo el más hippie del barrio, que quede claro. 😉
En cualquier caso, gracias por el artículo, por la respuesta y por el esfuerzo que hacéis por sacar artículos, tutoriales. Gracias de corazón por ello.
Lo de la palabrita «calidad» es un poco lo de menos, es lo que me permite hilar todo el argumento. Fijate que yo uso «mantenibilidad» que no deja de ser otra palabra. Pero sí veo que la calidad muchas veces está mal entendida tanto por nosotros porque la «glorificamos» como por negocio que no entiende las implicaciones que hay detrás. Sin embargo al hablar de mantenimiento, ciclo de vida, adaptación a cambios, … eso sí que lo pillan rápido y puede haber un diálogo muy bueno para precisamente no dejar de hacer las cosas bien, que es al final lo que nos interesa a todos (de hecho más a negocio que a nosotros).
Lo de «la llave inglesa» no es por reducirnos a máquinas, sino porque tenemos que darnos cuenta de que nuestra labor es ponernos al servicio de negocio. Esto cuesta porque aquí el problema es nuestro ego. Además atentos a la IA, machie learning y todas estas mandangas que vienen pisando fuerte y negocio no va a tardar ni un minuto en cambiarnos por otra cosa que haga lo mismo más rápido o más barato o con menos problemas (vale es cierto que no tanto y todavía nos quedan muchos años de servicio, pero ojito por ejemplo a cosas como esta: https://twitter.com/TeleportHQio/status/1043245039261044736?s=20).
Y muchas gracias por los ánimos!
Hola Alex,
Muy interesante artículo además de controvérsico :). Creo que da para que todos reflexionemos acerca de ello.
Aprovecho el hilo para compartir mi punto de vista sobre el tema.
Yo por calidad, aplicado a desarrollo de software, entiendo un conjunto de propiedades del propio sistema como podría ser la mantenibilidad, pero además otras muchas como: seguridad, disponibilidad, rendimiento, interoperabilidad, etc… Lo que comúnmente se denominan requisitos no funcionales o atributos de calidad del software.
Por supuesto que nuestro objetivo es entregar valor a negocio de una manera lo más rápida posible, para ello la MANTENIBILIDAD (atributo de calidad) jugará un papel muy importante, pero también de manera SEGURA (ej: los datos del sistema no pueden verse comprometidos), con tiempos de respuesta adecuados (RENDIMIENTO), con una buena DISPONIBILIDAD del servicio, etc…
Normalmente (seguro que hay excepciones) negocio no suele centrarse en este tipo de características del sistema y suele ser por una razón muy sencilla, se dan por hechas.
En mi opinión es labor del desarrollador, arquitecto, ingeniero de software (o como queramos llamarlo) concienciar a negocio sobre ello e intentar aplicar unos NIVELES de CALIDAD acordes con el contexto: no es lo mismo desarrollar una pequeña aplicación web de uso interno para 3 usuarios que la utilizarán 2 veces por semana para consultar unos datos, que una plataforma para la consulta de la historia clínica de pacientes (SEGURIDAD), o que un sistema de control ferroviario (RENDIMIENTO, DISPONIBILIDAD, ROBUSTEZ). En estos casos los requisitos no funcionales difieren enormemente.
Resumiendo, para mí la calidad es algo inherente e inseparable del software y es el propio contexto (y nuestro buen hacer) el que determinará los niveles adecuados a aplicar para considerar que algo entrega valor con calidad.
Saludos!
Perplejo! Espero que en la fabricación del avión, barco, BMW con el que vas a trabajar, medicamento que tomas para el colesterol … no apliquen tales criterios y rezo a Dios para que no aplicaran o apliquen semejantes criterios en la central nuclear que tengo a 20 kilómetros de mi casa …
He leído el artículo y lo veo así: es deseable producir software correcto, robusto, y fácil de cambiar, en un tiempo razonable. «Fácil de cambiar» es una calidad interna (invisible sin examinar el código) esencial para ser productivo. Calidad interna y productividad no son intercambiables. Sin embargo en los miembros de un equipo hay diferente conocimiento, intereses, y personalidades, lo cual lleva al conflicto.
Por ejemplo, aunque tengamos un ideal común de calidad frente al que medirnos, y hablemos de ello (e.g. un test debería ser FIRST), también depende de nuestro juicio individual identificar que tests aportan valor o no. Madurar no es solo leer un libro, hace falta mucha bici para ser ciclista. Si no fuese así nos reemplazarían con un algoritmo. Es inevitable que haya diferentes criterios.
También hay diferentes intereses, es el «tú hazlo que funcione me da igual como», contra «no quiero leer código durante horas para cambiar una línea», o «usemos tal tecnología porque incrementa mi valor como profesional».
Esta en la naturaleza del software ser invisible y único. Si hay un conflicto hace falta un líder técnico que entienda ambas partes. En su defecto es el programador el que se lleva la última torta.
Excelente artículo, tal vez lo de mal explicado es porque no todos entienden el sentido que le quisiste dar pero todo lo que has expuesto es correcto. Al ser programadores estamos prestando un servicio al Cliente que nos contrata; y los negocios hoy en día se rigen mucho por los resultados, no hay tanto espacio para la calidad. Entonces nuestro deber es asumir los objetivos y resultados como nuestros, entonces nos enteramos que nuestra «calidad» entonces depende de alcanzar los objetivos de manera correcta, con la menor cantidad de recursos y en el menor tiempo posible. Si nos cuesta mucho entender el concepto debemos tomar el siguiente ejemplo:
Voy a construir mi casa, busco a un contratista y le doy los planos que yo he realizado, el los examina y me muestra los cambios que se pueden hacer para que esté bien construida, pero pues yo la quiero como está diseñada, entonces trata de que comprenda que se puede mejorar, así será más eficiente y tendrá mas rentabilidad a largo plazo; como no soy ingeniero eso no lo puedo ver y por lo tanto no me interesa, lo quiero es que se construya como lo tenga visualizada, y si no me pude cumplir en eso busco otro contratista que haga el trabajo como yo lo deseo.
Este vendría a ser idea principal, alcanzar los objetivos de forma eficiente y rápida, la calidad viene después.
Bueno la verdad es que lo que estoy diciendo es básicamente lo contrario, el hacer las cosas bien no es negociable. Por seguir el ejemplo, si me piden hacer una casa y sé que si la hago tal como me ha pedido se va a derrumbar no debería construirla jamas. Si me dicen que haga una casa y que la única herramienta que puedo usar es un destornillador (porque el resto de herramientas
no las entiende quien me contrata) no debería construirla jamas.
Pero lo que tampoco puede pasa es que si me han pedido un caseta para el perro yo construya un palacio porque es mucho más chulo o que para construir la caseta del perro quiera usar una tuneladora para hacer unos cimientos de cuarenta metros porque así la caseta no se la llevará un huracán (pero claro para usar eso necesito seis meses).
Lo que hay que construir está en manos exclusivamente del negocio y el cómo está en nuestra mano. Pero el cómo tiene que ser lo justo y necesario para conseguir el qué con todas la garantías y no «fliparnos» ni definiendo nosotros el «qué» ni queriendo usar para el «cómo» todas y cada una de las herramientas existentes.