Para mim, é uma proporção de estabilidade (como em cimento, barro cozido no forno, em pedra, escrito com tinta permanente). Quanto mais instável for o seu código, quanto maior a probabilidade de você precisar mudá-lo no futuro, mais facilmente flexível ele precisa ser, como a argila úmida, para se manter produtivo. Também enfatizo flexibilidade e não legibilidade. Para mim, a facilidade de mudar o código é mais importante do que a facilidade de lê-lo. O código pode ser fácil de ler e um pesadelo para mudar, e de que adianta ler e compreender facilmente os detalhes da implementação se eles são um pesadelo para mudar? A menos que seja apenas um exercício acadêmico, normalmente o ponto de poder compreender facilmente o código em uma base de código de produção é com a intenção de poder alterá-lo mais facilmente conforme necessário. Se é difícil mudar, muitos dos benefícios da legibilidade saem pela janela. A legibilidade só é geralmente útil no contexto de flexibilidade, e a flexibilidade só é útil no contexto de instabilidade.
Naturalmente, até mesmo o mais difícil de manter o código imaginável, independentemente de quão fácil ou difícil seja ler, não representa um problema se nunca houver um motivo para alterá-lo, apenas use-o. E é possível obter essa qualidade, especialmente para código de sistema de baixo nível, em que o desempenho geralmente tende a contar mais. Eu tenho o código C que eu ainda uso regularmente, que não mudou desde o final dos anos 80. Não precisa mudar desde então. O código é fugaz, escrito nos dias de bit-fiddling, e eu mal o entendo. No entanto, ainda é aplicável hoje em dia e não preciso entender sua implementação para tirar o máximo proveito dela.
A escrita completa de testes é uma maneira de melhorar a estabilidade. Outro é o desacoplamento. Se o seu código não depende de mais nada, então a única razão para ele mudar é se ele próprio precisa mudar. Às vezes, uma pequena quantidade de duplicação de código pode servir como um mecanismo de desacoplamento para melhorar drasticamente a estabilidade de uma forma que torna uma troca digna se, em troca, você obtiver código que agora é completamente independente de qualquer outra coisa. Agora esse código é invulnerável a mudanças no mundo externo. Enquanto isso, o código que depende de 10 bibliotecas externas diferentes tem 10 vezes o motivo para mudar no futuro.
Outra coisa útil na prática é separar sua biblioteca das partes instáveis de sua base de código, possivelmente até mesmo construí-la separadamente, como você faria para bibliotecas de terceiros (que também devem ser usadas, não alteradas, pelo menos não pela sua equipe). Apenas esse tipo de organização pode impedir as pessoas de adulterá-lo.
Outro é o minimalismo. Quanto menos o seu código tentar fazer, maior a probabilidade de ele fazer o que bem faz. Desenhos monolíticos são quase permanentemente instáveis, uma vez que quanto mais funcionalidades são adicionadas a eles, mais incompletos parecem.
A estabilidade deve ser seu objetivo principal sempre que você quiser escrever código que inevitavelmente será difícil de mudar, como o código SIMD paralelizado que foi micro-sintonizado até a morte. Você contraria a dificuldade de manter o código, maximizando a probabilidade de não precisar alterar o código e, portanto, não precisará mantê-lo no futuro. Isso reduz os custos de manutenção para zero, não importa o quão difícil seja manter o código.