Quando descartar um software legado?

[reinaldorauch]

Quando devemos abandonar o desenvolvimento de software legado e escrever uma aplicação do zero para o mesmo fim?

[alganet]

Vou dar minha opinião pessoal:

Um software pode descartado quando alguém tem coragem pra fazer isso e consegue. O PHP foi re-escrito várias vezes mantendo compatibilidade, o Linux teve vários drivers re-escritos mesmo sem testes unitários, a principal implementação de NTP foi re-escrita recentemente do zero, o Chrome tem uma engine nova que suporta JavaScript velho também. Sempre dá pra melhorar, e o melhor torna o anterior descartável.

Coragem sozinha não é suficiente, a pessoa precisa entender o sistema e conseguir abstraí-lo de uma forma que seja mais simples que manter a abstração atual.

Melhor também não é suficiente. É preciso ser melhor e compatível. Se o contexto é software livre, precisa ser compatível tecnicamente. Em uma empresa pode ser compatível com os interesses comerciais.

Várias coisas podem tornar um software melhor e compatível, e isso gera descarte de gerações anteriores de software. Ninguém mais usa o Bourne Shell original, usam alguma re-escrita compatível. Ninguém mais usa o vi original, usam alguma re-escrita compatível.

O legado ainda é inocente até que se prove o contrário, mas assim que se prova não há dúvida. Basta alguém escrever, ou provar um conceito, ou talvez codar um protótipo.

[iannsp]

Duas visões do mesmo problema: A começar pela questão comercial, se um software foi escrito e esta em uso, ele teve um custo e este custo foi planejado de acordo com seu rendimento financeiro, logo, antes de reescrever se pensa na questão de amortização do custo e do rendimento planejado para o software. Se o software já pagou a sua conta(o custo efetivo de desenvolvimento) então estão abertas as portas para reescrita. Se o software não é rentavel o suficiente para interessar ser totalmente redesenhado(a partir das experiencias geradas com os feedbacks dos clientes) então as portas se fecham e a reescrita não vai acontecer nunca.

E temos a questão técnica, reescrever um software não é algo a ser feito por que o programador quer, por que o gerente quer, por que a tecnologia ficou velha e etc. Reescrever um software é um caminho trilhado para oferecer beneficios que o atual codebase não oferece, seja por recursos de linguagem, seja por recursos da arquitetura futura perante a atual(novamente, reflexo dos feedbacks dos clientes e percepção dos analistas), talvez seja motivo de reescrita problemas como não encontrar mão de obra capaz de manter o codebase atual, não conseguir fazer upgrades da infraestrutura necessaria para roda-lo e etc.

A soma das questões comerciais e técnicas é quem diz se é possivel ou não e, a partir dai, eu acho perfeito o texto do @alganet.

[reinaldorauch]

Entendi. Muito boas as suas explicações, me ajudaram a pensar melhor sobre isso

[augustohp]

Concordo.

A visão de que o próximo software, a versão 2.0, vai ser a solução de todos os problemas beira a ilusão pra mim.

Além do efeito do segundo sistema citado no Míiiitico Homem-Mês, duvido que a equipe que assistiu a criação do legado seja capaz de escapar dele criando algo novo. O "algo novo" estará fadado ao mesmo destino quando exposto a prova do tempo se a cultura do time (produto e desenvolvimento) não mudar.

Acredito no lema da 37signals, do Getting real, de que menos software é mais. Antes de culpar o software legado, considere a hipótese de que existe muita funcionalidade ali que não é usada e que simplificar o legado (tanto código quanto funcionalidade) pode ser o caminho mais viável.

PS: Não deixe de ver as referências e links externos nos links da Wikipedia também. :wink: PPS: Falhei em não colocar um link direto pro Jargon file, mas eu precisava deixar a resposta mais concisa. :stuck_out_tongue_winking_eye:

[reinaldorauch]

Então, resumindo, o mais efetivo seria continuar trabalhando no legado de forma que ele evolua a ponto de ele não ser mais legado, mesmo que chegue ao ponto de reescrevê-lo completamente, evitando assim criar um novo software do zero?

[augustohp]

Então, resumindo, o mais efetivo seria continuar trabalhando no legado de forma que ele evolua a ponto de ele não ser mais legado, mesmo que chegue ao ponto de reescrevê-lo completamente, evitando assim criar um novo software do zero?

:+1:

Existem casos e casos, tentar chegar a uma solução pra todos eles é complicado, mas um time que tenha capacidade de manter um software por um longo período de tempo sem considerar ele ruim deve ser capaz de identificar a necessidade de novos sistemas ou de novas partes.

