DRY is commonly interpreted to mean that code should not have duplicate structures. For instance two array indexes that both use rand(4) would be refactored away. Let’s look at an example of code that does exactly that. Person.new(names[rand(4)], jobs[rand(4)]) At some point, this is perceived as duplication and an abstraction is put in place. This abstraction is not logically consistent with the domain logic. Person.new(random_item(names), random_item(jobs)) At first this inconsistency is not inherently dangerous.

Years ago, I watched Kent Beck’s talk on finding ease at work. He described death marches and unsustainable pace. He told stories of people having their humanity ignored, resulting in burn out and depression. Though, I was yet to experience life as part of a development team, my college experience allowed me to identify with those stories. He went on to discuss the pendulum swing between two states of engineering, the highs of being the team hero and the lows of being a failure.

Is your development team frustrated? Do they seem like they are going slower? Maybe you ask yourself, “Are they working hard enough?” They need something called slack — no not that chat app. They need time to reflect on their processes and try new ones to see if they can work more effectively. “How is that possible,” you ask. The answer is a techtro. Techtro: is short for technical retrospective.

In the words of Jimmy Two Times, “I’m gonna go get the papers, get the papers.” The Don’t Repeat Yourself (DRY) Principle is commonly interpreted to mean, code with no duplicate statements. I’d like to explore that thinking with you for a few minutes so that I can demonstrate how it is flawed. I have written a small program that displays the name and job of randomly created people. Take a look at the :random_person function.