Best Practices?

Design patterns are best practices. Best practices are, by definition, the best way to do things. It’s right there in the name. Therefore we should use design patterns for everything. Taken to its logical conclusion, you end up turning the interview FizzBuzz question into the Fizz Buzz Enterprise Edition. That’s perfect, right? It’s got, among other things, frameworks, abstractions, factories, strategies, Travis for CI, and it’s even got an implementation. Which means if you need a scalable, enterprise-ready version of FizzBuzz, you’re set. End of story.

Or not. There are lots of design patterns there. But the simple usage of a pattern doesn’t mean it’s a good thing. After all, you can always add another level of abstraction.

More seriously, all of those things are important. When used at the right time. You could use a Builder to set up a State Machine every time you need to get the current state, but is that the right thing? Probably not. 

There are two times when those best practices are almost certainly wrong. At the very start of a project, and when you’ve pushed your project into areas where most folks haven’t gone. Because that’s not what the Best Practices are best at.

When we did the O’Reilly kata last year we almost certainly over-designed it. We had microservices, an authentication/authorization module, and provisions for adding a machine-learning component. For a customer with 100s of customers at 10s of locations in one city. In reality, you probably could have managed it with a spreadsheet and some web connections and a few Excel macros. The winning architecture was a monolith with some clear internal separation for if/when more scale was needed.

At the other end of the spectrum is getting the most performance out of a system. Which for me was epitomized by the Apple ][ hi res graphics, with it’s weird modes and loading order, because it saved a chip in the design and was cheaper/faster. There’s no Best Practice that will tell you that it’s a good idea to load things like that. It’s just something needed in that particular time/place. The StackOverflow folks have a good description of how they traded best practices for scale/speed, and how now, with more power and different goals they’re changing some things.

Which is to say that best practices are best practices when the situation you’re applying them to match the conditions the best practices were developed for.