A common problem in component frameworks, class libraries, foundation services, and other infrastructure code is that many are designed to be general purpose without reference to concrete applications. This leads to a dizzying array of options and possibilities that are often unused, misused, or just not useful. Most developers work on specific systems: the quest for unbounded generality rarely serves them well (if at all). The best route to generality is through understanding known, specific examples and focusing on their essence to find an essential common solution. Simplicity through experience rather than generality through guesswork.
Kevlin Henney

Acho que essa cultura de generalização exagerada pode criar problemas quando programadores perdem o foco no contexto do sistema, nos interesses dos stakeholders e passam em se preocupar em produzir frameworks e componentes genéricos.

Although many architects value generality, it should not be unconditional. People do not on the whole pay for (or need) generality: They tend to have a specific situation, and it is a solution to that specific situation that has value. We can find generality and flexibility in trying to deliver specific solutions, but if we weigh anchor and forget the specifics too soon, we end up adrift in a sea of nebulous possibilities, a world of tricky configuration options, overburdened (not just overloaded) parameter lists, long-winded interfaces, and not-quite right abstractions. In pursuit of arbitrary flexibility you can often lose valuable properties, accidental or intended, of alternative, simpler designs.
Kevlin Henney

Thus, the real goal for all architect is to make sure the final architecture, resulting from the design and code written, solves the stakeholders concerns. I have nothing if only nice code and a great design that does not solve the stakeholders needs.The architect needs to learn how to get out of the design/coding swirl without losing eye-contact, and start developing the solution with the problem in mind.
William Martinez Pomares

A maioria dos esforços para tornar implementações genéricas, acabam inserindo complexidade desnecessária ao código fonte, pois as decisões são feitas para resolver, problemas que na maioria das vezes acabam não se concretizando no futuro.
Frameworks genéricos, ou frameworks de referência geralmente se tornam um problema de arquitetura de sistemas. As boas arquiteturas são estabelecidas dentro de um cenário espefício. Cada projeto tem característias e necessidades únicas, que podem ser resolvidas com frameworks mais apropriados para àquela situação. Mas na prática, o que acaba acontecendo, é que após um projeto bem sucedido, muitos programadores tem a impressão que o mesmo framework pode ser utilizado para qualquer outro projeto futuro. E então, a máxima torna-se verdadeira: pra quem só tem um martelo, todo problema é prego.

Claro, que práticas que já obtiveram sucesso num projeto, podem eventualmente ser aplicadas em outras situações. Contudo, isso não pode se tornar uma regra. Achar que algumas tecnologias podem ser aplicadas em todos os projetos, é ilusão. Mas tem muita gente que ainda acredita em soluções genéricas, compra meias tamanho único e fica na eterna busca pela bala de prata para seus problemas.

Além do mais, o cliente não compra arquitetura. O cliente paga por uma solução, que as vezes, é software. O cliente não está preocupado com o número de camadas da aplicação ou se ela foi desenvolvida com struts ou mentawai, muito menos com o design de suas classes. O cliente espera que o sistema ajude a resolver seus problemas e venha de encontro aos seus anseios.
Apesar da arquitetura de sistemas estar mais relacionada à escolha e aplicação de tecnologias, creio que seja fundamental que arquitetos e programadores sempre mantenham foco nos interesses e objetivos dos principais stakeholders dos projetos.

E antes de sair tentando reusar objetos e generalizar componentes, pergunte a si mesmo: “O que realmente precisa ser feito ?”

A simplicidade na programação, é um assunto que vem montivando muita gente. Rico Mariani (Microsoft), fala sobre simplicidade e performance:

I hardly think that one can make any conclusions about which vendor has the edge in performance from my article on Performance Tidbits.  If I was to summarize my advice in that blog in a few words it would be “don’t use OOP features that you don’t need.”

This is not to say that you should shun virtual functions, inheritance, or other features of modern programming languages.  Far from it, often they not only add clarity and maintainability they also improve performance.  But, as often, I find that people have written their code in some elaborate way when a much simpler model would have been equally servicable and more performant.  Whatever programming religion you may have I think you’ll agree that more complex language abstractions do not inherently help your design — rather each more sophisticated feature starts at a net negative and must somehow earn its way to positiveness with benefits such as clarity, ease of maintenance, performance, and so forth.
From Rico Mariani’s Performance Tidbits

Código fonte complexo, é um forte candidato a refactoring. Simplicidade é tudo. Não vamos utilizar design patterns sem necessidade. Faça a coisa mais simples possível que possa funcionar. Não pense em problemas que você ainda não tem. Se foque no que precisa ser feito agora. Torne o YAGNI uma filosifia de trabalho. O pessoal do 37signals, já falou muito a respeito disso:

Keep your code as simple as possible. You’d think that twice as much code would make your software only twice as complex. But actually, each time you increase the amount of code, your software grows exponentially more complicated. Each minor addition, each change, each interdependency, and each preference has a cascading effect. Keep adding code recklessly and, before you know it, you’ll have created the dreaded Big Ball of Mud.

• Less software is easier to manage.
• Less software reduces your codebase and that means
• less maintenance busywork (and a happier staff).
• Less software lowers your cost of change so you can adapt quickly. You can change your mind
• Less software results in fewer bugs.
• Less software means less support.
  

Não há nada de errado na aplicação dos design patterns catalogados pelo GoF – Design Patterns: Elements of Reusable Object-Oriented Software ou nos Blue Prints da SUN. Mas não crie problemas, apenas para poder utilizá-los.

Não vejo nenhuma vantagem em investir muito tempo tentando resolver algo, que um dia talvez, poderá vir a acontecer. Implementar soluções, na tentativa de resolver problemas que ainda não existem, não fazem muito sentido para mim. Todos os requisitos não precisam ser implementadas agora. Ao invés disso, acho mais inteligente fazer esforços para manter componentes desacoplados, permitindo que o sistema cresça interativamente de forma sustentável, à medida que novas funcionalidades vão sendo inseridas. As vezes, é fundamental saber o que deve se descartado.

The “secret” to good software design wasn’t in knowing what to put into the code; it was in knowing what to leave OUT! It was in recognizing where the hard-spots and soft-spots were, and knowing where to leave space/room rather than trying to cram in more design.
Brad Appleton

Em se tratando de software, quanto menos, melhor.