Monthly Archives: March 2015

DRY principle beyond small talks

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


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?


  • 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

Before DevOps: Delivering more by delivering less

Undesired complexity give undesired deliveries

There are many aspects to consider related to DevOps and delivery, many strategies and (in the right context and the right approach) there are also some very useful tools. It is a complex issue and last thing that we want is to make that even harder because of undesired complexity. A poor and an un-appropriate design is the main cause of the problems.

Suppose that the main aspects of a product functionalities and design are the followings:

  • Functionalities: f1, f2, f3
  • Business rules: r1, r2
  • External frameworks, technologies, and drivers (APIs, hardware interfaces, others) e1, e2
  • External interfaces: i1, i2,
  • Technical mechanisms: t1, t2, t3..

Should stay together only what it changes and should be deliver together.

As generic rule, if one of this aspects it is changed, we do not want to affect, change and deliver others aspects. Below are some examples of anti-patterns.

Anti-pattern: Lack of functional cohesion

Just a start example: If was requested to deliver a change for the functionality f1, it is highly undesired to change also functionalities f3 and f4 only because f1, f3 and f4 are unnecessary coupled in the implementation. This coupling could mean: same function, same class or same package as opposite of using distinct design elements.

Anti-pattern: Non-DRY business rules

If the business rule r1 it is used in more functionalities (that have dedicated components) and that rule implementation is duplicated (multiplied) in every functionality, then a change in r1 will require change and delivery for all those functionalities and components.

Anti-pattern: Mixing functionalities with external communication

Suppose that f1 and f2 are using TCP sockets for communication with some external systems and we need to replace this type of communication, if the f1, f2 implementation is mixed with socket management aspects, then we need to change and deliver also f1 and f2.

Anti-pattern: Mixing functionalities with external interfaces

External interfaces could suppose handling of some specific external data structures and/or of some specific communication protocol. If we are mixing these parts with internal functionalities, with any change in the interface, we should change and deliver also some not related internal parts, .

Anti-pattern: Mixing functionalities with technical aspects

You need to protect the representation of the business inside the product from the changes related to technology. Where is the technology involved? Any I/O aspect that wrap the hardware: GUI, network, databases, file systems is strongly related to technologies and platforms. If, for example, you have a lot of functionality and business representation in the design of the GUI elements, any change in GUI technologies will affect the business representation inside the product, that should also massively changed and then delivered.

Anti-pattern: “Utils”

A symptom of a poor design that could cause undesired supplementary work on development and delivery are the “utils” packages, especially without clearly dedicated sub-packages. Examples:

  • “utils” package that mix together classes belong to different functional aspects
  • “utils” package that mix various technical aspects without having dedicated sub-packages

This kind of design suppose that we need to change, test and deliver the “utils” almost with any change of the product.

Anti-pattern: Dirty code

Breaking simplest Clean Code rules (similar with the ones that are used in refactoring) could cause undesired coupling and undesired increase of delivery scope. Some examples that could induce such problems:

  • Any duplicate/multiplied code
  • Breaking SRP principle
  • Global context data, global variables (breaking Law of Demeter)

Minimizing the need of change and delivery

We need to reduce the need of change and delivery only to the required ones. There are several practices and approaches that could avoid that problem (the examples presented above or similar ones):

  • Keep the code clean by writhing Clean Code first and refactor and pay the technical debt whenever it is necessary
  • Use functional cohesion as the main criteria of creating components and packages
  • Use Clean Architecture that propose a default, strategic separation of concerns
  • Extend XP engineering practices (Simple Design, Refactoring, TDD) with the ones from Agile Modeling and DAD
  • Respect Law of Demeter on any level of the design – do not use any global context
  • Make the products adaptive by keeping up-to-date with target business by often and early injection of feedback from that business.

You can argue that I already write about all these in a previous post “Roadmap to an Agile Design”. Yes, indeed, in order to deliver just what it is needed and avoid waste you must have an Adaptive Design, the main characteristic of an Agile Design.

In order to that you should be open  to all outstanding agile practices for design and do not be closed in the smaller universe of some very lightweight Agile methods. And remember that those lightweight methods are not created as full process methodologies, but as indications to build a customized process.

Imagine that all these problems are far worse if we have multiple variations and variants of the same product. The massive effort for any change and delivery will block the overall agility and responsiveness of the development team and massively reduce the overall economics for both development and customer side.

Use a strategic separation of concerns

Do not use any reference to any global context

%d bloggers like this: