¿Cuándo se renunciaría a la compatibilidad con versiones anteriores en favor de una implementación de interfaz nueva y mejorada? [cerrado]

He trabajado en la misma compañía de software durante más de diez años. Como resultado, he implementado una gran base de código usando varios lenguajes de programación orientados a objetos. Era un programador principiante cuando comencé mi carrera y no sabía mucho sobre una buena interfaz y principios de diseño de clase. Me gustaría pensar que mis habilidades de diseño han mejorado con el tiempo, pero ahora me enfrento a más y más dificultades para mejorar mi código anterior debido a problemas de compatibilidad con versiones anteriores. Mi código es utilizado por una gran cantidad de clientes como parte de los productos que vende mi empresa.

Mi pregunta es: ¿cuándo debería uno dejar de tratar de mantener la compatibilidad con versiones anteriores de las interfaces antiguas y morder la viñeta a favor de implementar un diseño completamente nuevo?

Creo que llega un punto en el que mantener la compatibilidad con versiones anteriores se convierte en una carga tan grande que los cambios útiles en las interfaces se vuelven imposibles. ¿Alguien ha experimentado inquietudes similares, quién puede proporcionar algún comentario?

Si bien 'cuándo' es una buena pregunta, creo que 'cómo' es aún más relevante. Puede ser difícil hacer una transición de ruptura de una manera que no haga que los usuarios se sientan frustrados o infelices. Algunos elementos a considerar:

• Comuníquese con sus clientes / clientes mucho antes de cualquier transición. Explica por qué y cómo se implementará. Citando la seguridad, el rendimiento, la estabilidad y la flexibilidad futura como razones son todas válidas.
• Si de todos modos está haciendo una pausa limpia, solicite comentarios.
• Si hay desarrolladores de terceros, asegúrese de incluir sus aportes también en la medida en que tenga sentido.
• Si es posible, proporcione una capa de compatibilidad.
• Proporcionar una guía de actualización completa.
• Haga que la actualización sea lo más fácil e indolora posible. Minimice el dolor de sus usuarios, incluso si eso significa un poco más de trabajo para usted.
• Si cobra, ofrezca un descuento por actualizaciones a la nueva versión.
• Agregue al menos algunas características nuevas y útiles en una nueva versión para incentivar la actualización. Esto es especialmente importante para que la actualización sea más atractiva para los gerentes.
• Si hace un descanso, hágalo la última vez que lo necesite. Eso significa una planificación exhaustiva por adelantado y asegurarse de que todo esté configurado correctamente.
• Si tienes una interfaz de usuario, no te preocupes por los cambios. Piense en actualizar en lugar de rediseñar. Para usuarios no técnicos, los cambios drásticos en la interfaz de usuario de una versión a otra pueden ser una gran causa de frustración.
• Su nueva versión debería ser notablemente más estable y eficiente que la anterior. No les dé a sus usuarios una razón para resentir la actualización. No publique una nueva versión sin pruebas exhaustivas de antemano (unidad, integración y pruebas beta).
• Mantenga la versión anterior simultáneamente durante un período prolongado de tiempo. Si decide eliminarlo gradualmente y descontinuar el soporte, avise con al menos 6 a 12 meses de anticipación, más si puede.
• ¿Puede permitirse mantener dos versiones a la vez en términos de finanzas y mano de obra? (Además, desde una perspectiva comercial, no debe detener el soporte de la versión anterior hasta que pueda permitirse perder los clientes restantes que se aferran a la versión anterior y no desean actualizar. Ese punto debería ser cuando sus costos de mantenerlo supera sus ganancias de él.)
• Comprométete a realizar actualizaciones de seguridad por un período de tiempo después de que la versión anterior haya sido descontinuada si es necesario.
• Nuevamente, la comunicación es enorme durante todo el proceso. No deje que sus usuarios / clientes / clientes se sientan abandonados en ningún momento. Su lealtad y pasión es la base de su negocio. Asegúrese de responder a sus preguntas en su blog o en sus foros. El factor social no debe subestimarse.

En cuanto al 'cuándo', probablemente tendrá una mejor idea para su aplicación que cualquier otra persona. En general, sin embargo, podría ser el momento de un descanso limpio cuando su deuda técnica y su arquitectura inhiban completamente la estabilidad, eviten un rendimiento razonable y hagan que el desarrollo de nuevas funciones sea abrumador o innecesariamente difícil.

Todo lo dicho, no des este paso a la ligera. Incluso bien hecho, romper la compatibilidad con versiones anteriores es un gran problema. Debe considerar aumentar su cobertura de prueba y refactorizar primero y, si es posible, antes de considerar un descanso.

En general estoy de acuerdo con James Anderson. Sin embargo, en mi experiencia, hay aspectos adicionales que pueden merecer consideración y que pueden apuntar hacia una opción que de hecho permita interfaces en evolución.

