The Original DRY, WET and Slogan Based Development

Hopefully, you now understand some of my pain when I’m arguing against DRY, and arguing against deep abstractions. The original definition of DRY though, Single Source of Truth etc, that’s ok right? I mean, WET (Write Everything Twice etc) just sounds so bad, and it’s the opposite of DRY, right?

Well …​ no, not really. This is development by slogan, pure and simple. Luke is right to fear this, it leads to dogma and dogmatic position taking and so to endless, needless, debate and argument over developer practices.

Don’t Repeat Anything == The Tower of Coupling

Copy and Paste, it’s bad. We have this drilled into us as received knowledge. We must build abstractions to avoid copying code, or concepts that seem similar, at all costs. We must do this, or we are bad developers and we’ve built a WET (Write Everything Twice .. etc) system, which isn’t DRY, so it’s bad.

I did a fun little talk a while ago that touched on this (seriously, go and do something a little silly every so often, it’s fun), and pointed to the problem that is inherent in applying DRY too broadly; Coupling.

I recently had a thought provoking exchange on Twitter with Luke Daley who is a Gradle developer, creator of the Ratpack web framework and all around awesome fellow.

We were briefly discussing DRY, aka Don’t Repeat Yourself, that great maxim of modern software development. My opening gambit was that ‘DRY totally sucks’ (because well, Twitter..). Luke picked me up on this, asking for a more nuanced view, more depth. His entirely reasonable request, to not ‘propagate software development by slogan’, which I’ve unashamedly stolen as my title is one we should all pay attention to.

All Hail the Command Object

This is a follow on to Simplicity in Web Architecture – Beware the Stateless Service

In that article, I gave my opinion on the Stateless Service programming model, and why I think it has been overused and touched on some of the issues it has caused.

It developed out of my unhappiness with the way I see code layed out in many Spring and Grails applications. The Service layer becomes stuffed with all the important logic, kept away from the domain and without much in the way of support to be had from the excellent Object Oriented language that Groovy is.

Peter Ledbrook recently wrote a blog post about the future of Grails, which sparked some deep thoughts about where Grails is heading as a platform.

As a long-term Grails user with interests in programming in the large, functional languages, DDD, CQRS, and high-volume HTTP, I’ve been contemplating what the future holds for this framework.

The Changing Landscape

The industry has changed significantly since Grails was born. Grails emerged from the Spring/MVC consensus - essentially designed to be “Java/Spring web development done right.” It was, and continues to be, a better Spring MVC paired with a better Java (Groovy). This approach has been beneficial to the industry.