Reutilización de código, mantenimiento de aplicaciones (VI)
Introducción
Hasta ahora, hemos visto como pasar de una aplicación de Software que cumple los requisitos a una aplicación de Software que cumple los requisitos, que es reutilizable y que mejora el mantenimiento de aplicaciones, llevándolo todo a un mundo ideal.
¿Pero es ese mundo ideal de desarrollo el mundo ideal de la oportunidad de negocio o de mercado?.
Cuando las prioridades se imponen al mundo ideal
Hablo de desarrollo del Software…
El problema hoy día de muchas empresas, por no decir todas, es la prioridad.
El riesgo o amenaza de una empresa es la competitividad de la competencia.
Y las incógnitas de la ecuación de toda empresa es el tiempo, los gastos y los ingresos.
Si mezclamos todos estos ingredientes en un mismo tarro, podemos obtener un cocktail de lo más explosivo.
En el mundo ideal, los desarrolladores queremos hacer un código bonito y que cumpla todas las posibles premisas de lo que es un desarrollo correcto, sin embargo, no siempre esto es posible.
La presión por terminar los proyectos en un corto plazo de tiempo, pensar en ingresar todo lo que se pueda y ofrecer unos gastos reducidos, hacen que el proyecto sea atractivo, la empresa ingrese un variable muy goloso y se vuelva a desarrollar otro producto. Así funcionan la mayoría de empresas de servicios hoy día. Es lo que mucha gente denomina como un modelo de negocio práctico.
Sin embargo, hay clientes (existen y los hay), que prefieren no ser tan “prácticos” y dedicar parte de los esfuerzos y dinero a lograr un sistema que recoja todas estas bondades. Y con ello, no se está queriendo decir que el proyecto haya sido más largo o más costoso entendiendo como coste los gastos o la diferencia entre ingresos menos gastos.
Muchas veces, pensamos que hacer proyectos que dispongan de todas estas posibilidades no es ventajoso, pero pensemos en que podemos estar delante de un proyecto cuyos requisitos cambian o se saben de antemano, que variarán en el tiempo y mucho,… quizás convenga hacer las cosas de la mejor forma posible.
No quiero indicar con todo esto que es mejor una forma de hacer los proyectos (por ejemplo en la parte I de este conjunto de entradas), o de la última forma aplicando estrictamente SOLID.
Me gustaría que este conjunto de entradas sirvieran de reflexión para indicar que ni existe el mundo ideal ni el mundo “no ideal” es malo.
Cada proyecto de Software es único, no me cansaré de repetirlo, y como tal, requiere un planteamiento concreto a la hora de abordarlo.
Muchas startups utilizan planteamientos ágiles para sacar adelante su producto, porque no buscan el cojo-producto, sino dar funcionalidad a una idea para ir comprobando como funciona y en su caso refinarla adecuadamente. Dentro de ese refinamiento, podrían encontrarse con la necesidad de rehacer su producto por completo, y eso siempre y cuando empiecen a tener éxito y mucho antes de que se convierta en cojo-producto como es obvio.
A veces debemos sacrificar mantenimiento y reutilización para llegar al mercado primeros y golpear antes.
Todo, absolutamente todo, es cuestión de prioridades, y nada nos hace más libres que tomar las decisiones que consideremos oportuno en cada momento, pudiendo saltar de una forma de abordar el producto a otra si con ello, tenemos después que rehacer el producto.
3 Responsesso far
En tu razonamiento hay una premisa implícita: resulta más rápido y barato hacer software de baja calidad.
¿Realmente es así?
Ojo, que no estoy diciendo que seguir SOLID a rajatabla y aplicar sobreingeniería a un proyecto sea rentable, pero tampoco tengo muy claro que hacer las cosas «mal» ayude a reducir el time-to-market.
MMmm…
>En tu razonamiento hay una premisa implícita: resulta más rápido y barato hacer software de baja calidad.
Yo SÍ creo que hacer las cosas «mal» puede ayudar a reducir el time-to-market. Pero como todo tiene un precio que se paga. A este precio se le conoce como «deuda tecnológica».
Hacer software de «baja calidad» es más rápido y barato, pero adquiere una deuda tecnológica.
Mientras tengas esta deuda, es decir mientras tu producto no esté «bien» irás pagando los intereses que te genera. Intereses en forma de que arreglar un error te cuesta más tiempo. Que añadir una funcionalidad pasa a ser más complicado, etc, etc.
A medida que inviertes tiempo refactorizando tu código, y así vas «pagando» la deuda contraída, los intereses disminuyen (añadir funcionalidades pasa a ser más fácil, resolver un bug lleva menos tiempo,…).
Y como todas las deudas cuando más se pospone su pago (es decir, si «pasas» de refactorizar el código, «total ya que funciona…») más han crecido los intereses y al final puede llegar a un punto donde ya no es posible asumir su pago, es decir estamos ante una aplicación totalmente inmantenible. Que puede que funcione, pero que no vamos a poder mejorar y donde cuando se detecte un bug será imposible de resolver.
Contraer deuda tecnológica NO es malo. De hecho a veces es imprescindible para sacar producto nuevo (de ahí la visión «agile» de las start-ups), pero debe tenerse presente que se contrae y debe planificarse cuando y como se piensa «pagar» esa deuda.
En resumen: si hago las cosas «mal» quizá saldré antes, pero luego deberé invertir MÁS tiempo en arreglar cada bug o en añadir funcionalidad nueva. Y como no pague la deuda, llegará un punto que mi producto me «explotará».
Así que la conclusión es que se puede hacer algo temporalmente «mal» para salir rápido al mercado, porque es un parche, por lo que sea, pero debemos ser conscientes de ello y luego invertir el tiempo necesario en mejorar el código. Si no lo hacemos, morimos fijo.
Saludos!
Hola Eduard,
Estoy de acuerdo en el tema de la deuda técnica y en la visión ágil. De hecho que parece fundamental no tratar de dejar todo el código «perfecto», sino invertir el tiempo en solucionar aquello que te está frenando en cada momento (el resto lo dejas bien guardadito y encapsulado y si funciona y no tienes que tocarlo a menudo, estupendo).
A lo me refería es que hay veces que, por intentar correr mucho, te ahogas antes de empezar (no hace falta esperar meses para acumular intereses).
A veces se tarda muy poco en «acabar el desarrollo», para luego pasar por una fase eterna de pruebas hasta tener algo medianamente presentable porque no se han aplicado los más mínimos criterios de calidad a la hora de construir el software.
Por supuesto todo depende mucho del proyecto y del equipo, pero estoy cansado de tratar con proveedores que me dicen «en una semana lo tienes» y es verdad, en una semana lo tengo, pero luego me paso 4 meses hasta que lo puedo poner en producción porque está todo lleno de fallos, y esto lo digo como *cliente* no como desarrollador.
Saludos