Duplicated code? Wrong term!
“Duplicated code” – that it is a very often used term. Sorry, but at least in my experience, I have refactored thousands of pieces of codes where this term is completely unappropriate: a code that it is repeated 5 times, 20 times or 50 times is MULTIPLIED not duplicated.
Using “duplicate” it is in fact a misinformation about the magnitude and severity of the problem. Consider, for example, a business rule multiplied with an average factor of 40 and a system with hundreds or more represented business rules.
DRY—Don’t Repeat Yourself: Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. (The Pragmatic Programmer by Andrew Hunt and David Thomas)
DRY dogma versus DRY spirit
A pragmatic approach will consider that many software systems are far for respecting good enough this principle or other principles. Anyway, if you want to control or fix the design it is better to focus first to what it is matter. We can found a lot of “duplicated”/multiplied code, but in some cases the consequences are more severe. Here are some example that you should never multiply:
- Business rules and algorithms
- Functionalities
- Entities
- Technical mechanism
More: if you have constraint to duplicate something – for example same business rule in java and DB code – you should have a clear map of these duplications that must keep synchronized.
Some simple questions
Just a simple question for code multipliers: having already a business rules multiplied of 50 times, what are the chances to find and change all of them if that rule it is changed? 5%? That is a programmatic bug generator.
Another question: what is the effort necessary for changing the same business rule in 50 places, where the most time is spent on finding these places? That is a programmatic destruction of the software economics
Another question: how it is possible to persist in such mistakes for years?
The answer could be a quote of “Land of confusion” Genesis song: “This Is the World We Live In“. Or maybe the song title it is the best answer.
Effects misunderstanding
The effects of multiplied code is in most of the cases deeply misunderstood.
“We have some poor design, but we will test and will work“
Really?
Too often there is this kind of bug report: if I execute the sequence a, b , c, d .. that feature works and if I execute the sequence b, a, c , d the same feature does not work. In many case does not work because is not the same feature! That mean not the same code. The main problem is that the testers usually checks the first sequence and will not check also the second one because they suppose that should be executed the same function and same code.
A multiplied code has a high probability to:
- not be tested for all occurences
- not be changed for all occurrences
- be melted in each occurrence with other pieces of codes and will highly increase the fragility of the product
More questions
The reverse question: (not if you have multiplied code, but) You have at least some examples of how to not multiply business rules, algorithms, functionalities, mechanisms?
Recap
- It is not duplicated code, it is multiplied!
- DRY first what it is matter most
- Multiplied code will (almost) never be fully tested
- Multiplied code will (almost) never be fully changed
- Multiplied code compromise the software economics
Agile Design = Adaptive-Lean Design 