Almost patterns

If you're involved with software development, chances are you came across the concept of a design pattern. A lot have been said on the topic, and the bottom line of this writing is: go on reading about them and using them.

But let's think about the context in which almost all patterns and principles are forged: good teams with great people.

Let's think about the context in which most people write code: at best mediocre, constantly shifting, teams, usually with not so great people. Sometimes goes better, sometimes goes worse.

I live in this less-than-ideal world. I also happen to like it, at least a bit, because of the challenges it creates, different from those you find in textbooks (yes, even in design patterns textbooks).

Sometimes, your code is some kind of best effort framework used by even less experienced people. Withouth documentation. Without tests.

Put it another way, we have a space formed by $GoodCode \times Time \times Experience$ and maybe some other dimension, but let's stick with this three.

If I plot design patterns as I imagine them, as a function $Time \times Experience \rightarrow GoodCode$, this is what I get:

What is missing, in our less-than-ideal world, is some kind of almost patterns function which makes the shape more interesting for us, that is yielding good code also when developer experience and time are low.

Something like this:

Notice how we don't want to loose the normal design patterns side of the shape. My favourite principle is the good old KISS, Keep It Simple Stupid: but with an additional reasoning on what Simple and Stupid mean. With simple I mean very, very simple, and with stupid, very, very stupid. So, here is my favourite almost pattern:

Utility is king: make Utility classes with static methods where possible. Complex objects with complex state? No thanks.

This has the advantages of esily sharing them between classes (going from class to static method is more difficult), and getting something easier to comprehend by just looking at the code (hopefully).

But remember, this is an almost pattern: it is still possible, and indeed very easy, to write bad code with this. After all, almost patterns may be just a call to use patterns well and not overuse them.