Este ejemplo es de uno de los equipos con los que estoy trabajando. Envían un producto de forma regular, al menos una vez al mes, a veces incluso semanalmente. Se alienta a los clientes a actualizar, ya que las nuevas funciones y las nuevas plataformas solo son compatibles con las versiones más recientes. La actualización es fácil y los clientes pueden incluso saltear versiones intermedias. La degradación no es compatible. Además, las versiones solo son compatibles durante 3 años. Después de eso, hay un período de gracia de un año cuando las tarifas de mantenimiento se duplican.

Como resultado, la gran mayoría, aproximadamente el 95% de los clientes, se actualiza regularmente, al menos una vez al año. Esto también significa que puede introducir gradualmente nuevas interfaces.

¿Qué hay de las viejas interfaces? La técnica que utiliza este equipo es declarar interfaces antiguas como 'fin de vida útil'. Luego hay un período de 12 meses en el que la nueva interfaz está disponible y la interfaz anterior aún no se ha retirado. Las nuevas interfaces ofrecen mejores características que la interfaz anterior, por lo que hay dos incentivos: la interfaz anterior al final de la vida útil y la nueva interfaz son mucho mejores.

La interfaz antigua concreta en este caso era una tecnología específica de plataforma que está en proceso de ser reemplazada gradualmente por una interfaz de servicio basada en tecnología estándar estándar.

Por supuesto, este cambio no ocurre durante la noche y lleva muchos años hasta su finalización. Pero permitió detener la inversión en la vieja tecnología y, en cambio, invertir en la nueva tecnología. Los clientes reciben asistencia y tienen un camino a seguir. La mayoría de ellos también agradecen el avance hacia una tecnología más nueva.

Sin embargo, tenga en cuenta que este enfoque particular puede no funcionar en su escenario. Ciertamente funciona para el equipo con el que estoy trabajando.

Ya obtuvo algunas buenas respuestas aquí, por lo que me gustaría agregar un puntero a un muy buen artículo de Joel Spolsky sobre este tema. Está discutiendo los planes de renunciar a la compatibilidad con versiones anteriores en IE 8, que es esencialmente el mismo que su problema:

http://www.joelonsoftware.com/items/2008/03/17.html

¡La respuesta corta es nunca!

La experiencia muestra que dejar caer la compatibilidad con versiones anteriores al menos molesta a los clientes y usuarios y, en el peor de los casos, los pierde por completo.

Si le está pidiendo a sus usuarios que reescriban el código, después de que hayan terminado de maldecirlo a usted y a todos sus descendientes, pensarán "Si tengo que volver a escribir de todos modos, tal vez debería cambiar a esa biblioteca ACME que he estado leyendo tanto sobre? "

El truco consiste en mejorar la interfaz actual de tal manera que no rompa la compatibilidad con versiones anteriores o en ofrecer una interfaz completamente nueva, brillante y obviamente superior, manteniendo la interfaz anterior. En algún momento, habrá nuevas funciones en la nueva interfaz que simplemente no serán posibles en la interfaz anterior, pero esto solo da a las personas un incentivo para moverse, sin forzar el problema.

Edite para aclarar esto aún más.

Lo que usted como programador piensa es:

"Mejoraré esta API y haré que el sistema sea lo mejor posible y todos me admirarán".

Lo que pensarán los usuarios de su API es:

"A * * * e él piensa que mi tiempo y mi horario no son importantes. Tengo que dejar lo que estoy haciendo y refactorizar todo mi código por ninguna otra razón que no sea satisfacer su ego. Si tengo que refactorizar, entonces voy a cambiar a otra API solo para pegarlo también a él ".

Esto es realmente más una decisión comercial que técnica. Por lo general, esto se hace como parte de una versión principal (por ejemplo, pasar de la versión 3.5 a la versión 4.0), y a menudo las dos versiones son compatibles en paralelo durante un tiempo. Esto significa que hará el mantenimiento de la versión anterior, pero todas las características nuevas solo aparecerán en la nueva versión. La versión anterior es compatible siempre que la empresa gane dinero con ella, o al menos lo suficiente como para compensar los costos de mantenimiento. Esté preparado para presentar esto a la gerencia.

He estado en el lado del cliente de este, así que diría que realmente depende de lo que planeas hacer con la transición.

Actualmente estamos actualizando nuestro sistema de cuentas. La compañía que realiza la actualización también es compatible con la versión incompatible anterior. Planean tomar los datos y moverlos al nuevo sistema para que (en teoría) todos los datos antiguos estén allí. Pagaremos un par de cientos de libras por la conversión de datos. No hay problema.

Compare con una situación anterior en otra empresa para la que trabajé. El proveedor no tenía forma de pasar de los sistemas antiguos a los nuevos. Esto los puso en la misma situación que cualquier otro proveedor. De hecho, su situación era peor porque sabíamos que no estaban comprometidos a ayudarnos con las actualizaciones. No obtuvieron el nuevo contrato.

Has hecho el trabajo duro para conseguir y mantener clientes, ¿cómo puedes facilitar la transición?