Executando verificação de segurança...
3

Posso discordar e concordar ao mesmo tempo?

Vou discordar porque faz uma afirmação que refazer um projeto do zero é sempre ruim, que falta maturidade em quem decidiu fazer isso. Isso é claramente falso.

É verdadeiro em muitos casos, talvez maioria, e pode até mesmo ser quase todos, até porque eu não tenho dados, e ninguém tem para afirmar qual é a quantidade.

Qualquer afirmação de 100% sem contexto é errada, até porque mesmo que acerte será só porque tinha 50% de chance de estar certa.

Na minha visão de 40 anos fazendo e acompanhando sistemas, completamente do zero, pegando sistema andando e decidindo refazer do zero, ou preferindo só ir dando manutenção, em alguns casos refazendo todo ele mas não do zero, falta maturidade sempre que a opção for 0 ou 100. Só sabendo do caso concreto pode-se tomar uma boa decisão. Falar que deve fazer algo sempre, mesmo que as chances sejam boas de acertar porque a maior parte dos casos acontece isso, é jogar pôquer.

A analogia ajuda a entender a questão, mas não mostra o problema porque são coisas completamente diferentes. Mas também porque não é algo que aconteça de fato, e se acontecer é claro que é para resolver a questão pontual. Ninguém decide refazer do zero todo sistema porque tem um relatório que está saindo com valores errados.

Em caminhões, ônibus, aviões, e outros veículos de frotas tem hora que aposentam o que não compensa mais dar manutenção e pegam um novo que custa absurdamente mais caro. Não posso fazer uma analogia com isso porque o custo de aquisição e manutenção em cada caso é absolutamente previsível, em software não é.

Justamente porque o custo não é previsível é difícil tomar decisão, e é necessário demonstrar com clareza que uma opção é melhor que a outra e que não há tanto risco assim no caso concreto. E a minha experiência mostra que é comum não compensar fazer algo do zero. Mas também há casos que compensam, como uma empresa de transportes faz.

Tem casos que a qualidade do código é ruim demais, e não está trazendo vantagens. Eu já peguei um sistema que tinha uma média de 5 warnings por linha, e algumas linhas eram impossíveis de ter warning, então a média real é maior. Como você vai consertar isso? Era como dar seta e a porta abrir de tanto efeito colateral imprevisível que tinha.

Recentemente eu dei uma consultoria resolveram jogar fora todo o sistema feito em uma linguagem para fazer em outra, e praticamente só por isso. Foi a melhor decisão? Não sei não estou acompanhando, a decisão não foi minha, eu estava mostrando o caminho, mas deu ruído no processo. Eles tinham um sistema com vários problemas também, claro, e agora é possível que tenham um melhor, mas não sei. Pode ter ruídos e fazerem algo tão ruim ou pior que antes.

Não é só questão do quanto está ruim, mas da capacidade das pessoas de fazer a mudança.

Um erro muito comum é reescrever tudo querendo manter compatibilidade com o antigo. Isso é o pior dos dois mundos, você paga o preço de arrumar com o carro andando e de comprar um novo. Para fazer isso tem que se comprometer com um produto completamente novo. O custo de ficar fazendo adaptações é algo, e é imprevisível tanto quanto o de fazer tudo do zero.

Se você não fizer o seu concorrente, que talvez nem exista ainda fará. Um monte de empresa não quis fazer do zero e tinha outro fazendo, e agora sua posição de mercado está ameaçada. Se outro pode fazer, por que não eu?

Decidir qual é a hora de fazer isso, que pode ser nunca, é muito difícil. Mesmo pessoas muito experientes podem errar feio.

Até porque não se tem muita informação sobre isso. As pessoas não fazem os dois e medem qual foi mais barato. Ninguém sabe como foi no passado, e mesmo que souber não quer dizer que o seu caso será assim por uma quantidade enorme de razões.

É mais fácil mensurar o custo de fazer do zero e é sempre alto, muito alto. Mesmo se for feito do jeito certo, o que muitas vezes não é. Pode parecer que ir fazendo mudanças incrementais custa mais barato, mas é até difícil mensurar todos os custos, o prejuízo causado por estar com algo capenga, o que é manutenção normal e o que não é, o quanto é mais caro mexer em algo que não está bom, o custo de ter uma equipe sobrecarregada e até desmotivada com aquilo, além do custo de oportunidade já falado antes.

Em alguns casos pode ser até que sirva para arrumar a casa em processo e metodologias, por ser uma forma de ir reformando a equipe, porque muitas vezes a solução é começar o projeto novo com equipe nova, que tem lá seu problema também, mas só mostra como a decisão é difícil.

