Exemplo

Em um projeto para um grande cliente, o arquiteto passou 5 meses, para estabelecer um projeto de arquitetura baseado no padrão de injeção de dependência para o tratamento de mensagens. O objetivo era fazer com que esta arquitetura extremamente robusta e criar um modelo de dados flexível para o serviço de mensagens e armazenamento de dados.

A teoria era que a arquitetura poderia ser reutilizada novamente em outro projeto com o mínimo de esforço, e seria fácil de injetar novos componentes devido à flexibilidade oferecida pela dependência injeção.

No entanto, a palavra teoria na frase anterior foi cuidadosamente escolhida. Os stakeholders do sistema ficaram impacientes, querendo saber por que tanto esforço estava sendo gasto em uma solução tão sofisticada, e pediu para ver algum progresso demonstrável. O arquiteto resistiu, insistindo que sua equipe não devia ser desviada e continuou a abraçar os benefícios em longo prazo da arquitetura.

Os stakeholders do sistema perderam a paciência e substituíram o arquiteto por alguém que estava promovendo uma solução muito mais simples baseada em servidor.

Este foi um caso clássico de overengineering. Enquanto a solução original era elegante e poderia ter colhido grandes benefícios em longo prazo, adotar uma abordagem ágil e que pudesse ser demonstrada ao longo do projeto era a chave para o sucesso aqui.

O segredo para o sucesso é concentrar-se nos requisitos conhecidos e evoluir e refatorar a arquitetura através de iterações regulares, enquanto a produção de código em execução, faz muito sentido em quase todas as circunstâncias.

Como parte deste processo, você pode analisar continuamente seu projeto para ver que melhorias podem ou não ser acomodadas no futuro. Trabalhar em estreita colaboração com as partes interessadas pode ajudar a desencadear necessidades futuras e eliminar aquelas que parecem improváveis.