Quando alguém desistiria da compatibilidade com versões anteriores em favor da implementação nova e aprimorada da interface? [fechadas]

Trabalho na mesma empresa de software há mais de dez anos. Como resultado, implementei uma grande base de código usando várias linguagens de programação orientadas a objetos. Eu era um programador iniciante quando comecei minha carreira e não sabia muito sobre os bons princípios de interface e design de classe. Gostaria de pensar que minhas habilidades de design melhoraram com o tempo, mas agora tenho mais e mais dificuldades em melhorar meu código anterior devido a preocupações de compatibilidade com versões anteriores. Meu código é usado por um grande número de clientes como parte dos produtos que minha empresa vende.

Minha pergunta é: quando parar de tentar manter a compatibilidade com versões anteriores de interfaces antigas e morder a bala em favor da implementação de um novo design?

Acho que chega um momento em que manter a compatibilidade com versões anteriores se torna um fardo tão grande que alterações úteis nas interfaces se tornam impossíveis. Alguém já experimentou preocupações semelhantes, quem pode fornecer algum feedback?

Embora 'quando' seja uma boa pergunta, acho que 'como' é ainda mais relevante. Pode ser difícil fazer uma transição de ruptura de uma maneira que não deixe os usuários frustrados ou infelizes. Alguns itens a serem considerados:

• Comunique-se com seus clientes bem antes de qualquer transição. Explique por que e como será implementado. Citar segurança, desempenho, estabilidade e flexibilidade futura como razões são válidas.
• Se você estiver fazendo uma pausa limpa de qualquer maneira, solicite feedback.
• Se houver algum desenvolvedor de terceiros, inclua as entradas deles na medida do possível.
• Se possível, forneça uma camada de compatibilidade.
• Forneça um guia abrangente de atualização.
• Faça a atualização o mais fácil e indolor possível. Minimize a dor dos usuários, mesmo que isso signifique um pouco mais de trabalho para você.
• Se você cobrar, ofereça um desconto para atualizações para a nova versão.
• Adicione pelo menos alguns recursos novos e úteis em uma nova versão para incentivar a atualização. Isso é especialmente importante para tornar a atualização mais atraente para os gerentes.
• Se você fizer uma pausa, faça a última vez que precisar. Isso significa algum planejamento abrangente com antecedência e garantir que tudo esteja configurado corretamente.
• Se você possui uma interface do usuário, faça alterações com facilidade. Pense em atualizar em vez de redesenhar. Para usuários não técnicos, mudanças drásticas na interface do usuário de uma versão para outra podem ser um grande motivo de frustração.
• Sua nova versão deve ser visivelmente mais estável e com desempenho do que a antiga. Não dê aos usuários motivos para se ressentirem da atualização. Não libere uma nova versão sem testes extensivos previamente (unidade, integração e teste beta).
• Mantenha a versão antiga simultaneamente por um longo período de tempo. Se você decidir desativá-lo e interromper o suporte, avise com antecedência de pelo menos 6 a 12 meses, mais se puder.
• Você pode manter duas versões ao mesmo tempo em termos de finanças e mão de obra? (Além disso, do ponto de vista comercial, você não deve interromper o suporte à versão antiga até ter a possibilidade de perder os clientes restantes que se apegam à versão antiga e que não desejam atualizar. Esse ponto deve ser o momento em que seus custos de mantê-lo supera seus lucros.)
• Comprometa-se a fazer atualizações de segurança por um período após a descontinuação da versão antiga, se necessário.
• Mais uma vez, a comunicação é enorme durante todo o processo. Não deixe seus usuários / clientes / clientes se sentindo abandonados a qualquer momento. Sua lealdade e paixão são a base do seu negócio. Certifique-se de responder às perguntas deles no seu blog ou nos seus fóruns. O fator social não deve ser subestimado.

Quanto ao 'quando', você provavelmente terá uma idéia melhor para sua aplicação do que qualquer outra pessoa. Em geral, no entanto, pode ser hora de uma pausa limpa quando sua dívida técnica e arquitetura inibem completamente a estabilidade, impedem um desempenho razoável e tornam o desenvolvimento de novos recursos impressionantes ou desnecessariamente difíceis.

Tudo isso dito, não dê esse passo de ânimo leve. Mesmo bem, quebrar a compatibilidade com versões anteriores é um grande problema. Você deve considerar fortemente aumentar sua cobertura de teste e refatorar primeiro e, se possível, antes de considerar uma pausa.

Em geral, eu concordo com James Anderson. Na minha experiência, há, no entanto, aspectos adicionais que merecem consideração e que podem apontar para uma opção que de fato permite interfaces em evolução.

