it-swarm-es.com

¿Cómo puedo vender una reescritura de un programa heredado a la empresa?

Tenemos una aplicación clásica heredada ASP que existe desde 2001. Necesita ser reescrita con urgencia, pero está funcionando bien desde la perspectiva del usuario final.

La razón por la que siento que es necesaria una reescritura es que cuando necesitamos actualizarlo (lo cual es cierto que no es tan frecuente), se tarda una eternidad en revisar todo el código espagueti y solucionar los problemas. Además, agregar nuevas funciones también es un problema, ya que se diseñó y codificó mal.

Realicé un análisis de costos para ellos en mantenimiento, pero están dispuestos a gastar más en los pequeños trabajos de mantenimiento que en una reescritura. ¿Alguna sugerencia para convencerlos de lo contrario?

17
Wil

Creo que hay dos factores que debe considerar que al menos no cubrió en su Q. Permítame definirlos a medida que los uso, luego me ocuparé de responder su Q.

  1. Riesgo
  2. Oportunidad costo

El riesgo es probablemente obvio: la posibilidad de que apilen una montaña de dinero en algo que no va a ninguna parte. El riesgo se ve agravado por lo que Brooks llamó "Efecto del segundo sistema" y el resto de nosotros llamamos "Chapado en oro". Cada reconstrucción que he visto conlleva el riesgo de las personas que agregan todas las funciones que no agregaron la primera vez.

El costo de oportunidad en este contexto es el costo asociado con la reescritura de la funcionalidad que, desde la perspectiva comercial, estaba funcionando bien. Es el costo de oportunidad porque significa que no tiene la oportunidad de agregar funciones.

Vender algo que es puramente una refactorización es difícil porque tanto el riesgo como el costo de oportunidad tienen dinero adjunto desde la perspectiva de la toma de decisiones. Lo que generalmente recomiendo es que en lugar de vender una reescritura del sistema, venda un "mejora sobre la marcha" a nivel de componente. Cuesta más porque tiene que construir adaptadores/fachadas/proxies, pero es menos riesgoso y más fácil de vender. He estado allí en el "tenemos que reconstruirlo todo" y simplemente no va bien.

Y aquí está el problema: con el tiempo, todos los sistemas se convierten en basura a menos que seas lo suficientemente disciplinado para evitar que lo hagan.

Lo que me deja con esta pregunta de vuelta a usted: si no puede venderlos, o incluso a su equipo, haciendo lo correcto día a día, ¿qué le hace pensar que realmente puede ver una reescritura?

Realmente se necesita una seria introspección para responder esa pregunta con honestidad. A veces le han entregado un sistema de alguien que no tenía ni idea. A veces, alguien que comenzó con las mejores intenciones y con el pie derecho le entregó un sistema, pero que se vio comprometido por una mala cultura corporativa en el camino. Si no puede saber cuál es, ¡debe averiguarlo pronto!

22
MIA

Aquí hay algunas ideas, todas las cuales he hecho más de una vez.

  1. Nada triunfa como el éxito: ven con él algún día. Una de las razones clave por las que se rechazan las cosas es que los tomadores de decisiones sienten que no va a ser mucho mejor después, o que es probable que no pueda hacerlo. Si puede reunir una prueba de concepto convincente y mostrársela, es más fácil venderla.

Algunas de las mejores cosas que he escrito comenzaron como proyectos furtivos. Las cosas que la gente decía no eran posibles. Otro que escucho mucho es, "gente más inteligente que tú lo ha intentado y ha fallado". Cuando te presentas con una prueba de concepto convincente, prácticamente diezma esos argumentos.

No puedo decirte cuántas veces la gente se ha negado a dejarme trabajar en un proyecto, rechazando todos los argumentos razonables, sin escuchar nada de ellos. Luego les muestro una demostración, y de repente piensan que el proyecto es una gran idea. Pero ten cuidado: cuanto más presiones a alguien y más insisten en que la respuesta es no, debes tener cuidado: deben tener una forma honorable de cambiar de opinión sin resentirse contigo por ello o sin sentirse mal. Así que sea diplomático, idealmente trate de hacerles pensar que fue idea suya. o tener una buena relación con ellos, alternativamente.

La clave para una gran demostración es la planificación. No empiece por pensar en cuál debería ser el producto. Empiece por pensar en cómo sería la demostración más impresionante. Tienes que hacer suficiente ingeniería para que tu demostración no sea solo vaporware puro, pero lo que quieres implementar primero es lo que sea necesario para hacer que la demostración se mueva en sus calcetines.

  1. Abre nuevas posibilidades con el nuevo diseño. Había un sistema que reescribí que se ajustaba exactamente a tu situación. Fue un dolor terrible trabajar en el sistema. No teníamos que cambiarlo muy a menudo, pero cuando lo hacíamos, me dolía el alma y me daban ganas de llorar. El sistema estaba escrito en VB.Net y tenía toda la lógica empresarial intercalada en todo el código GUI (que era una aplicación .NET de gran peso). La gerencia no quiso rehacerlo. Rehice el backend usando un servicio web y luego mostré cómo hacerlo nos permitiría agregar más de una interfaz de usuario al producto. Este fue un producto para la gestión de llamadas telefónicas en centros de llamadas. Vendí la idea a la gerencia mostrándoles una maqueta que funcionaba tanto en un sitio web como en un teléfono inteligente. Inmediatamente comenzaron a pensar en otros tipos de productos nuevos que podrían usar al tener múltiples interfaces de usuario en esto.

  2. Establezca una cabeza de playa/No se coma el elefante de una vez: construya su sistema perfecto poco a poco. Dedique un poco de tiempo a imaginarse cómo sería su sistema ideal. Visualice cuál es esa arquitectura. Dibuja un diagrama de bloques en una hoja de papel y guarda esa imagen en tu mente. Luego, la próxima vez que necesite arreglar algo, intente construir una pieza de ese sistema ideal. Luego puede construir un adaptador que le permitirá conectarlo al sistema anterior. El adaptador aislará su hermosa pieza nueva de los feos caprichos del viejo código de mierda. Pieza a pieza, puede reemplazar todo el sistema de esa manera. La primera pieza es la más difícil: es como establecer una cabeza de playa en territorio enemigo. Pero una vez que se establece su cabeza de playa, avanzar se vuelve progresivamente más fácil.

Por ejemplo, teníamos este enorme cuerpo de código escrito en PHP un lugar donde trabajé. Mi equipo y yo queríamos usar Python, pero la gerencia no quería financiarnos para hacer eso. comenzamos a agregar nuevas funciones usando un servicio web Python, y usando curl para acceder a las de PHP. No fue una reescritura total, pero una vez que construimos las instalaciones para facilitar la integración de las bases de código, había establecido una cabeza de playa, pudimos mover el resto hacia adelante más fácilmente desde allí.He hecho lo mismo con los sistemas heredados de perros en lenguajes como COBOL y RPG/3, llamando a Java.

14
Unoti

Piense con mucho cuidado antes de volver a escribir. Lea la publicación del blog de Joel Spolsky, Cosas que nunca debe hacer.

Hay una razón sutil por la que los programadores siempre quieren desechar el código y empezar de nuevo. La razón es que piensan que el código antiguo es un desastre. Y aquí está la observación interesante: probablemente estén equivocados . La razón por la que piensan que el código antiguo es un desastre se debe a una ley fundamental y cardinal de la programación:

Es más difícil leer código que escribirlo.

Es por eso que la reutilización de código es tan difícil. Esta es la razón por la que todos en su equipo tienen una función diferente que les gusta usar para dividir cadenas en matrices de cadenas. Escriben su propia función porque es más fácil y divertido que averiguar cómo funciona la función anterior ...

La idea de que el código nuevo es mejor que el antiguo es evidentemente absurda. Se ha utilizado código antiguo . Ha sido probado . Se han encontrado muchos errores y se han corregidos . No tiene nada de malo. No adquiere errores simplemente por sentarse en su disco duro. ¡Au contraire, bebé! ¿Se supone que el software es como un viejo Dodge Dart, que se oxida simplemente sentado en el garaje? ¿Es el software como un oso de peluche que es un poco asqueroso si no está hecho de todo el material nuevo ?

... Es importante recordar que cuando empiezas de cero no hay absolutamente ninguna razón para creer que vas a hacer un mejor trabajo del que hiciste la primera vez. En primer lugar, probablemente ni siquiera tenga el mismo equipo de programación que trabajó en la versión uno, por lo que en realidad no tiene "más experiencia". Simplemente volverá a cometer la mayoría de los viejos errores e introducirá algunos problemas nuevos que no estaban en la versión original.

El viejo mantra construir uno para tirar es peligroso cuando se aplica a aplicaciones comerciales a gran escala. Si está escribiendo código de forma experimental, es posible que desee romper la función que escribió la semana pasada cuando piense en un algoritmo mejor. Esta bien. Es posible que desee refactorizar una clase para que sea más fácil de usar. Eso también está bien. Pero tirar todo el programa es una locura peligrosa ...

14
grokus

Tuve la oportunidad de una reescritura completa dos veces (trabajos diferentes).

La primera fue una aplicación bastante pequeña. Se estimó que la reescritura llevaría seis meses a dos programadores. Cumplimos con el plazo y el cliente estaba muy contento. Desafortunadamente, a pesar de la demanda, marketing abandonó la aplicación, por lo que el esfuerzo fue en vano.

La segunda fue la aplicación principal de una pequeña empresa. La reescritura fue completamente subestimada y casi arruinó la empresa. Al final, el proyecto fue un éxito.

El problema con las reescrituras es que no agrega ninguna funcionalidad a la aplicación. Lo que significa que es difícil de vender. Así que es mejor reescribir piezas pequeñas en cada momento. Refactorización ++.

4
Toon Krijthe

No vuelva a escribir: los riesgos y costos son demasiado altos para su negocio. Consulte el artículo de Joel Spolsky al que hace referencia @Grokus para conocer las razones.

Ofrezco una opción alternativa: una combinación de refactorización del código que sea adecuado más la introducción de una tecnología complementaria. Por ejemplo, comience a escribir nuevas páginas en ASP.NET, migrando gradualmente más y más código al mundo .NET. Lo hemos hecho con éxito: las nuevas funciones son una gran oportunidad para hacerlo, pero las partes más simples del sistema que se pueden migrar rápidamente también son candidatas. Puede ser necesario inventar algún nivel de abstracción o una especie de sistema puente (agregar una capa de API al sistema "antiguo") para llegar allí.

Solo usted puede tomar la decisión de optar por MVC + AJAX, MVC + SilverLight/Flash o similar, pero no tiene que estacionar nada antes de seguir adelante.

Sí, habrá algo de dolor y confusión en el camino, pero tendrá un producto que se puede enviar todo el tiempo, en lugar de un largo, largo, largo tiempo 'en desarrollo' con un producto establecido que se volverá obsoleto y perderá participación de mercado en competidores.

3
JBRWilkinson

¿Te refieres a venderlo a t negocio, como para convencer a los gerentes de que lo hagan? Desafortunadamente, no hay truco de magia para hacer que los gerentes que ven todo a corto plazo reconozcan los problemas a largo plazo. Especialmente si no son técnicos, es posible que no aprecien las razones técnicas de tal cosa. Lo mejor que puede hacer es lo que ya ha hecho: demostrar que es lo correcto financieramente. Si no lo hacen, no hay mucho que pueda hacer más que sentarse y ver cómo las cosas implosionan.

Por otro lado, si se refiere a cómo se lo vende a un cliente que es una empresa, es fácil. Vuelva a escribir la cosa y dígales que si quieren la característica X, deben usar el nuevo sistema. A veces, para ayudar a un cliente, necesitas un poco de cariño.

2
GrandmasterB

Primero, cree una categoría para los cambios típicos en términos de SLOC (y puntos de función si implica cambios en los elementos de la IU).

Luego, observe los cambios de código anteriores y vea dónde encajan en el modelo de categoría descrito anteriormente.