[fhgomes]

Um software que não tem NADA de testes unitários já seria motivo para reescrever? E se está em versões de frameworks atrasadas uns 2 anos?

[fhgomes]

Alganet , você comentou sobre protótipo, que acha que deveria ser descartado. Qual sua visão sobre um MVP? (talvez um MVP meio grandinho) A idéia de negócio é de ser um MVP.

Ainda sobre o tema MVP. Sabendo que existe uma possibilidade dessa ideia não ser validada no mercado e o código ser jogado fora. Até que ponto vale a pena investir em testes unitários nesse MVP? Também em questão de pesquisar novos frameworks para utilizar e fazer um código bonito.

Resumindo. Fazer um MVP com código "tripa" e depois reescrever caso der certo? Ou já fazer certo do começo para evoluir o código depois?

[reinaldorauch]

Bom, a opinião que formei é que depende de vários fatores, inclusive se a pessoa/time/organização gosta de aceitar mais riscos ou não, custos para se fazer isso, e como será feito isso: se é uma reescrita total, se vai parar totalmente a manutenção do legado ou se deverá ser mantido junto com a nova versão. Creio que devemos balancear as opiniões dos stakeholders e do dev team, pois satisfazendo um lado somente, não há produto viável comercialmente

[eportella]

Minha opinião é simples e direta, "quando vale a pena" e sempre cairemos nesta pergunta no final de tudo.

vale a pena fazer subir uma versão da minha base de dados? vale a pena atualizar meu server SO? vale a pena começar do zero com outra linguagem de programação?

minha opinião pessoal é sim sempre vale a pena tudo que for evolutivo. Evolução é saudável para nós como profissionais que nos manteremos atualizados, saudável para o próprio software que sempre será revisado "algo não visto é algo esquecido". Porém um software não é feito para ele mesmo ou para o desenvolvedor, é moldado para um produto, então eu refaço a pergunta.

Vale a pena o produto desta forma? Vale a pena $$$?

Abraços

[ghost]

Com todas as opiniões citadas aqui e no hangout, a que eu me identifico mais é a do @alganet. Na minha opinião, todo software, legado ou não, deve ser abandonado quando necessário. Quando ele se torna um deficit ao invés de lucro: em caso do software não é escalável, extrema dificuldade de manutenção e/ou mão de obra extremamente caro. Também quando há estratégia nova estratégia envolvida, quando digo estratégia não é necessariamente trata-se de regras de negócio.

Por exemplo: trabalho para uma grande companhia aérea, justamente no setor de inovação e desenvolvimento de sistemas, logo trabalho diretamente com softwares legados, e sua melhoria, ou o seu descarte. Temos aqui vários microssistemas, responsáveis por troca de mensagens entre diversos outros sistemas, torre de controle, aviões etc. Um dos principais software que temos é um que realiza um papel de "hub" é todo escrito em shellscript.

E apesar de sua simplicidade, sua arquitetura é muito boa e atende completamente as necessidades da empresa, é escalável e com uma manutenção simples e de baixo custo. Mesmo havendo um projeto para convertermos a solução para SOA a longo prazo. Porém, recentemente, a diretoria resolveu abandonar o mesmo e criar uma nova solução do zero, seguindo a mesma arquitetura em Java. Mas por qual motivo, se o sistema, mesmo em sua simplicidade, atende todos os requisitos? Porque a empresa responsável por realizar o suporte a aplicação só responsabiliza se o sistema for feito em Java. Neste caso mesmo, na minha opinião ele seguindo todos os requisitos se tornar um case de não abandono, devido a uma nova estratégia, o sistema será abandonado.

Então, reforçando a minha opinião, o sistema legado deve ser descartado, quando ele impede de alguma forma a estratégia da empresa, ou quando se torna um problema.

[netojoaobatista]

Link para o hangout Quando descartar um software legado

[alganet]

@fhgomes desculpa pela demora.

A diferença entre um protótipo e um MVP é que o protótipo é um experimento pra avaliar uma tecnologia. O MVP é um experimento para avaliar um modelo de negócio. Ambos são experimentos e na minha opinião são melhores se forem descartados.

Sendo mais direto: Tanto MVPs quanto protótipos são experimentos. Eles agregam conhecimento, não código. Eu acho melhor que eles sejam projetados de forma mínima e descartados em seguida em favor de um software feito com o conhecimento obtido.

Muitos modelos de negócio envolvem um primeiro produto que é tanto um protótipo quanto um MVP.