O que fazer quando um projeto é muito difícil de continuar desenvolvendo?

Quando leio as respostas, tenho a sensação de que muitas pessoas subestimam o quão ruim e inatingível pode ser uma base de código.

Apenas para ilustrar isso, estou trabalhando no local onde o projeto inteiro se originou de um arquivo "principal" de centenas de milhares de LOC. ... a pior parte é que a besta ficou maior e maior ao longo do tempo:

• métodos com dezenas de milhares de LOC
• mais de 15 níveis de recuo
• GOTOs se espalham sobre eles, quebrando os loops
• ponteiro aritmético, void * casted everywhere
• muitos nomes de variáveis "duas letras"
• lotes de código ninguém tem ideia do que faz
• ninguém realmente sabe como a coisa toda funciona mesmo ... mas funciona e faz milhões
• código duplicado em todos os lugares com algumas linhas alteradas aqui e ali
• coisas obscuras de WINAPI
• comportamento não determinístico por causa de variáveis não inicializadas, estouro de buffer, ponteiros errados ...
• sem documento, sem especificação

Antes de começar a trabalhar, não imaginava que algo tão catastrófico pudesse existir. Os custos de manutenção são, obviamente, surpreendentes e tudo é feito para tentar minimizar as mudanças.

Eu acho que você deve simplesmente falar sobre isso com seu gerente. Falar faz maravilhas. O que é importante para eles é entender qual é o estado atual. Essa manutenção é realmente extremamente difícil, demorada, propensa a erros, tudo isso por causa do código ruim. Além disso, continuar trabalhando nisso normalmente aumenta a dívida técnica porque acrescentamos pilhas de lixo com base em outras pilhas de lixo. ... mas enquanto isso, por ser uma porcaria produtiva que ganha o dinheiro da empresa, temos que lidar com isso, mesmo que seja difícil e improdutivo.

A outra coisa engraçada é que qualquer idiota pode transformar um código fonte normal em uma pilha de porcaria. No entanto, quanto mais baixo for o código, mais inteligente será o que lida com ele. O lado ruim disso é que o idiota parecia produtivo desde que ele adicionou recursos, e o brilhante, improdutivo, já que ele tem que lidar com a bagunça de seu antecessor. Apenas bons gerentes com conhecimento técnico podem entender o que está acontecendo.

Muito raramente existe um caso em que há um requisito impraticável, geralmente é um "não quero", sendo dito "não posso".

Nunca use absolutos como "Can't" e "Unworkable", a menos que você possa provar e tenha absoluta certeza de que esgotou todas as opções. Você parece um idiota ou um covil quando isso é feito. Várias vezes me disseram "Isso não pode ser feito ..." e vi isso funcionando alguns dias ou semanas depois, deixando os desenvolvedores com uma aparência ruim. Isso coloca eles e o resto da equipe em uma posição realmente difícil da próxima vez, como eles dizem "não podem" e não são acreditados.

Se você realmente não puder, forneça alternativas para consideração, com os benefícios e desvantagens de cada um. Siga isto com discussão aberta e honesta. Concentre-se em encontrar uma solução, não definindo o problema.

Seu gerente não contratou você para criar problemas. Ele contratou você para criar soluções. Nunca leve um problema ao seu gerente que você não tenha (ou pelo menos tentou) obter uma solução.

Bem, acho que basicamente tudo realmente pode ser feito, é apenas uma questão de quanto tempo demora. Em uma base de código ruim, tudo leva naturalmente muito tempo. Então, quando você está dizendo que algo é inviável, eu entendo que você levaria muito tempo para implementar um certo recurso para que ele seja praticamente viável. Eu sei que um gerente pode pensar que é apenas um pequeno problema, você sabe, "nós já temos outros recursos como este, como pode ser tão difícil?".

Se o seu gerente é o tipo de pessoa que não entende quando você os explica sobre os antipadrões e os cheiros do código, eles devem pelo menos entender o tempo e o dinheiro. Portanto, crie um plano sólido e sólido sobre como você implementaria o recurso solicitado, se realmente quiser fazer isso. Reserve um tempo para analisar o código e dividir o projeto em sub-tarefas gerenciáveis de no máximo 8 horas. Desenhe um gráfico de Gantt dos estágios do projeto. Quando você não puder fornecer uma estimativa de tempo precisa, dê pelo menos um intervalo: 10 a 30 horas é melhor que nada. Explicar o caso ideal quando levaria 10 horas e informar seu gerente sobre as condições do pior cenário de 30 horas. Então, talvez diga algo como "Dada a qualidade geral do código, tenho certeza de que ficaremos mais próximos de 30 a 10 horas. Observe também que essa tarefa está no caminho crítico do gráfico de Gantt, então quando esta está atrasada , todo o projeto está atrasado. "

