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.