Robert Martin (Uncle Bob), autor de Clean Code (código limpo), faz uma análise sobre os riscos envolvidos na utilização de frameworks de desenvolvimento. Para Martin, grande parte dos programadores acoplam cedo demais seus sistemas ao código de frameworks, afetando negativamente o design das aplicações:
Comprometer-se com a utilização de um framework é algo bastante comum entre as equipes de desenvolvimento. No início dos projetos, o entusiasmo é grande e os times deliberadamente acoplam seu código ao código dos frameworks, para só mais tarde descobrirem que o próprio framework se tornou um empecilho à evolução de seus sistemas.
Martin reconhece que os frameworks lidam com um grande número de pequenos detalhes, cujo tratamento manual seria muito trabalhoso. Contudo, o autor explica que a utilização de um framework requer bastante comprometimento, pois deve-se abrir mão do controle sobre todos esses detalhes gerenciados pelo framework:
Claro que isso parece ser algo bom e geralmente é. No entanto, existe uma armadilha à espera e é difícil vê-la chegando. Antes que você perceba, se encontrará realizando todos os tipos de ações antinaturais no seu código [...] se curvando cada vez mais às convenções do framework, suas peculiaridades e idiossincrasias.
Para Martin, a explicação desse problema está no fato de que todo esse comprometimento com o framework não é recíproco, uma vez que o próprio framework é livre para se evoluir em qualquer direção, mesmo que essa direção seja conflitante com as necessidades de sua aplicação:
Isso não deveria ser uma surpresa. Frameworks são escritos por pessoas para resolver problemas específicos. Tais problemas podem ser semelhantes ao seu, mas não são exatamente iguais. À medida que os problemas coincidem, o framework pode ser extremamente útil, mas a partir do momento que os problemas divergem, o framework pode ser um grande empecilho.
Martin conclui explicando sua própria abordagem com relação à utilização de frameworks:
Ao longo dos anos, adotei um ceticismo saudável com relação aos frameworks. Embora reconheça que eles possam ser extremamente úteis, também percebo que existem custos envolvidos.
Sua estratégia é sempre manter frameworks como Spring, Hibernate e Rails ao "alcance das mãos", deixando-os atrás de certos "limites arquiteturais", confinando sua utilização apenas a subsistemas periféricos, sem deixar que afetem as decisões arquiteturais de alto nível e as regras de negócio centrais de suas aplicações.