Você terminará com o seu projeto A levando, digamos, 100 horas. Em seguida, crie outro plano, escrevendo o recurso solicitado do zero. Isso pode ser difícil de incluir em seu projeto existente se / quando suas interfaces estiverem ruins também, então lembre-se de incluir o tempo de integração dos dois sistemas juntos. Dessa forma, você pode acabar com um projeto B que leva, digamos, 90 horas. Isso provavelmente é muito próximo do plano original para o gerente comprar, mas então você deve explicar como a nova base de código seria muito mais fácil de modificar: se você implementasse o Recurso 2 em cima do Projeto A, levaria 30 horas , mas se você fez o mesmo com o Projeto B, levaria apenas 5 horas. Neste ponto, tenho certeza que seu gerente começa a ver as coisas em perspectiva.

Orgulho profissional (o tipo ruim, não o tipo bom) geralmente faz com que os codificadores sintam que precisam passar por eles. Na prática, acho melhor me reunir com o gerente do projeto (fazer discussões mais duras como essa durante o almoço, geralmente tira a pressão, IMHO) e discutir suas preocupações. Deixe-os saber os problemas, talvez intransponíveis, você encontrou. Proponha algum tipo de compromisso, se for humanamente possível. Por exemplo, "Não podemos adicionar o recurso Foobar no tempo alocado, mas a implementação do FizzBuzz levará um quarto do tempo e nos dará 75% da funcionalidade."

Qualquer gerente de projeto que se preze quer saber dessas coisas e estará aberto para discutir preocupações, especialmente se você tiver algum tipo de solução.

Sempre que alguém designar uma tarefa para você nesse projeto, faça uma estimativa honesta e cuidadosa sobre o esforço. Se a coisa é realmente "impraticável", como você diz, essas estimativas menos ou mais tarde serão adicionadas a uma quantia tão alta que seu gerente de projeto considerará parar o projeto.

(Ou ele irá atribuir a tarefa a outra pessoa que não pensa da mesma maneira que você faz sobre a coisa).

Você quer começar fazendo algum tipo de análise de custo-benefício. Você não vai realmente entender o quanto é importante simplesmente começar de novo sem provar que essa é a melhor abordagem a ser adotada. Isso não quer dizer que seu instinto esteja necessariamente errado, mas você realmente precisa determinar por si mesmo se é um caso de relutância ou orgulho profissional impedindo-o de trabalhar em um produto existente.

Tão ruim quanto uma base de código existente pode parecer, você precisa lembrar que provavelmente já existe um investimento considerável nele que seu empregador não vai querer que você jogue fora sem uma causa realmente boa. A realidade é que, mesmo que você tenha uma razão muito boa para querer descartar o produto existente, precisará justificar seu raciocínio e, para que isso funcione tanto para sua equipe quanto para a empresa, você precisará ser capaz de mostrar não apenas quanto o produto está custando e pode economizar se feito de outra maneira, você também precisará mostrar que existe um caminho para o seu "ideal de ouro" que não será proibitivamente caro, e você pode Certifique-se de que esse custo extra do caminho será contado em relação a qualquer economia em potencial que você possa pensar que pode mostrar para sua reescrita.

O que estou dizendo é que isso vai dar muito trabalho. Você precisa mostrar o que o produto está custando para manter como está, o que custaria para melhorá-lo para torná-lo de um padrão melhor, o que ele lançaria para manter enquanto se prepara para passar para um novo produto, o que custará para desenvolver um novo produto e o que o novo produto custará para manter.

A realidade é que nenhum produto é realmente difícil de manter. Todos os produtos podem ser melhorados com uma abordagem cuidadosa para refatoração e melhoria gradual ao longo do tempo. Isso também vai ser muito trabalhoso, mas é menos provável que seja tão dispendioso ou esforço intensivo do que tentar justificar jogar a toalha simplesmente porque a atual base de código é difícil de manter. Quando ouço alguém dizer que o código é insustentável, o que ouço é que é provável que o código não seja suportado por testes de unidade, provavelmente não suportados pela automação de teste / compilação, provavelmente muita duplicação de código e provavelmente muitas classes e métodos que estão todos tentando fazer muito. Todos esses são problemas que podem ser corrigidos em grande medida, se for aplicado um pequeno esforço para resolvê-los.