Este exemplo é de uma das equipes com as quais estou trabalhando. Eles enviam um produto regularmente, pelo menos uma vez por mês, às vezes até semanalmente. Os clientes são encorajados a atualizar, pois novos recursos e novas plataformas são suportadas apenas em versões mais recentes. A atualização é fácil e os clientes podem até pular as versões intermediárias. O downgrade não é suportado. Além disso, as versões são suportadas apenas por 3 anos. Depois disso, há um período de carência de um ano em que as taxas de manutenção dobram.

Como resultado, a grande maioria - cerca de 95% dos clientes - atualiza regularmente, pelo menos uma vez por ano. Isso também significa que você pode introduzir gradualmente novas interfaces.

E as interfaces antigas? A técnica que essa equipe usa está declarando interfaces antigas como 'fim da vida útil'. Depois, há um período de 12 meses em que a nova interface está disponível e a interface antiga ainda não foi retirada. As novas interfaces oferecem melhores recursos do que a interface antiga, portanto existem dois incentivos: o fim da vida útil da interface antiga e a nova interface, muito melhor.

A interface antiga concreta nesse caso era uma tecnologia específica da plataforma que está sendo substituída gradualmente por uma interface de serviço baseada na tecnologia convencional padrão.

É claro que essa mudança não acontece durante a noite e leva muitos anos até a conclusão. Mas permitiu interromper o investimento na tecnologia antiga e, em vez disso, investir na nova tecnologia. O cliente recebe assistência e tem um caminho a seguir. A maioria deles também está acolhendo a mudança para novas tecnologias.

Porém, lembre-se de que essa abordagem específica pode não funcionar no seu cenário. Certamente funciona para a equipe com a qual estou trabalhando.

Você já tem boas respostas aqui, portanto, gostaria de adicionar um ponteiro a um artigo muito agradável de Joel Spolsky sobre esse tópico. Ele está discutindo os planos de desistir da compatibilidade com versões anteriores no IE 8, que é essencialmente o mesmo que seu problema:

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

A resposta curta é Nunca!

A experiência mostra que a redução da compatibilidade com versões anteriores, no mínimo, irrita clientes e usuários e, na pior das hipóteses, os perde completamente.

Se você está pedindo aos usuários que reescrevam o código, depois que eles terminarem a maldição habitual de você e de todos os seus descendentes, eles pensarão: "Se eu tiver que reescrever de qualquer maneira, talvez eu deva mudar para a agradável biblioteca ACME que tenho lido tanto sobre? ".

O truque é aprimorar a interface atual de maneira que não prejudique a compatibilidade com versões anteriores ou oferecer uma interface totalmente nova, brilhante e obviamente superior, mantendo a interface mais antiga. Em algum momento, haverá recursos na nova interface que simplesmente não serão possíveis na interface antiga, mas isso apenas incentivará as pessoas a se mudarem, sem forçar o problema.

Edite para esclarecer isso ainda mais.

O que você, como programador, pensa é:

"Melhorarei esta API e tornarei o sistema o melhor possível e todos me admirarão".

O que os usuários da sua API pensam é:

"A * * * e ele acha que meu tempo e horário não são importantes. Eu tenho que parar o que estou fazendo e refatorar todo o meu código por nenhuma outra razão senão satisfazer o ego dele. Se eu tiver que refatorar, vou mudar para outra API apenas para colocá-lo também ele ".

Esta é realmente mais uma decisão comercial do que técnica. Geralmente, isso é feito como parte de um release principal (por exemplo, passando da versão 3.5 para a versão 4.0), e geralmente as duas versões são suportadas em paralelo por algum tempo. Isso significa que você fará manutenção na versão antiga, mas todos os novos recursos aparecerão apenas na nova versão. A versão antiga é suportada desde que a empresa lucre com ela, ou pelo menos o suficiente para compensar os custos de manutenção. Esteja preparado para apresentar isso à gerência.

Estive do lado do cliente, por isso diria que realmente depende do que você planeja fazer sobre a transição.

No momento, estamos atualizando nosso sistema de contas. A empresa que está fazendo a atualização também suporta a versão incompatível anterior. Eles planejam pegar os dados e movê-los para o novo sistema para que (em teoria) todos os dados antigos estejam lá. Pagaremos algumas centenas de libras pela conversão de dados. Sem problemas.

Compare com uma situação anterior em outra empresa em que trabalhei. O fornecedor não tinha como fazer a transição dos sistemas antigos para os novos. Isso os colocou na mesma situação que qualquer outro fornecedor. De fato, a situação deles era pior porque sabíamos que eles não estavam comprometidos em nos ajudar com as atualizações. Eles não receberam o novo contrato.

Você fez o trabalho duro para obter e manter clientes, como pode facilitar a transição?