Nos lugares que mais dá certo ir fazendo incrementalmente são justamente os que precisam de menos mudanças ou menos traumáticas. A decisão deveria ser muito simples, o problema sempre está no que está caindo aos pedaços.

Conserta isto em vez de pegar um zero, e diga como ficou o resultado:

Fiat 147 todo detonado andando pelas ruas

Se for mais difícil será mais caro, então não pode ir por esse caminho, a questão é que nem sempre dá para saber qual é mais difícil e caro. O que é certo é que se souber o que está fazendo não tem como fazer incrementalmente ser ao mesmo tempo eficiente, econômico e sustentável do que refazer do zero. Errando tudo pode acontecer.

Para obter os mesmos resultados nas duas formas só tem um jeito do incremental ser feito, e é refazer do zero todo o sistema incrementalmente, que é muito mais difícil e caro. O que as pessoas fazem é aceitar resultados piores porque o custo de refazer não compensa. Ou só mexem onde precisa porque o resto está bom o suficiente, e se alguém cogitar refazer tudo do zero em um caso assim pode buscar a camisa de força.

Não entrei na questão de quantos usuários estão pendurados, ou outras questões políticas envolvidas, que torna a questão mais complexa ainda.

De fato muita gnete vai escolher refazer do zero por deslumbramento, sem saber onde está se metendo, por ingenuidade, aí é um problemão.

Eu sei qual fica melhor sempre, quando a qualidade da equipe não está em discussão. Se vale o custo é a resposta de ouro que estamos buscando.

O segredo é saber o quanto o sistema está dando problemas, não pode ser só um pouco, o quanto terá de ganho mudando tudo radicalmente e quanto tempo e custo disso, além de riscos. Quase todas as discussões que eu já vi nem era para pôr na mesa "refazer do zero".

Para finalizar, minha experiência mostra que qualquer situação assim deve ser evitada por inexperientes, porque as decisões serão tomadas com base no que ouviram falar e não no que viveram. Isso não dá certo. Já ficou longo para mostrar mais questões.

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

Eu votei na postagem original pelo conteúdo geral, o título (texto e tudo caixa alta) quase me fez não votar. E deu algo esquisito, nem sei se o voto que está aí é meu, estou abrindo issue.

Carregando publicação patrocinada...
1

pior erro estratégico que qualquer empresa de software pode cometer” ao decidir reescrever seu código do zero.

https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

Joel fala do caso da Nescape que segundo ele se deu mal ao reescrever do zero.
E ele diz, que uma empresa nunca deve fazer isso!

Não sei se ele esta certo ou errado, mas os argumentos dele e seu conhecimento vasto devem ser levados em conta!

https://www.joelonsoftware.com/2000/11/20/netscape-goes-bonkers/

https://www.joelonsoftware.com/2002/01/23/rub-a-dub-dub/

Não é uma discordancia nem concordancia com argumentos, mas é sempre interessante ver relatos de gente da industria

1

É um contexto. Inclusive que tinha um monte de gente batendo cabeça. Enquanto isso, tinha um monte de gente fazendo concorrentes. Quando você pega detalhes, relatos de todos, até mesmo livro foi escrito sobre o assunto e vê que não tinha como dar certo. Podiam ter feito mudanças incrementais e o resultado seria bem parecido.

O Joel é(ra) muito influente e tornou o caso famoso, e muita gente o usa como "prova" de que é assim, mas é só um caso, que serve de aprendizado, não de prova. Afinal, eu já vi avião cair, nunca mais vou pegar um.

Inclusive há algumas pessoas que contestam bastante o que ele postou aí. Ele serve de exemplo, mas não é canônico. Ele não pode ser usado como "boa prática". Eu até comecei a montar minha palestra "A péssima prática de seguir boas práticas" em parte por causa desse artigo. Porque eu via que as pessoas não entendiam o que é uma anedota e o que é fato comprovado que funciona universalmente, e transforma em boas práticas o que funciona circunstancialmente apenas. Então as pessoas começam adotar sem que aquilo tenha eficácia comprovada em todos os contextos, ou sejam começam tomar água sanitária para tratar Covid. Água sanitária é sensacional, eu sempre tenho aqui em casa. Eu teria usado outra coisa se tivesse pego Covid. O médico já me mandou usá-la para outras coisas.

Não se pode glorificar ou demonizar nada, para cada contexto tem uma indicação. Em saúde eu prefiro ouvir médicos, em decisões complexas sobre software eu sei quem escutar, principalmente quem não escutar.