The Non-Repetitive Work Fallacy

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.

One thought on “The Non-Repetitive Work Fallacy

  1. blezs 2016-02-04 / 16:16

    Very interesting observations. SW dev is a low variation, repeatable activity. Creating an outcome or sometimes even output of a certain size and value in a certain timescale is where the unpredictability part kicks in. The output of our repeatable and predictable processes is very uncertain and unpredictable.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s