Screw best practices and dogma

Monday, February 24, 2014 gc 2 Comments

The term "best practice" is naïve, condescending, and quite dangerous. Why? Because it implies it can get no better and used regardless of your context or situation. You (and your team) live in a temporal context. Given your context, some practices are helpful and some are harmful. If you think about it, best practices do not even exist.

What should you embrace instead of best practices? Certainly consider practice patterns. A practice pattern is a practice that only makes sense in a particular context for a reason. Know your context and your practices will become clearer. The same is true for design patterns and you would not blindly use a design pattern no matter the context.

Dogma

Dogma is a set of principles laid down by an authority as incontrovertibly true.

5 problems with dogma (and principles)

1. Like best practices a design principle leaves no room for improvement and only makes sense in a context.

2. Combining design principles often works against your real and honest goals.

3. Design principles are often in conflict, which can only increase complexity.

4. Design principles come with a downside. This also reveals the truth about dogma: dogma lays down negatives as incontrovertible truth.

5. Design principles that worked in the past will not necessarily work in the future. Dogmas eventually collapse.

Why is dogma even more dangerous than best practices?
Dogma is even more dangerous, because dogma is much harder to refute, and teams can base even more value on dogma since it is an entire set of principles driving an entire architecture. Challenge one principle and you challenge the dogma and architecture as a whole.

"Don't be trapped by dogma --which is living with the results of other people's thinking. Don't let the noise of others' opinions drown out your own inner voice."

Steve Jobs (1955 - 2012)

What should you embrace instead of dogma?
Simply embrace design rationale and empirical data:

A is important, so we chose B, accepting downside C.

Design Teams
Design teams can easily be locked in best practices and dogma. These often times divide a team in dysfunctional and irrational ways. Blindly following the dogma while losing sight of core goals.

Empirically, I have seen some of the most successful (and profitable) teams refute best practices and dogma, so there has to be something to it.

The main point: any design team should challenge best practices and dogma. As Alan Kay said, "Point of view is worth 80 IQ points."

In my view, best practices and dogma do not lead to great design — more often, they lead to poor over-abstracted design which can be even worse than an under-abstracted design.

Enjoy.

2 comments:

bmonster said...

I agree and disagree:

In a shared development team, for the most part it's better to create a pattern and stick to it. It may seem dogmatic, but if every developer is left to their own devices and creates their own pattern then the result is chaos.

When you're doing architecture and deciding what pattern, or your own derived patterns, then dogma and best practice may lead you to a design that is not optimal to the problem you are trying to solve. In general, patterns should be socialized and accepted by the team, and then followed.

4:23 PM