DRY – Don’t repeat yourself.
DIE – Duplication is evil
The above principles are applied in Software engineering to reduce the complexity, increase the quality and maintainability of the software(or any work product comes under the system). This principle coined by Andy Hunt and Dave Thomas in their book called “The Pragmatic Programmer” which is one of my highly recommended book for every software developer.
Every piece of knowledge should have a single, unambiguous, authoritative representation within a system.
This is applicable in the entire life cycle of a product from the design, to documentation, coding to test cases. This approach makes the software (or work product) high in quality and lower the maintenance effort.
For example, in my programmers’ life I’ve reviewed several code where we can find the same code is repeated across multiple files, or even multiple functions in the same file. The problem is the logic may have bugs and later if this part want to be removed or modified, we’ve to take care all part of the system to ensure we’ve properly modified it and ensure nothing is broken. This is increasingly complex if the project is too large and several people working on it. But if we define it in a single meaningful way and make the entire system make use of this unique piece of source code, that’s the best way tot manage complexity and maintainability. The cost for fixing such issues are very high. The bugs are always cost effective during the development period. Once if it’s released to the market, the cost to deploy the updates are too high and risky.
Not only Duplication, mostly the developers leave orphan functions which may cause confusions. for e.g. ProcessPresetChange() and OnPresetChange(). (Take it, I’ve see such kind of code several times). These functions doing the same stuff. How does it created? First a simple version of this function was implemented. Later due the poor quality of code, the new programmer has learned things himself and implemented another function which is invoked from a different user action. The previous function was written for test purpose. Anyway the problem solved temporally. Later, when another person wants to modify the same function, which one he will modify? The previous programmer left the orphan functions in the same source file. The new person has to find out where the functions are being called and replace it well. This is extremely costly and confusing.
The duplication can arise in several situations.
1. Developer is forced to duplicate the information as he has no other way.
2. Developer unknowigly duplicate the information without having proper understanding of what he do. The senior developers should orient the team members towards the data flow, architecture and the way to accomplish things before people start to work on the products.
class Line
{
int start, end, distance;
…..
};
The above class may find good enough to get things done. but what if it was written like this,
class Line
{
int start, end;
public:
GetLength(){ return end – start;}
};
3. Lazy programmers find duplication is the easiest way to get things. They’re the real evils.
4. When collaboratively working with large number of team, the duplication can be occurred from different resources. In this context the teams should share the design and other knowledge enough to work well each other. Reusable components are the solution to solve such kind of problems.
I’ve mainly talked in programmer’s point of view. This applicable everywhere like Database management, documentation etc.
On closing, Keep in mind “Don’t Repeat Yourself”
