Entre el abaratamiento de costes propiciado por la globalización y la situación económica actual, parece que el precio es lo único que importa hoy en día. Se buscan productos que hagan (o aparenten hacer) cuantas más cosas mejor, por el menor precio posible.
Conseguir más por menos es un objetivo completamente razonable, pero todo tiene un coste (nadie da duros a cuatro pesetas, que decía mi abuelo) y al final siempre se resiente lo mismo: la calidad.
Por supuesto, este fenómeno no es ni mucho menos exclusivo del desarrollo de software y podemos apreciarlo en todo: ropa, calzado, comida, aerolíneas, hoteles, dispositivos electrónicos, …
En este escenario, a la hora de desarrollar software nos encontramos con la necesidad de tratar con una presión por parte de negocio que suele ir en dos líneas:
- Gastar menos. Lo que suele traducirse en reducir plazos (pagar menos horas) o reducir personal (pagar menos sueldos).
- Obtener más. Si no se pueden reducir gastos, hay que conseguir que el producto haga más cosas por el mismo precio.
La presión por incrementar las ventas hace que se dé máxima importancia al tiempo y/o a añadir un montón de purpurina y luces brillantes para que llamen la atención y poder captar más clientes. El cómo hacer que esos clientes luego no salgan huyendo descontentos es otra historia.
Invertir horas de desarrollo en hacer mejor las cosas, aumentar la calidad y ganar en solidez no es algo que se considere importante, quizá porque tampoco es algo fácil de usar como argumento de venta en muchos casos, en los cuales el cliente sólo busca un precio ajustado o una lista de características larga.
Cuando nos enfrentamos a estas situaciones, llega un momento en el que los que estamos desarrollando el software nos preguntamos, ¿qué sentido tiene luchar por hacer las cosas bien, si no es lo que se va a valorar de nuestro trabajo?
Hay varias razones que justifican escribir software de calidad y muchas de ellas son perfectamente válidas desde el punto de vista puramente económico, pero hay un motivo que nos afecta directamente a los que lo desarrollamos: el software de calidad te permite dormir tranquilo, como dicen en Release It!:
your users may not thank you for it, because nobody notices when a system doesn’t go down, but you will sleep better at night
puede que tus usuarios no te lo agradezcan porque nadie se da cuenta de que las cosas funcionan, pero dormirás más tranquilo
Dentro del ciclo de vida de un producto, el mantenimiento durante la fase de producción es una de las fases más importantes y, a la vez, desagradables. Cuando estás desarrollando y encuentras un fallo, puede ser hasta divertido buscarlo y corregirlo. Cuando ese fallo lo encuentras en producción, dejando sin servicio a miles de usuarios y hay que corregirlo contrarreloj… te aseguro que es mucho menos divertido.
Muchos de los que hacemos esto no somos los que nos encargamos de dar el mantenimiento directamente y estamos parapetados detrás de equipos de operaciones o soporte, pero cuando el problema es grave, antes o después nos acaba salpicando.
Es importante tener en cuenta que esto no se trata de todo o nada y hay situaciones en que deben primar otros factores. Cuando estamos arrancando un producto, es preferible poder contar con algo sin tener que esperar indefinidamente al producto perfecto (aunque cuidado, que también se puede ser demasiado ágil). Si nos demoramos mucho en un desarrollo es posible que nos quedemos sin recursos ecómicos antes y no podamos llegar a ponerlo en producción, en cuyo caso la calidad será lo de menos.
Insisto en que el objetivo de reducir costes y obtener más por menos me parece lo más natural del mundo, pero sacrificar la calidad no es el mejor camino para conseguirlo y, concretamente, hacer software de calidad no tiene porqué ser más caro ni menos rentable.
Como siempre, se trata de buscar un equilibrio, aunque ahora parece que el desnivel es siempre hacia el mismo lado y es a nosotros a los que nos toca tirar hacia el otro y pensar un poco en la calidad de lo que hacemos, aunque sólo sea para no volvernos (más) locos.
100% de acuerdo. Añadiría otro elemento que presiona la calidad a la baja: los desarrolladores. Hay muchos que sólo les preocupan los requisitos funcionales; es decir, si hace lo que me piden que haga, está bien. Mantenibilidad, escalabilidad, legibilidad, son conceptos que les resultan ajenos o que engloban en las «manías del jefe».
Tienes razón, Javier. Para mi es la diferencia entre gente que cumple en su trabajo y gente que _hace bien_ su trabajo.
@javier tienes razón, aunque yo creo que es algo propio de mi trabajo, y me gusta hacerlo así y pienso que alguien que no piensa en los aspectos tipo escalabilidad, legibilidad, equipo, documentación, o siemple estructura; creo yo que no se les puede llamar desarrolladores. Hace poco empecé a trabajar, y tengo mucho que aprender, pero estoy acostumbrado a leer código y a disfrutar con el código bien escrito, elegante, escalable, que deslumbra como se ha plasmado la idea o como el equipo domina tecnología y lógica. Pero entre mis compañeros hay algunos que hace códigos muy feos, sin sentido estructural, «USAR LA CADENA DE DESCRIPCIÓN PARA IDENTIFICAR LOS OBJETOS, ¡ ENVÍA EL ID POR FAVOR!» «luego busco la cadena en la bd y saco el id», eso no es un desarrollador.
Saludos desde Valencia.
No puedo estar más de acuerdo contigo, Juanma. He comprobado que realizar aplicaciones y componentes software cuya calidad no se ha cuidado y que tienen un diseño marcadamente pragmático pocas veces dan el resultado esperado, puesto que pronto se desea cambiar algo o cambia el entorno, un ligero cambio de especificaciones y todo peta irremediablemente.
Más velocidad en el desarrollo no siempre es mejor, hay que defender la elegancia y la pureza. ¡Hagamos que el tópico de programador informático cambie!
No aporreamos teclas, no picamos código: hacemos INGENIERÍA.
Jesus, por desgracia lo que dices es muy frecuente (di mi visión sobre ello aquí: https://blog.koalite.com/2012/02/la-industria-del-software-en-espana-eres-tu/). Aunque se haga duro a veces, yo creo que merece la pena esforzarse por hacer las cosas bien porque es la mejor manera de demostrar es rentable.
José Manuel, estoy de acuerdo con lo que dices, pero lo de ingeniería… ahí tengo mis dudas.
Madre mía, ¿cuál es tu opinión al respecto? Ingeniería para mí es resolución de problemas con base formal sólida+ingenio+metodología. ¿Por qué no lo tienes tan claro que hagamos ingeniería? En todo caso es algo sublime :)
Creo que somos todavía una profesión muy joven que intenta buscar sus metodologías y procesos y, depende de con quien hables, tratan de asimilarla a una ingeniería, a una arquitectura o una artesanía.
En mi opinión (muy personal), el desarrollo de software tiene una parte creativa que no se puede obviar. Mucha gente que lo concibe como una ingeniería cree que la parte creativa acaba en el análisis, arquitectura o diseño, y por tanto es factible dar un conjunto de especificaciones para que alguien «pique código», pero creo que hoy por hoy eso simplemente no es viable.
«Picar código» bien requiere más creatividad que «poner ladrillos bien» (dicho con todo mi respeto para los que ponen ladrillos, cuyo trabajo tiene otro tipo de dificultades).
Justamente estas vacaciones leí «SCRUM Y XP DESDE LAS TRINCHERAS» y uno de los capítulos es «Por qué la calidad no es negociable». En el libro se divide la calidad en dos tipos, la interna (código) y la externa (diseño).
La externa, la incluyen dentro del alcance del proyecto por lo q puede ser variable. Podemos tener un producto más o menos feo y mejorarlo a futuro, pero con la interna, no hay negocio posible :-)
Buen Post!!. Encantado de encontrar tu blog.
Omar, me parece una buena forma de verlo. Habrá que echarle un ojo al libro.