Don't Repeat Yourself... Really!

...And I hope that someday
That you, you people will all have the chance
To read The Helping Friendly Book
And experience the wisdom
Of the great, the great and knowledgeable
Man who wrote The Helping Friendly Book 
Because he is, the great and knowledgeable
He is the one, the only author of The Helping Friendly Book
He is the man
The great man
The only, the special
His name is
The author of The Helping Friendly Book
He is the great
The knowledgeable, the one and the only
The great, the knowledgeable
Person who wrote The Helping Friendly Book
His name could only be
The one, the only, the only, the special
The author of The Helping Friendly Book...
-Excerpt from Icculus by Phish
There are few mantras that are as universally agreed upon by Software Engineers as Don't Repeat Yourself or DRY.  It rings deeply and globally true that any form of code duplication is at best a compromise, at worst, an abominable trap.  Writing and maintaining code is difficult enough without doing it many times.  So if we all know this, and we all agree, then why is it that the industry's preferred architectural best practices embrace duplication?

If you've ever built a controller, a repository, a service layer, a data access provider, or anything remotely like one of these things, you know exactly what I'm talking about.  Duplication is what you do.  You copy the logging code.  You copy the query strategy.  You copy the update methodology. You copy the attributes and data structures. You copy the exception handling pattern.  "That's how it was shown to you by smart people, so it must somehow be right," you think as you faithfully type away, all the while wondering if you've become little more than a digital version of a truck driver.

Like the proverbial cliff all your friends jumped off of according to your mother, it doesn't matter how bad of architecture you have seen, there is another, better way... so stop it!  But perhaps you're so used to following your lemming-like friends that you don't know how to escape the allure of duplication?  I'll offer some suggestions.

Existing Hooks and Abstractions

I've seen many applications that duplicate logging and exception handling, while being built in frameworks that provide easy to implement hooks for just these things.  At a minimum, know your tools.

Frameworks

There are new frameworks every day.  Most of them encourage repetitious coding practices and should be avoided, but some aim to automate patterns and escape the madness.  Don't use a framework just because everyone else is doing it, and if you do, at least learn how to extend it.

Aspect Orientation

Aspect Orientation or AOP is an approach that calls for applying on-the-fly code generation or similar to automate all similar patterns.  For instance, an AOP-based framework would be one which allows you to define once how logging is performed, and apply that across all service calls.  Note that Aspect Orientation isn't synonymous with code generation, there are clever ways to accomplish the approach using composition hooks or code injected at runtime.

Data Access Platforms

Most repetition in today's applications seems to revolve around data access.  It seems somehow accepted that most aspects of applications can be automated, but not data access.  Granted, it may seem difficult to orchestrate and automate proper concurrent access of data across all layers, but there are platforms like Dataphor have solidly proven that all aspects of data access, from user interface to storage, can be completely automated.  If your platform or frameworks do not automate it, don't settle.

Conclusion

Regardless of what you do, say no to pattern duplication and begin enjoying your work again.  Do it for the lemmings; do it for your mother!

Comments

ark creature id list said…
If you want to see some god-awful WET code, look at some Teradyne TestStation In-circuit test programs (.tpg) files. Test generators generate this text file which contains code blocks (tests instructions) for each individual component on a circuit board. If you have 10 identical circuits, with 10 identical IC's, you get 10 identical tests (except for the node names or node numbers). The translator would not compile any function that accepted a node name or node number as an argument. There was no way to assign a node-name or node-number to a variable or pass it to the function used to set relays in the tester, so all connection information had to be hard-coded (almost always by the test generator software). This allows individual tests to be modified or debugged if needed without affecting other "working" tests, but it was a major pain. That was some of the ugliest code I've ever seen. It's sad that most ICT development relies on core software that was first developed in the 1980s and early 90s. They just redesign the interface about every 15 years, but they are still locked into using the same old software with all its inherent problems. In-circuit board testing is a dying industry. As boards become smaller and smaller, there is no room for enough testpoints for a bed-of-nails fixture. Plus, nobody wants to pay $10k for fixture and ICT program to test a $65 board, that will be obsolete in 3 years anyway. Electronics manufacturing is shifting to a production model where the few defective boards they build are just thrown away if they don't pass a functional test. You don't need good test technicians, rework technicians, or anyone who can troubleshoot (along with their higher salaries). That's progress for ya.
Read more



7:19 AM
eu4 console commands said…
I'm a bit sceptical about this hour of code movement. Sure it's great to code and all but you need to give people an understanding of what they're working with. The language for example hasn't been defined yet, so for all I know this could be any language until someone tells me what exactly what it is I'm working with. I think that we shouldn't tell people that anyone can do it, I think that we should instead say many can do it but with proper background knowledge. Also another problem arises from this movement which is that if everyone knows how to code in say Java for example, the actual people who have been in the field for a long time will start to make less since knowing Java is less of a rarity. I feel like this is the start of something bad, but I have no way of knowing the future. I just hope that this movement doesn't inspire too many people otherwise finding a job is going to be harder for me and others who have been studying different languages before it was cool. (I'm trying my hardest not to sound like a hipster right now)
12:11 PM
Shea butter soap benefits said…
when we will use the idempotent concept in programming , in which way it benefit program in any manner , and please give me some real world use of idempotence .Thanks

2:33 AM
Post a Comment

Popular posts from this blog

Enough software patent madness!

Say patent, and one might get a nostalgic tear in their eye as they envision a brave garage inventor, who, protected by his patent, earns what's due him thanks to legal protection against large greedy corporations. Enter reality. Now picture large corporations able to easily crush or control small businesses. Picture large companies being relentlessly attacked for money even though such companies have made every effort to respect other's claims. Picture an environment where anyone wishing to innovate is all but unable to do so because such effort will invariably step on an almost infinite and unknown set of patent "toes". To make things worse, there are those that are pushing for even more liberal patent laws , such as first-to-file, rather than first-to-invent. Something must be done to stop this! Patents are ruining the software industry and causing tremendous indirect damage to our country! Software shouldn't even be patentable. Patent law prohibits the
Read more

Virtual Appliances... poodoo

What I wish to address is this: "With the rise of virtualization, applications will transform into virtual appliances. Virtual appliances simplify application deployment by delivering the complete software stack—from OS to the application—as a single, integrated unit." -SDTimes Web Seminar Abstract Lest I be seen using VMs and am accused of being hypocritical: Virtualization is great for configuration testing. There is no better way to test against Oracle or Windows 98 without having to install such icky things than a VM. "Virtual Appliances", however, are a different story. Though they may “seem” exciting, and may be a practical solution given today’s technology and today’s problems, I find the trend disturbing. Why? ...Because a) the entire approach is grossly inefficient; and b) this is just another chapter in the long history of industry repetition. Setting aside the inefficiency aspect for a moment, isn’t this form of “run anywhere” virtualization exactly
Read more