Haga lo mismo con las nuevas características (es decir, trate los cambios de código y las nuevas características de manera diferente a menos que una nueva característica implique un cambio/costo significativo en la base de código existente). Si la integración de una nueva característica es trivial, sepárela de los cambios de código. Si su integración con la base de código existente es significativamente costosa, agréguela con los cambios de código.

Luego, para cada cambio de código categorizado (o nueva característica), determine 1) cuánto tiempo tardó en completarse, 2) cuánto tiempo se suponía que debía completar, - ) cuántas personas participaron realmente en la finalización, y 4) cuántas personas se pensó inicialmente que serían necesarias para su finalización.

Por lo tanto, ahora debería tener una presentación tabular de los artefactos entregados (cambios de código y nuevas funciones), cada uno con columnas que indican los recursos estimados y reales (horas, personas) consumidos.

Luego puede asumir un salario promedio por hora de ingeniero (digamos $ 40/hora). Multiplique eso por 2 para indicar el costo total del ingeniero/hora (una estimación del salario por hora, electricidad, servicios de oficina y alquiler, etc.). No tiene que ser preciso, solo lo suficientemente realista.

Para cada artefacto entregado [~ # ~] a [~ # ~] , puede calcular lo siguiente:

estimated_cost(A) := avg_hr_salary * estimated_hours(A) * estimated_people(A)

approx_cost(A) := avg_hr_salary * (actual_hours(A) + estimated_hours(A))/2 * (actual_people(A) + estimated_people(A)/2

max_cost(A) := avg_hr_salary * actual_hours(A) * actual_people(A)

Con estas relaciones (que deben basarse en cambios de código reales o elementos nuevos ... de lo contrario, no tienen sentido), puede calcular (por tamaño de categoría), cuál es el% de un cambio de código de ese tamaño para desviarse del tamaño estimado (un% de falla), el costo aproximado así como el% del cambio de código podría llegar a un máximo. costo.

Es probable que el porcentaje de desviación máxima del costo estimado (mínimo) se asemeje cada vez más a una distribución exponencial cuanto mayor sea el cambio de código.

Con esa fecha, puede decirle a su cliente lo siguiente:

Usted con su cliente:

Este cambio que está solicitando (A) podría requerir 10K SLOC, en la base de código anterior. Los datos históricos indican que podrían necesitarse 2 personas como mínimo (estim_personas), posiblemente aumentando hasta 3 personas (personas_actual). La probabilidad del cambio al costo (estimado_cost) es A%; B% para approx_cost y% C para max_cost.

Ahora, esta es la clave. Tiene que hacer los mismos cálculos para nuevas solicitudes (el tipo cuya integración con el código base antiguo implica cambios no significativos en el posterior).

Si encuentra que los costos estimados, aproximados y máximos para nuevas solicitudes de un tamaño determinado son (con suerte) significativamente menores que los costos de los cambios de base de código antiguos de el mismo tamaño, [~ # ~] luego [~ # ~] tienes un argumento para reescribir el código. Ha proporcionado suficiente evidencia de que la base de código anterior es costosa de cambiar en comparación con cambios de la misma magnitud en el nuevo código.

Pero si los costos de las nuevas solicitudes de código no difieren mucho de los cambios de código antiguos de la misma magnitud, tendrá dificultades para justificar una reescritura de código (y podría indicar que los problemas no son solo para la base del código, sino también en sus prácticas de desarrollo.)

2
luis.espinal

Si es posible, haga lo que pueda para mejorar la aplicación tal y como está ahora.

Si no está satisfecho con la documentación, después de haber pasado tiempo averiguando las cosas ESCRÍBELAS para la próxima sesión de mantenimiento. Con frecuencia, cuando ve una base de código por primera vez, solo una breve lista de "por lo tanto" (para responder a los por qué el código no puede) puede ayudar a comprender inmensamente lo que sucede.

¡Mejore gradualmente!

1
user1249

Encuentra una manera de hacerlo poco a poco.

Si intentas reescribir todo desde cero, probablemente nunca lo lanzarás.

Si los trozos del tamaño de un bocado son lo suficientemente pequeños, es posible que ni siquiera necesite venderlos a la empresa: es posible que pueda simplemente seguir adelante mientras implementa nuevas funciones.

0
Bill Michell