6/20/2012
The DRY principle is kind of a known concept to most software developers. it goes hands in hand with “Minimize Duplication” (4 elements of simple design by Kent Beck) “Single Source of Truth” and probably some more of this kind.
But lets start with a story
I hate Wasting Time
This week I was sitting doing some pairing trying to setup their first Given-When-Test using nBehave. We went through the regular steps: creating a new empty project, setting up a new empty spec test running it seeing that it fails and started working on actually doing something meaningful by loading up the application DAL into the test context.
10 minutes into the process, executing what we had resulted in a very nice FileNotFoundException and some text talking about that the need to use a strong name assemblies only.
Great!
Of course Microsoft was generous enough to omit the name of the actual file (which probably would have saved us most of the time in fixing the problem and your time in reading all this) but anyway 1 hour later we noticed that the code base has several 3rd parties dll’s appearing in the wrong places and they were all checked into the source control AND to make things happier they were not of the same version. In short we had mismatching dll’s duplication.
Of course, like always, after I fix a problem everything seems so obvious and I cant figure why I didn’t understand it much earlier. but anyway after 2 more minutes we had that one thing solved and we actually were ready to do some serious work. At that point however we ran out of time so we scheduled to continue another time.
Duplications are Evil
Yes the DRY principle which wikipedia defines as :"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." applies to more than just code and code design. It applies to all parts of the system, in my case it can be restated by the common sense directive:
You shall only have a single copy of any 3rd party dll checked into your source control
Yes I feel stupid
So where else can DRY be applied? What example do you have?
Want to adopt Agile and don’t know where to start?
click here to learn
Posted in: 
Posts
2 comments:
I would like to know, when would you consider that the DRY prinicple shouldn't be used?
I'm not sure i have a good answer for that. Two things that do come to mind are:
1) I would repeat things if i feel they contribute to the understanding more then the cost involved in repeating
2) I think i will use repetition as a way to emphasis an idea in order to make it clear it is important.
(I don't have a good code example for that though)
Does this make sense?
Post a Comment