Is the code better?

As long as there is night, there will be day. As long as
there is twitter, there will be DHH posting “robust” opinions on there. Recently he was
making comments like this:

So, I followed the github link (https://gist.github.com/2838490) and
I just LOLd. The OP’s comment is exactly how I started to write controllers in
asp.net MVC when I started learning about SOLID — moving all the logic into
some “service” just to get it out of the controller. As it happens, I think DHH
posts the best code example for the given context of simple synchronous code.

I had a senior dev at the time telling me how pointless my
services were. But I was adamant it was SOLID code, and thus unquestionably correct, and he was wrong. (Morcs his
name is. Top developer and you should follow him on twitter @morcs).

DHH later tweets about a podcast in which he discusses all
of these issues. I had a listen and it was super-engrossing, I recommend you do
too http://rubyrogues.com/056-rr-david-heinemeier-hansson/

In the rest of this post I’m taking an exploratory approach.
My aim is to clarify my own thoughts and put them out there to be shown lacking and hopefully improved given further insight — I’m being civil and open-minded for a change.

You should really listen to the podcast if you want the full
context.

What Would DHH Say?

“Show me the code. Is the code better? Does it look better
after than it did before?”. He argues that OO principles, patterns and laws
sound unquestionable when discussed in the abstract, but often fall down when liberally
applied to real code. He reels off a number of examples based on the Rails code,
too.

He thinks that because they are called “principles” or “laws”
that we feel we have to use them. I believe he is correct. I can think back to
a number of discussions I’ve had where someone has told me the code is better
because it follows principle X, yet it doesn’t really look any better (In fact
I’ve said the same many times myself).

In fact, for some of
those use cases the principle makes it more difficult. For instance, there is
often a trade-off between DRY and SRP — do you want logic to be isolated or
centralised? It depends on the context, not your favourite principle. And I think we have all broken the “law” of demeter when it was a hindrance.

Follow the Leader

What happens when we tell developers to follow the golden “rules”
of SOLID, OO and all that jazz? We promise them that when they reach enlightenment
they can break these “rules” with their god-like expertise?

Well if they don’t
know why they are doing it, and they aren’t applying it based on the context,
there is a *chance* they may create an over-engineered mess that is harmful.
But that’s abstract….

…at 7digital, one of the projects has a code base created
with the best of intentions. The developers thought they were doing the company
good by having so many abstractions. Yet on a daily basis we are fighting
against all of them to find out the real logic of the system. I’m not
criticising the devs, they learned about SOLID, thought it was awesome and
really tried their best. Much like I have done to many a poor code base.

But who is really telling us that we should liberally apply
SOLID to every crevice of OO code? Let’s start at the top — is Uncle Bob
telling us to liberally apply SOLID without thought of context? No he’s not — I’ll
quote him directly: “abstractions are indirection”. In fact, Uncle Bob tells
you not to use the Open Closed principle until you know how the application is
being used and how it is changing http://www.cleancoders.com/codecast/clean-code-episode-10/show. Exactly the case DHH is making.

Who to Follow Then?

What if we take the DHH approach? Imagine a world where we
have to justify the use of a pattern or principle. No longer are we sheep following the herd, but responsible developers justifying our design decisions.

When I think about it, it seems like there should be no
other way. Yes, absolutely, learn about SOLID, DRY and all of the good things
you can because they are super-important. Just be aware of the puppy-love
infatuation you subsequently go through and over-apply them. This is the phase
where you learn by detouring from the applicable-contexts.

…but I think regardless of ability we should always keep context in mind and do the DHH — “is
the code better? Does it look better? Why is it better? What pain is it causing?
What pattern or principle will genuinely help here?”.

Be objective and follow yourself.