Em alguns casos muito raros, você pode ter um código que tenha dependências sobre as quais você não tem controle. Estou falando de antigos produtos legados de terceiros que estão sendo usados por sua base de código, mas que foram esquecidos porque foram adicionados anos atrás, e todos os especialistas ficaram sem documentar por que esses produtos estavam em uso. Em tais casos, você pode estar justificado em começar algo novo, no entanto, dependendo do tamanho do seu produto, é raro que isso justifique reescrever um produto inteiro do zero.

Eu não acho que você possa encontrar uma resposta definitiva para sua pergunta. Grande parte desse tipo de coisa realmente se resume a você, à sua equipe, à cultura da empresa, ao tempo, ao financiamento disponível e a toda uma confusão de outras coisas. Esse é o tipo de coisa que você realmente precisa sentar com seu gerente para discutir e trabalhar em equipe para determinar o melhor caminho a seguir.

Realmente, nunca há um projeto completamente impraticável se puder ser projetado ou imaginado - a parte impraticável pode vir das escolhas feitas para implementar o produto.

Por exemplo, é perfeitamente correto dizer que é impraticável desenvolver um aplicativo para iPad com apenas uma máquina Windows e uma cópia do Visual Studio. Além de situações como essa, é melhor pensar em termos de custo e oportunidade.

Pense nas soluções para o problema em potencial e esteja aberto com o gerente de produto sobre o que é difícil, por que, como você pode resolvê-lo e como você pode precisar de ajuda para resolvê-lo. (Às vezes pode ser uma questão de não conhecer uma tecnologia específica o suficiente para saber o que é realmente bom e o que não é bom.)

Não há como responder a isso sem detalhes específicos. Quão importante é este projeto para a empresa? Quanto tempo e dinheiro já foram gastos? Você está propondo abandonar completamente o projeto ou é possível reduzir seu escopo, aumentar o prazo ou adicionar mais pessoas?

Se este é o produto principal da empresa, e abandoná-lo significa que a empresa vai à falência, então tudo que você pode fazer é renunciar. Por outro lado, se você pode sugerir algo construtivo, como descartar alguns recursos ou alocar mais tempo e pessoas, é perfeitamente razoável levá-lo para o gerente.

Como Michael acabou de sugerir, o ponto crucial é: por que este projeto é impraticável?

Um gerente de projeto só quer saber disso. Dê-me pelo menos uma razão realmente convincente para desistir e eu farei. Vou tentar limitar o dano no mínimo e vou parar o desenvolvimento.

Como você pode imaginar, é muito, muito difícil convencer um gerente de projeto que um projeto em execução deve ser interrompido por causa de considerações técnicas. Até mesmo uma confusão total de código pode ser melhorada ou reescrita.

Diferente é o caso de considerações comerciais. Um projeto pode perder sua razão de existir durante o desenvolvimento. Talvez um novo concorrente já tenha ocupado o nicho desejado, talvez o investidor não tenha mais dinheiro. Há possível motivos comerciais para interromper um projeto.

Minha sugestão muito pessoal é identificar com os melhores cuidados os problemas com o projeto, explicar ao seu gerente de projeto por que eles tornam o projeto impraticável e o que você pode fazer para corrigi-los.

Seja construtivo. Traga para a mesa todas as soluções que puder encontrar. Faça o seu melhor para salvar o projeto, mesmo que ache que ele deveria ser morto.

A última decisão deve ser deixada ao investidor e ao gerente do projeto. Se a sua explicação for convincente, eles vão parar o projeto.

Esse tipo de problema geralmente é um desacordo sobre o tempo e os recursos necessários, e há muitas maneiras de negociar mais tempo, mais recursos, um caminho de desenvolvimento diferente ou objetivos diferentes.

Se você não puder negociar um plano de trabalho satisfatório, sua posição de reserva sempre poderá ser "esse projeto não pode ser feito por mim (com esses recursos)". Se isso não cancelar o projeto ou transferi-lo para a chapa de outra pessoa, é difícil para a gerência responsabilizá-lo pelo fracasso.

De qualquer forma, o importante é que você não aceita uma tarefa que não pode ser concluída apenas para agradar seu gerente.