The guru affirms that the earth is supported on the back of a tiger. When asked what supports the tiger, he says it stands upon an elephant; and when asked what supports the elephant he says it is a giant turtle. When asked, finally, what supports the giant turtle, he is briefly taken aback, but quickly replies “Ah, after that it is turtles all the way down.”
The above parable would appear to have been taken literally in certain web design fields. Which appear to be abstractions… all the way down.
I remember well the halcyon and free days, circa 2005. Just starting out on my first ‘real world’ assignment — an ASP.NET (v1.1) web site. I used the WYSIWYG editor to drag buttons onto the form, clicked on them to get to the click handler, and just went right ahead and in-lined a bunch of SQL, right there in the code-behind. Full stack, right there in a single method!
Of course, since then I have realised that in-line SQL is not the best idea, and that business logic of any sort in click handler is not the best idea either. And I have learned all about ORMs, and REST, and TDD, and DDD, and CQRS, MVC, and FML, and all the other acronyms we need to know to hoodwink the various interviewers. I even know what a few of them mean, and I’m sure that my code is all the better for it. But sometimes, when I can’t quiet my brain and get to sleep.. sometimes I wonder if all this ‘stuff’ is really worth it. Are our applications better for it? Do we finish faster? Are there really fewer bugs?
Best Practices
I had the dubious pleasure at one point along the way to work on an application that looked a bit like this:
View -> View model -> Model -> API -> Controller -> Business Entity -> Repository -> ORM -> Database
That is a deep stack for a crud application with a couple of bells and whistles. A symphony of complexity, to deliver an string of text to a web browser.
The worrying thing about the above, is that it is more or less in keeping with the ‘best practices’ for all of various technologies that were being used. I could point to plenty of resources suggesting that for each individual technology, the above is the best approach. Where this breaks down a bit, is when you start to think about what is the best approach for the application.
It’s very easy to get lost in the hype when the new coolness arrives — which it does with ever increasing regularity! When half your life is spent prepping for interviews, it’s easy to forget that good code doesn’t have to use every ‘gang of four’ pattern.
Maintainability
I have found that recent projects that I have worked on — while they may have embraced ‘best practices’ — are extremely hard to maintain.
Of course, I am not suggesting that we go back to the days of in-lining SQL in the code behind files. That approach was ‘simple’ in some ways, but was certainly not maintainable.
Every line of code that is added to an application adds complexity to the application. And as complexity goes up, maintainability goes down. Every single line of code needs to be able to justify it’s existence in the application. This goes doubly for every additional layer that gets added to the application, and triply for every abstraction, or pattern, that gets added.
Keep your eye on the prize
There is no point in writing beautiful code that no one else can understand. There is no point in allowing complexity to creep into your application just because a blog post says it is ‘best practices’.
In general, keeping things simple, and keeping things lean is the best approach. I have been trying to keep this at the front of my mind in recent months, and I feel like my code is improving for it!
