The Non-Repetitive Work Fallacy

It is not uncommon to hear people say that software development is non-repetitive work where the work always unique and rarely repeat.  It is not uncommon to hear people say that software development is a craft, an act of design and even divine inspiration and that we therefore can learn from other industries that is described as repetitive.

I think this is a fallacy, a fallacy I call the Non-Repetitive Work Fallacy.

The most obvious and most repetitive parts of modern software development is often described as this:

1. Think: Figure out what test will best move your code towards completion.
2. Red: Write a very small amount of test code.
3. Green: Write a very small amount of production code.
4. Refactor: Now that your tests are passing, you can make changes without worrying about breaking anything.
5. Repeat: Do it again. You’ll repeat this cycle dozens of times in an hour. 20-40 cycles in an hour is not unreasonable.

Description is adopted from James Shores blog post Red-Green-Refactor about TDD.

If you use the popular agile framework you will most likely have a number of repeating ceremonies that you perform on a regular basis e.g. sprint planning, daily standup, retrospective.

Are running you software development using continuous delivery approach you are most likely running the same delivery pipeline over and over again on a regular basis.

If you are developing software using Lean Start Up, then you are trying to go through the Build-Measure-Learn cycle as fast as possible.

These are only a few examples of how software development is highly repetitive. We are most likely developing different products every time, but the way we do it is often very repetitive. Especially if we are Agile.

I think there is a great deal we can learn from other industries and their approaches in software development. We just need to take a step back and observe how we do work, and not so much of the output of the work.