totallyoverengineered

ExchangeRateProvider / TDD

"Patterns panacea"

I considered myself just that once I’d learned and used dozens of patterns. They helped me develop flexible frameworks and build robust and extensible software systems. After a couple of years, however, I discovered that my knowledge of patterns and the way I used them frequently led me to over-engineer my work. Once my design skills had improved, I found myself using patterns in a different way: I began refactoring to patterns, instead of using them for up-front design or introducing them too early into my code. My new way of working with patterns emerged from my adoption of Extreme Programming design practices, which helped me avoid both over- and under-engineering. Over-engineering tends to happen quietly - many architects and programmers aren’t even aware they do it. And while their organizations may discern a decline in team productivity, few know that over-engineering is playing a role in the problem.Perhaps the main reason programmers over-engineer is that they don’t want to get stuck with a bad design. A bad design has a way of weaving its way so deeply into code that improving it becomes an enormous challenge. I’ve been there, and that’s why up-front design with patterns appealed to me so much.Experiences made me aware that I needed to stop thinking so much about patterns and refocus on writing small, simple, straightforward code. I was at a crossroads: I’d worked hard to learn patterns to become a better software designer, but now I needed to relax my reliance on them in order to become truly better.