Repetition – one thing happening again and again. It’s everywhere. Look at the trees outside and you see patterns of branches and leaves, repeated over and over.
Yet, when it comes to product design, business, software and other creative works, we strive to avoid repeating ourselves. We strive to make it “one of a kind”, a “unique” business proposition. “Don’t repeat yourself” is a common maxim in the software industry.
However, as in nature, repetition is frequent and common in software and elsewhere. And granted, it has often caused much pain and frustration. However, it may not always and necessarily be a bad thing. We might ask: “where does repetition make sense?”
In one of my former projects, working with a very experienced and trusted team leader, I was assigned to develop a new feature of the product, in this case, an online form, containing many fields and controls and some fairly complex interactions. After I had completed this, he tasked me to develop a new screen. And when described the new screen to me, it sounded so similar to the first screen that my immediate first thought was: “this should all really be done as one re-usable component, called by both screens”.
However, when I expressed this idea to him, he recommended against it. “Don’t do that – copy and paste!”. Suprised, I asked him if he was serious. “Yes!”, he said, “trust me”.
So I followed his advice, copied the existing code to a new file, and started working on the new requirements. And even though, at the start, they had seemed like very similar screens, as development progressed, the code started to diverge quite radically.
For example, a user would enter a figure on one form, and they would get one kind of error and a link leading them to a particular screen; whereas on the other screen, they might enter a figure into an equivalent field, get a message that wasn’t an error, or a link leading them to a different screen.
What I realised was that these are two very different screens. They started out the same, and I was correct to point out the similarities. But, over time, they were destined to diverge and become very different screens. Thus, it made more sense to start with a copy-and-paste.
What would have happened if I had gone with my initial instinct and created one “master” component, to serve both screens? Well, every time there was a difference between the behaviour of one screen and the other, we would have to add some kind of exception (e.g. an if-statement) to the “master” component. And over time, as these differences accumulated, the “master” component would develop into a mess of exception-handling, and the code would become difficult to read and maintain.
Instead, I ended up with two separate screens, each with its own behaviour, which could easily be modified if needed.
More broadly, the “mathematical” instinct may be to reduce, but the problem may not be one of reduction, but rather, of generative, divergent growth. In simple words: we may want lots of copies, so that we can easily modify each copy in a different way.
So sometimes “don’t repeat yourself” is helpful advice, but sometimes it’s not. If you know ahead of time that two or more pieces are going to diverge from each-other, and you want to be able to easily control and customise each of those pieces, copy/paste may well be a better strategy.