ti-enxame.com

Como posso vender a reescrita de um programa legado para a empresa?

Temos um clássico legado ASP aplicativo que existe desde 2001. Ele precisa urgentemente ser reescrito, mas está funcionando bem da perspectiva do usuário final).

A razão pela qual eu sinto que uma reescrita é necessária é que quando precisamos atualizá-la (o que não é tão frequente), leva uma eternidade para percorrer todo o código espaguete e corrigir os problemas. Além disso, adicionar novos recursos também é uma dor, pois foi arquitetado e codificado incorretamente.

Eu executei uma análise de custo para eles na manutenção, mas eles estão dispostos a gastar mais para os pequenos trabalhos de manutenção do que para reescrever. Alguma sugestão para convencê-los do contrário?

17
Wil

Acredito que haja dois fatores que você deve considerar e que pelo menos não abordou em seu Q. Deixe-me defini-los à medida que os uso e, em seguida, começarei a responder ao seu Q.

  1. Risco
  2. Oportunidade custo

O risco é provavelmente óbvio: a chance de eles empilharem uma montanha de dinheiro em algo que não vai a lugar nenhum. O risco é agravado pelo que Brooks chamou de "Efeito do Segundo Sistema" e o resto de nós chama de "Gold Plating". Cada reconstrução que eu vi traz riscos de pessoas que adicionam todos os recursos que não adicionaram da primeira vez.

Custo de oportunidade, neste contexto, é o custo associado à reescrita de uma funcionalidade que, do ponto de vista do negócio, estava funcionando bem. É o custo de oportunidade porque significa que você não tem a oportunidade de adicionar recursos.

Vender algo que é puramente um refatorador é difícil porque o Risco e o Custo de Oportunidade têm dinheiro vinculado a eles do ponto de vista da tomada de decisão. O que geralmente recomendo é que, em vez de vender uma reescrita do sistema, você venda uma "melhoria à medida que avança" em um nível de componente. Custa mais porque você precisa construir adaptadores/fachadas/proxies, mas é menos arriscado e mais fácil de vender. Eu estive lá no "precisamos reconstruir tudo" e simplesmente não vai bem.

E aqui está o problema: com o tempo, todos os sistemas se transformam em lixo, a menos que você seja disciplinado o suficiente para impedi-los de fazer isso.

O que me deixa com esta pergunta de volta para você: se você não pode vendê-los, ou mesmo sua equipe, sobre fazer a coisa certa no dia a dia, o que o faz pensar que pode realmente ver uma reescrita?

Realmente é preciso muita introspecção para responder a essa pergunta honestamente. Às vezes, você recebeu um sistema de alguém que não tinha ideia. Às vezes, você recebeu um sistema de alguém que começou com a melhor das intenções e com o pé direito, mas foi comprometido por uma cultura corporativa pobre ao longo do caminho. Se você não sabe qual é, você precisa descobrir logo!

22
MIA

Aqui estão algumas ideias, todas as quais fiz mais de uma vez.

  1. Nada é bem-sucedido como o sucesso: apareça um dia. Um dos principais motivos pelos quais as coisas são recusadas é que os tomadores de decisão sentem que não vai ficar muito melhor depois disso, ou que provavelmente você não será capaz de realmente fazer isso. Se você puder montar uma prova de conceito convincente e mostrá-la a eles, será mais fácil vendê-la.

Algumas das melhores coisas que já escrevi começaram como projetos furtivos. Coisas que as pessoas diziam não eram possíveis. Outra que ouço muito é: "Pessoas mais espertas do que você tentaram e falharam". Quando você apresenta uma prova de conceito convincente, praticamente dizima esses argumentos.

Eu não posso te dizer quantas vezes as pessoas negaram me deixar trabalhar em um projeto, rejeitando todos os argumentos razoáveis, apenas ouvindo nada. A seguir, mostro uma demonstração e, de repente, eles acham que o projeto é uma ótima ideia. Mas tome cuidado: quanto mais você irrita alguém e quanto mais eles insistem que a resposta é não, você precisa ter cuidado: eles devem ter uma maneira honrosa de mudar de ideia sem se ressentir ou se sentir mal por isso. Portanto, seja diplomático e, de preferência, tente fazê-los pensar que a ideia foi deles. ou ter um bom relacionamento com eles, alternativamente.

