Hyrum Wright, engenheiro da Google, é o autor da observação que originou a “lei” de engenharia de software que leva seu nome. Em tradução livre:
Com um número suficiente de usuários, não importa o que estiver acertado em contrato: todos os comportamentos observáveis de um sistema serão premissas para funcionamento de outros artefatos. (Hyrum Wright)
Detalhes técnicos de implementação como tempos de resposta, ordenação em resultados, esquemas de bancos de dados, mecanismos de persistência e, até mesmo, detalhes de infraestrutura de uma aplicação servem, invariavelmente, como fundamento para desenvolvimento de processos e outros sistemas.
Esquemas de banco de dados, por exemplo, mesmo que oficialmente privados e restritos aos times técnicos da organização desenvolvedora, são frequentemente utilizados para desenvolvimento de mecanismos de integração.
***
[tweet]Quanto maior o número de usuários de um software, maiores serão as dificuldades e os custos potenciais da mudança.[/tweet]. Afinal, além de tudo que está explícito em contratos técnicos, será necessário mitigar as chances de que nenhum “comportamento comum” que possa ter sido utilizado como premissa em alguma implantação seja modificado.
***
[tweet]Quanto maior o número de usuários de um software, maiores são as possibilidades de clientes precisarem permanecer em versões antigas.[/tweet] Afinal, estes clientes poderão ter construído processos e ferramentas usando como base comportamentos do sistema que não foram preservados em versões mais novas.
A consequência direta disso é o aumento dos custos da empresa desenvolvedora pela necessidade de manter suporte a versões legadas, mesmo sem gerar valor novo.
***
Não é um motivo oficial, mas é fato que muitos programas de computador, mais antigos, teriam dificuldades para funcionar adequadamente em um pretenso “Windows 9”. Motivo? Muitos desses programas verificam se estão funcionando em um Windows 95 ou Windows 98 verificando se o nome do sistema operacional começa com “Windows 9” e, baseado nisso, determinam como o programa deve operar. Dessa forma, uma versão mais nova do sistema operacional poderia ser reconhecida por esses programas mal escritos como antiga.
Trata-se de um exemplo claro de como aspectos, aparentemente irrelevantes, podem ter impactos gigantescos com bases de usuário descomunais.
***
Soluções on-premises apresentam, naturalmente, mais comportamentos observáveis definidos de forma implícita do que soluções que “rodam” na nuvem.
***
Em casos extremos, as dependências estabelecidas para interfaces implícitas comprometem a evolução de sistemas, diminuindo competitividade.
Empresas contratando software que possuem grandes bases de usuários devem ter consciência de que estes provavalmente terão um ritmo de evolução mais lento e, geralmente, são mais difíceis de customizar.
***
A classificação de APIs como internas e externas, mitiga os impactos da lei de Hyrum. Afinal, “segrega” usuários e retarda a exploração de interfaces implícitas.
Veja também
***
[tweet]Os impactos da lei de Hyrum são maiores em empresas que adotam abordagens ingênuas de engenharia de software[/tweet] Por outro lado, abordagens sofisticadas demais aumentam a complexidade e, invariavelmente, o custo.
É responsabilidade do CTO garantir que a organização adote métodos de engenharia de software compatíveis com o número de usuários dos sistemas que mantem.
Insight muito bom e concordo 100% com esse custo normalmente escondido nos sistemas. É difícil de identificá-lo e, portanto, de corrigi-lo. Entendo a responsabilidade do CTO mas não entendo como ele poderia impactar positivamente nisso (vejo apenas como ele pode impactar negativamente). Em termos de ação direta, você não acha que aqui cabe o papel direto do arquiteto, do líder de equipe ou da equipe de testes?