Do repeat yourself

Do repeat yourself

Long time, no post. Partially I was busy with other projects, but for a brief time, I was busy writing an article for ACCU. And, as you might have guessed, the article was called “Do Repeat Yourself”.

I encourage the reader to check the Overload 151 issue to find the article:

Although the article encourages some sort of repetition, I won’t repeat here the content of the article. Instead, I’ll have a few extra thoughts here, turning a bit meta.

First, how did I came about to think on this topic:

  1. While writing at the Golden mean in software engineering post, I was listing out traditional techniques for improving the way we retain important information; one of the most important techniques is repetition; but why don’t we use repetition in programming?
  2. During roughly the same time, I was seeing a lot of the repetition of the DRY principle (don’t repeat yourself). How can we repeat that much a principle that advocates for lack of repetition? Maybe repetition is not that bad after all.

Both, I believe, are good reasons to start pursuing the subject of repetition in software engineering.

Then, there is a big WHY. Why do we need to challenge such a well-establish principle like DRY? Like with any other thing in the world, we need to avoid excesses and practice moderation. We need to avoid ideologies, we need to avoid considering any idea as a universal truth.

Every idea/concept/model is built on top of some assumptions. We simplify the problem to retain what’s essential. The idea holds as long as its assumptions hold. If we extend the idea too far, the assumptions start to be wrong, and the idea starts to break.

That is why we need to always re-evaluate our ideas and our assumptions. We need to make sure that they still hold in this ever-changing reality.

Keep truthing!

LucTeo's Picture

About LucTeo

Lucian Radu Teodorescu holds a PhD in programming languages, and is a Software Architect at Garmin International. He likes challenges; and understanding the essence of things (if there is one) constitutes the biggest challenge of all.

Cluj-Napoca, Romania lucteo.github.io

Comments