A chave para uma grande demonstração é o planejamento. Não comece pensando em como deve ser o produto. Comece pensando em como seria a demonstração mais incrível. Você tem que fazer engenharia suficiente para que seu demo não seja apenas um vaporware puro, mas o que você deseja implementar primeiro é o que for necessário para fazer aquele demo arrasar em suas meias.

  1. Abra novas possibilidades com o novo design. Havia um sistema que reescrevi que se adequava exatamente à sua situação. Foi uma dor terrível trabalhar no sistema. Não precisávamos chaghar com muita freqüência, mas quando o fazíamos, doeu em minha alma e me fez querer chorar. O sistema foi escrito em VB.Net e tinha toda a lógica de negócios intercalada por todo o código da GUI (que era um aplicativo .NET pesado). A gerência não queria refazer. Refiz o back-end usando um serviço da web e, em seguida, mostrei como fazer isso nos permitiria adicionar mais de uma IU ao produto. Era um produto para gerenciamento de ligações telefônicas em call centers. Eu vendi a ideia à administração mostrando a eles uma maquete que funcionou tanto em um site quanto em um smartphone. Eles começaram imediatamente a pensar em outros tipos de novos produtos que poderiam usar, tendo várias IUs nesta coisa.

  2. Estabeleça uma cabeça de ponte/Não coma o elefante de uma vez: construa seu sistema perfeito um pouco de cada vez. Passe algum tempo imaginando como seria o seu sistema ideal. Visualize o que é essa arquitetura. Desenhe um diagrama de blocos em um pedaço de papel e guarde essa imagem em sua mente. Então, da próxima vez que você precisar consertar algo, tente construir uma peça desse sistema ideal. Você pode então construir um adaptador que permitirá que você conecte-o ao sistema antigo. O adaptador irá isolar sua bela peça nova dos horríveis caprichos do antigo código de baixa qualidade. Peça por peça, você pode substituir todo o sistema dessa forma. O primeiro pequeno pedaço é a parte mais difícil - é como estabelecer uma cabeça de ponte em território inimigo. Mas, uma vez que sua cabeça de ponte está estabelecida, avançar se torna cada vez mais fácil.

Por exemplo, tínhamos esse enorme código escrito em PHP um lugar em que trabalhei. Minha equipe e eu queríamos usar Python, mas a administração não queria nos financiar para isso. começou a adicionar novas funções usando um Python webservice, e usando curl para acessá-los do PHP. Não foi uma reescrita total, mas uma vez que construímos as instalações para facilitar a integração das bases de código, nós tinha estabelecido uma cabeça de ponte, fomos capazes de mover o resto para frente mais facilmente a partir daí. Fiz a mesma coisa com sistemas legados doggy em linguagens como COBOL e RPG/3, chamando Java.

14
Unoti

Pense com muito cuidado antes de qualquer reescrita. Leia a postagem do blog de Joel Spolsky, Coisas que você nunca deve fazer.

Há uma razão sutil para os programadores sempre quererem jogar fora o código e começar de novo. O motivo é que eles acham que o código antigo é uma bagunça. E aqui está a observação interessante: eles provavelmente estão errados. A razão pela qual eles pensam que o código antigo é uma bagunça é por causa de uma lei fundamental da programação:

É mais difícil ler o código do que escrevê-lo.

É por isso que a reutilização de código é tão difícil. É por isso que todos em sua equipe têm uma função diferente que gostam de usar para dividir strings em matrizes de strings. Eles escrevem suas próprias funções porque é mais fácil e divertido do que descobrir como a função antiga funciona ...

