quarta-feira, 20 de fevereiro de 2013

O fantasma da produtividade


Para quem tem pouco tempo, os pontos chaves que destaco:

Sintomas clássicos da falsa entrega de software:
  1. Efeito bumerangue – você entrega e ele volta rapidinho;
  2. Efeito formigueiro – sempre tem que mudar em vários pontos;
  3. Efeito dinheiro velho – ninguém consegue reutilizar o código;
  4. Efeito piano – custos altíssimos operação e sustentação;
  5. Efeito laxante – manutenção complicada, sempre dá merda;
  6. Efeito pipoca – todos os códigos modificados estouram;
  7. Efeito navalha – alguém sempre sai cortado;
  8. Efeito previdência – só segurados conseguem manter o código;
  9. Efeito sabão – manutenção sempre escorrega no orçamento;
  10. Efeito furacão – remendar cansa e não segura ninguém;
  11. Efeito ex-esposa(o) – cliente perde amor pelo projeto.
Todos – sem exceção – pregam ao máximo o excesso de produtividade, acreditando fielmente que produção de software é fabricação de telas no processo “1,2,3”… No entanto, esquecem que resultado vem da reutilização (RiSE – Reuse in Software Engineering), padronização, estabilidade, integração e, principalmente, sustentabilidade da solução que está sendo implementada (continuous quality enablement).

É claro que alguém vai gritar que testar é caro. ... um estudo realizado e publicado pelo Instituto Forrester que mostra que corrigir um defeito custa 30x mais que resolvê-lo na origem.

Na prática, todos sabem o tamanho do prejuízo, porém ninguém quer encarar o leão de frente, sendo mais prático passar a batata quente para frente, gerenciar o turnover de pessoas, disponibilizar uma equipe gigantesca de suporte. Na sequência, os novos clientes acabam tendo fila gigantesca de implantação e são servidos por um processo lento e caro que aos poucos mina o crescimento de qualquer negócio.

Nesse momento você fará uma nova pergunta: Prefere colocar o foco no problema ou na solução? Esse é o momento de dizer sim à mudança e trazer um novo momento ao negócio, procurando produzir software com estratégia e não mais fabricar aos modos “go horse”, pois o “débito técnico” acumulado é igual a cartão de crédito, a conta chega mesmo.

Complemento meu:

Em alguns lugares que passei se tem a filosofia de fila de produção, onde os desenvolvedores tem a preocupação de entregar a tarefa o quanto antes, e não entregá-la bem testada correndo o risco que volte por bugs simples de se identificar com um pouco de teste.

Nunca consegui seguir esta filosofia, voltar a corrigir algo que deveria estar ok no primeiro envio para testes é demorado, pois precisa se lembrar o que se quis fazer em cada código, reproduzir a situação, etc.


Nenhum comentário:

Postar um comentário