design - magazine - Vida útil del software: ¿con qué frecuencia esperas comenzar desde cero?
design o desing (13)
A menudo es imposible justificar una reescritura completa a menos que realmente pueda cuantificar cuáles serán los beneficios para los usuarios finales. De lo contrario, los dejará con el mismo software durante 2 años mientras se va y rediseña el suyo. Mientras tanto, sus competidores están ocupados agregando nuevas funciones en lugar de volver a crear funciones existentes con nuevos errores. Tal vez la disminución en los costos de mantenimiento hará que valga la pena en el largo plazo, pero mientras tanto arriesga una gran pérdida en la participación de mercado.
Creo que está mejor con refactorizaciones pequeñas y seguras que pueden ocurrir simultáneamente con el desarrollo de nuevas funciones. Es posible que no puedas lograr todo lo que quieras, pero al menos tendrás algo que se pueda enviar mientras tanto.
Editar: en respuesta a "¿Y si la plataforma se muere? Al igual que en ASP Classic nuevamente", entonces no estás reescribiendo tu código cada X años. Su plataforma ha sido descontinuada. Por supuesto, esto no significa que de repente todos los servidores ASP clásicos mueren, solo significa que no habrá más actualizaciones para la plataforma. Luego debe sopesar el costo de la reurbanización de la aplicación en comparación con el costo de que sea más difícil atraer / mantener a las personas para que trabajen en ella. Cobol podría considerarse un callejón sin salida, pero todavía hay muchas aplicaciones de Cobol que la gente está manteniendo porque la compañía piensa que es más económico hacer eso que reescribirlas. Entonces, la elección de reescribir o no es todavía una decisión comercial.
He escuchado a personas decir que la vida útil promedio del software es de aproximadamente 3 años, pero eso me parece sorprendentemente bajo. No lo compro.
Después de todo, algunos de mis clientes tienen mainframes pesados que existen desde hace 20 años, y están tan arraigados que podrían vivir para siempre.
Personalmente, suelo empezar a hablar de una refactorización severa cuando la plataforma se hace tan vieja que es malo para nuestras habilidades (somos contratistas) y de otro modo ineficaces para seguir manteniendo el proyecto. Estoy pensando en ASP Classic aquí. Esa puede ser una ventana de 5 a 8 años, y ni siquiera necesita ser una reescritura.
Por supuesto, también he visto proyectos que incurrieron en una gran cantidad de deuda técnica porque alguien cedió a las partes interesadas con demasiada frecuencia o un desarrollador no sabía cómo planificar el cambio. O el proyecto se inició en una plataforma débil que no se escalaba bien. Eso reduce radicalmente la vida útil.
Tal vez esos proyectos son los que tienden a vivir 3 años. O menos.
Una última reflexión: algunos estudios han demostrado que es más barato mantener el código anterior que escribir nuevo, y lo creo. Reescribir sistemas grandes siempre es mucho más difícil y costoso de lo que parece.
¿Todo esto conspira para indicar que los desarrolladores tienden a reescribir demasiado pronto, y quizás ingenuamente? Estoy pensando que sí, y puedo ver que es un error fácil de hacer.
¿Cuáles son tus experiencias aquí?
Cuanto menos a menudo, mejor.
Pero, sinceramente, 3 años es muy corto. Especialmente para un promedio.
La realidad es que generalmente solo comienza de nuevo cuando no puede crecer , cuando la deuda técnica es tan alta, es mejor quebrar técnicamente. E incluso entonces a menudo puede reorganizar su deuda.
La clave del éxito a largo plazo es tratar de mantener su deuda técnica al mínimo en todo momento.
Depende completamente de lo que hagas. Para el software comercial, los tiempos de espera más largos casi siempre son buenos. Sin embargo, creo MMO de navegador, y he descubierto que con el gran volumen de edición y la reescritura de gran cantidad de códigos que siempre estoy haciendo para mejorar los juegos, ayuda a reescribir desde cero o cerca de cero casi todos los años. .
Por supuesto, siendo un par de chicos trabajando en proyectos relativamente pequeños, no tenemos casi los problemas de escalado que muchos de ustedes hacen. Hace que sea mucho más fácil justificar rehacerlo.
Además, no tener que informar a los gerentes probablemente nos ayude a algunos también.
Mi primer empleador, comenzamos a construir en 2000, la aplicación todavía existe después de 8 años en el mismo folleto. Comenzaron un proceso de reescritura que se ha estancado; sin embargo, ahora la aplicación se considera heredada y todas las funciones nuevas se basan en una nueva plataforma.
3 años parece muy corto.
No creo que la estimación de 3 años mida el tiempo entre las reescrituras totales. Es más probable que mida el tiempo entre versiones principales del mismo software (estoy pensando en Windows y MS-Office, por ejemplo). La próxima versión principal probablemente no sea una reescritura completa, solo una actualización.
Por supuesto, depende del dominio de la tecnología, pero tres años parece un poco bajo. Algunos dicen que toma hasta diez años para que un buen software madure.
He visto algunos proyectos en los que las partes interesadas dicen "podemos reescribir / reemplazar [el sistema grande] en seis meses" y todavía lo intentan varios años después.
Razones por las que creo que 3 años probablemente sean las correctas.
Se implementó un nuevo sistema principal (ERP, CRM, etc.) y tiene un módulo "integrado" para reemplazar la aplicación anterior.
Lo mismo, pero no una aplicación integrada, pero la aplicación existente no es adaptable (la gente se fue, la tecnología ha cambiado, las políticas de TI actuales han cambiado, a los usuarios no les gusta la aplicación existente).
La compañía de la que adquirió la aplicación básica, para personalizarla según sus necesidades, ha desaparecido.
O no te llevas bien con ellos nunca más.
La tecnología para la aplicación existente es "obsoleta" (de acuerdo con el proveedor del marco / Microsoft / consultor / experto de la industria / nuevo gerente de TI que tiene el oído de la administración).
"Estamos eliminando progresivamente (Windows 95 / Windows 98 / Windows 2000 / Windows XP / NT) y necesitamos una tecnología compatible en nuestras aplicaciones".
"Hemos aprendido mucho de (Versión de la aplicación n) y haremos mucho mejor la segunda / tercera / cuarta / n + 1 vez".
Justificación de trabajo para desarrolladores / gerente de TI / vicepresidente de división / empresa de consultoría.
Los usuarios lo odian
Hemos fusionado / adquirido un competidor / adquirido por un competidor y el suyo es mejor.
Eso es solo un comienzo.
Hay muy pocas aplicaciones cuyas funciones básicas no se implementaron satisfactoriamente hace mucho tiempo en dBASE ejecutándose en DOS. Que podría haberse migrado y haber estado disponible hoy a través de Foxpro. (Y, maldición, correrían rápido). Observe que Foxpro no aparece mucho por aquí, solo sigue ronroneando en el fondo. (Descargo de responsabilidad: no he tocado un framework xBase en 15 años).
Yo diría que nunca.
Escribir una aplicación es mucho más que codificar. Cuando reescribes todo, nunca pasa de cero ya que tienes el Xp del análisis anterior, la ejecución de producción, los informes de errores, el uso diario, etc.
También tiene datos que tendrá que portar.
Desde cero? Nop. Gran parte del trabajo ya está hecho, lo que lo hace más fácil, y es necesario adaptar una gran cantidad de trabajo previo, lo que lo hace más difícil. Al final, lleva mucho tiempo crear eso la primera vez, pero no lo hiciste ex nihilo.
depende de qué tan bien se haya modelado el negocio, incluidas las áreas futuras de cambio anticipadas, cuán involucrados estaban los interesados / usuarios, y especialmente qué tan bien se mantuvo el sistema de software.
Por ejemplo, el primer sistema completo de automatización empresarial que escribí "a mi manera" (es decir, donde las partes interesadas me escucharon y los escuché y nos tomamos el tiempo para entrevistar a todos los usuarios y realmente hacerlo bien) sigue siendo fuerte 21 años después. Se reescribirá gradualmente en los próximos años, no porque haya algún problema con el software, sino porque el director de TI piensa (y acepto, aunque no me lo preguntó) que sería mejor migrar las aplicaciones desde DataFlex. a la red.
Muchos de los sistemas de aplicación que he escrito o en los que he contribuido siguen siendo sólidos 5, 10, 15 y 20 años después. Sin excepción, es porque los interesados / usuarios estuvieron muy involucrados en el proceso, anticipamos cambios futuros en el negocio, nos tomamos el tiempo para hacerlo bien y nos aseguramos de que el equipo de mantenimiento hiciera lo mismo.
Por otro lado, por lo que he visto, la vida útil promedio del software malo es de aproximadamente 3 años, porque ese es el tiempo que tardan los usuarios en sentirse realmente hartos, los gerentes se cansan de oír hablar de eso, y los ejecutivos deciden "hacer algo" al respecto. Desafortunadamente, muchas ''reescrituras'' estipulan "mantener la misma interfaz" para evitar el reentrenamiento, lo que lleva a otro sistema malo y comienza otro ciclo de 3 años ;-)
El equipo en el que estoy trabajando ha estado desarrollando la misma aplicación web durante 6 años, y no hay final a la vista. En ese momento, se pasó de Classic ASP a ASP.NET 1.1 a ASP.NET 2.0, por lo que varios módulos han sufrido reescrituras incrementales, pero nunca algo así como una reescritura desde cero. De vez en cuando alguien dirá qué bueno sería si pudiésemos comenzar de nuevo, pero tenemos más de 60,000 usuarios: no hay forma de que vayan a esperar los 12 a 18 meses que tomarían mientras su funcionalidad o características actualizadas se sientan en una estante.
Solo he tenido la oportunidad de hacer una reescritura ground-up dos veces. En ambos casos, la razón por la que tuvimos tiempo y aceptación para hacerlo fue porque teníamos un grupo bastante pequeño de clientes que usaban una versión ya estable. Cuando acudimos a ellos con el nuevo producto, todos coincidieron en que era mejor que el sistema anterior, pero muy pocos lo compraron porque ya estaban contentos con lo que tenían. Fue muy divertido para los programadores, pero finalmente fue una pérdida para el negocio.
Por lo tanto, a partir de la experiencia personal, las cosas que puede comenzar desde cero cada 3 años probablemente no sean utilizadas por muchas personas. Cuando tiene una aplicación o servicio ampliamente utilizado, especialmente en un entorno corporativo, es bastante difícil obtener la aprobación para realizar actualizaciones graduales, y mucho menos volver a escribir.
La base de código con la que trabajo comenzó en 1980; todavía hay evidencia de código de 1984 en lugares, si sabes lo que estás buscando. Tengo pocas dudas en mi mente de que algunos, posiblemente incluso la mayoría, de ese código deberían mejorarse (y no hay duda de que podría mejorarse). Pero un ciclo de 3 años es muy corto en comparación con ese período de 30 años. Algunos códigos han sido descartados desde entonces; más probablemente debería ser. Pero planear reiniciar cada tres años me parecería libertino. Para un sistema complejo, piensa en Perl, Python, Ruby, un compilador de C, un compilador de C ++, un DBMS, te reirían de la cancha con un ciclo de 3 años de tirarlo todo de la basura. Al final de los 3 años, es posible que tengas un sistema moderadamente decente que otros 5 años traerán un buen brillo. Entonces, al menos en mi parte del mundo, necesitas pensar en términos de vida del código en ciclos de más de 10 años.
Todavía tengo un código de 19 años en producción, aunque con grandes modificaciones en el futuro.
En realidad, debería haber sido eliminado al menos hace 5 años, ya que había crecido LEJOS más allá del diseño original y se ve limitado por decisiones de diseño que tenían sentido cuando se escribió originalmente, pero ahora están locos.
Parece que la conversación aquí se centra en el tiempo promedio entre reescrituras. Pero muchos sistemas fallan o se vuelven obsoletos por razones comerciales y nunca se vuelven a escribir. Muchos sitios web se rediseñan cada 2-3 años. Se informa que las aplicaciones móviles tienen una vida media de solo 6 meses.
En mi búsqueda web en torno a la vida útil del software, solo pude encontrar un estudio de buena reputación sobre el tema. El estudio encontró una esperanza de vida promedio de 9-10 años, pero la encuesta inicial se realizó en 1991. El ritmo de cambio de los factores subyacentes del negocio y las tecnologías subyacentes ciertamente se ha acelerado desde entonces.