A ideia de que o novo código é melhor do que o antigo é evidentemente absurda. O código antigo foi usado. Foi testado. Muitos bugs foram encontrados e foram corrigidos. Não há nada de errado nisso. Ele não adquire bugs apenas por ficar sentado no disco rígido. Au contraire, baby! O software deveria ser como um velho Dodge Dart, que enferruja parado na garagem? O software é como um ursinho de pelúcia que é meio nojento se não for feito de todo material novo?

... É importante lembrar que, quando você começa do zero, não há absolutamente nenhuma razão para acreditar que fará um trabalho melhor do que da primeira vez. Em primeiro lugar, você provavelmente nem tem a mesma equipe de programação que trabalhou na versão um, então não tem realmente "mais experiência". Você cometerá a maioria dos erros antigos novamente e introduzirá alguns problemas novos que não estavam na versão original.

O velho mantra construa um para jogar fora é perigoso quando aplicado a aplicações comerciais de grande escala. Se você está escrevendo um código experimentalmente, pode querer rasgar a função que escreveu na semana passada quando pensar em um algoritmo melhor. Isso é bom. Você pode querer refatorar uma classe para torná-la mais fácil de usar. Isso também está bom. Mas jogar fora todo o programa é uma loucura perigosa ...

14
grokus

Tive a oportunidade de uma reescrita completa duas vezes (trabalhos diferentes).

O primeiro era um aplicativo bastante pequeno. A reescrita foi estimada em seis meses para dois programadores. Cumprimos o prazo e o cliente ficou muito feliz. Infelizmente, apesar da demanda, o marketing abandonou o aplicativo e o esforço foi desperdiçado.

O segundo era o aplicativo principal de uma pequena empresa. A reescrita foi completamente subestimada e quase arruinou a empresa. No final, o projeto foi um sucesso.

O problema com a reescrita é que ela não adiciona nenhuma funcionalidade ao aplicativo. O que significa que é difícil vender. Portanto, é melhor reescrever pequenos trechos a cada vez. Refatoração ++.

4
Toon Krijthe

Não reescreva - os riscos e custos são muito altos para o seu negócio. Veja o artigo de Joel Spolsky citado por @Grokus para saber os motivos.

Eu ofereço uma opção alternativa - uma combinação de refatorar o código que é adequado mais a introdução de uma tecnologia complementar ao lado. Por exemplo, comece a escrever novas páginas em ASP.NET, migrando gradualmente mais e mais códigos para o mundo .NET. Fizemos isso com sucesso - novos recursos são uma grande oportunidade para fazer isso, mas partes mais simples do sistema que podem ser migradas rapidamente também são candidatas. Pode ser necessário inventar algum nível de abstração ou tipo de sistema de ponte (adicionar uma camada de API ao sistema 'antigo') para chegar lá.

Só você pode decidir se deseja MVC + AJAX, MVC + SilverLight/Flash ou similar, mas você não precisa estacionar nada antes de seguir em frente.

Sim, haverá alguma dor e confusão ao longo do caminho, mas você terá um produto entregável o tempo todo, ao invés de um longo, longo, longo tempo "em desenvolvimento" com um produto estabelecido se tornando obsoleto e perdendo participação de mercado para concorrentes.

3
JBRWilkinson

Você quer dizer vendê-lo para sua empresa, como convencer os gerentes a fazerem isso? Infelizmente, não existe um truque de mágica para fazer os gerentes que veem tudo no curto prazo reconhecerem os problemas no longo prazo. Especialmente se eles não forem técnicos, eles podem não apreciar as razões técnicas para tal coisa. A melhor coisa a fazer é o que você já fez - demonstrar que é a coisa certa financeiramente. Se eles não fizerem isso, não há muito que você possa fazer além de sentar e assistir as coisas implodirem.

Por outro lado, se você quer dizer como vender para um cliente que é um negócio, isso é fácil. Reescreva a coisa e diga a eles que se eles quiserem o recurso X, eles precisam usar o novo sistema. Às vezes, para ajudar um cliente, você precisa de um pouco de amor forte.

2
GrandmasterB

Primeiro, crie uma categoria para mudanças típicas em termos de SLOC (e pontos de função se envolver mudanças nos elementos da IU).

