Having a DRY week

I decided this year that I should try even harder to help improve not only myself, but also my colleagues. I believe in continuous self educating through small goals and small efforts over a small quantity of time. Thus I will attempt to make weekly challenges that can be focused on for one week at a time, and to start it all off our good old friend the DRY principle will be put to the test.

I am a huge fan of “The Pragmatic Programmer” — in fact I would consider it sort of my development bible. I owe a huge thanks to Andrew Hunt and Dave Thomas. One of the principles coined in that book was DRY, or Don’t Repeat Yourself.
The DRY principle states that “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

I try to always write DRY code, but when under a lot of pressure, with too little time and maybe even over worked I can end up duplicating knowledge throughout a system. And I do get very upset when i realize that I did so later on. Its time to cut the crap. DRY saves money — full stop. How many times did you copy that system wide default time format string? How easy would it be to change all over? Sure, some nifty regex search can probably find most, and a simple situation will not cost a lot to fix but it will still cost a lot more than changing it in one known place.

For one week I will not violate the DRY principle what-so-ever.

What makes this hard is that we don’t fully know what legacy code we have to tackle, and sometimes some knowledge is tucked into the legacy code behind a private interface method and it will be a hell of a lot quicker to just copy that little array of data, or that calculation, or that comparison.
This challenge will most likely force us to yield another best practice; Refactoring.

Dry up but don’t generalize

What is important is that writing dry code is not the same as making all your code general and suited for re-use from the get-go. As YAGNI states we must resist the temptation to add code that is not needed, and to assume that the piece of knowledge you are implementing at the moment will end up being duplicated in the future is just premature generalization.