Em seguida, observe as alterações de código anteriores e veja onde elas se encaixam no modelo de categoria descrito acima.

Faça o mesmo para novos recursos (ou seja, trate as alterações de código e novos recursos de maneira diferente, a menos que um novo recurso envolva mudança/custo significativo na base de código existente.) Se a integração de um novo recurso for trivial, separe-o das alterações de código. Se sua integração com a base de código existente for significativamente cara, inclua-a nas alterações do código.

Em seguida, para cada mudança de código categorizado (ou novo recurso), determine 1) quanto tempo levou para ser concluído, 2) quanto tempo deveria levar para ser concluído, - ) quantas pessoas estavam realmente envolvidas na conclusão, e 4) quantas pessoas foram inicialmente consideradas necessárias para a sua conclusão.

Portanto, agora você deve ter uma apresentação tabular dos artefatos entregues (alterações de código e novos recursos), cada um com colunas indicando recursos estimados e reais (horas, pessoas) consumidos.

Você pode então assumir um salário médio/hora de engenheiro estimado (digamos US $ 40/hora). Multiplique isso por 2 para indicar o custo total de engenheiro/hora (uma estimativa de salário por hora, eletricidade, comodidades de escritório e aluguel, etc.). Não precisa ser preciso, apenas realista o suficiente.

Para cada artefato entregue [~ # ~] a [~ # ~] , você pode calcular o seguinte:

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)

Com essas relações (que devem ser baseadas em mudanças reais de código ou novos itens ... do contrário, não têm sentido), você pode calcular (por tamanho de categoria), qual é a% de mudança de código de que o tamanho se desvie do tamanho estimado (uma% de falha), o custo aproximado, bem como a% de mudança de código pode realmente atingir um máximo. custo.

As chances são de que a porcentagem de desvio máximo do custo estimado (mínimo) se assemelhe cada vez mais a uma distribuição exponencial quanto maior for a alteração do código.

Com essa data, você pode dizer ao seu cliente o seguinte:

Você para o seu cliente:

Esta mudança que você está solicitando (A) pode levar 10K SLOC, na base de código antiga. Os dados históricos indicam que pode levar 2 pessoas no mínimo (estimativa_pessoas), possivelmente escalando para até 3 pessoas (pessoas_real). A probabilidade da mudança para o custo (estimativa_custo) é A%; B% para approx_cost e% C para max_cost.

Agora, essa é a chave. Você tem que fazer os mesmos cálculos para novas solicitações (o tipo cuja integração com a base de código antiga envolve mudanças não significativas na última).

Se você achar que os custos aproximados e máximos estimados para novas solicitações de um determinado tamanho são (esperançosamente) significativamente menores do que os custos de alterações de base de código antigo do mesmo tamanho, [~ # ~] então [~ # ~] você tem um argumento para reescrever o código. Você forneceu evidências suficientes de que a antiga base de código é cara para alterar em comparação com alterações da mesma magnitude no novo código.

Mas se os custos de novas solicitações de código não divergem muito das alterações de código antigo da mesma magnitude, você terá dificuldade em justificar uma reescrita de código (e pode indicar que os problemas não são apenas para a base do código, mas também em suas práticas de desenvolvimento.)

2
luis.espinal

Se for possível, faça o que puder para tornar o aplicativo melhor como está agora.

Se você não estiver satisfeito com a documentação, depois de ter gasto um tempo tentando descobrir as coisas ESCREVA-OS para a próxima sessão de manutenção. Freqüentemente, quando você vê uma base de código pela primeira vez, apenas uma pequena lista de "motivos" (para responder os por que o código não pode) pode ajudar a compreender imensamente o que está acontecendo.

Melhore gradativamente!

1
user1249

Descubra uma maneira de fazer isso aos poucos.

Se você tentar reescrever tudo do zero, provavelmente nunca o lançará.

Se os pedaços do tamanho da sua mordida forem pequenos o suficiente, você pode nem precisar vender isso para a empresa: você pode simplesmente seguir em frente enquanto implementa novos recursos.

0
Bill Michell