If it hurts, do it more often
There’s a good chance that regular exercise will help you become a healthier person. The more often you go to the gym and lift weights (or whatever you like to do), the more strength you will gain, and as a result, the easier it becomes to repeat the same exercise. This is possible because your body will slowly but gradually adapt to the stress of exercise.
While that’s obviously a simplified explanation – there’s a lot more to be said about adaptation and exercising the right way without getting injured – this is generally true:
Practice something long enough and you will get better at it. Or putting it in a more catchy way: If it hurts, do it more often. Eventually, the pain will fade away.
The great thing about this principle is that it’s not limited to sports – you can apply it to any useful activity that can be done frequently:
- Do you consider yourself to be a mediocre speaker? Keep giving presentations at local user groups until you feel more comfortable.
- Do you have trouble writing blog posts? Make it a habit to write 250 words a day and the pain will vanish (mostly).
- A different kind of example: Entrepreneurs are supposed to wear many hats. By spending time in customer service, they can learn what it takes to provide great support – and only then consider hiring for the position.
Now let’s see how this idea applies to software development, using continuous integration as an example.
The pain of continuous integration
In his post, Frequency Reduces Difficulty, Martin Fowler writes:
Most programmers learn early on that integrating their work with others is a frustrating and painful experience. The natural human response, therefore, is to put off doing it for as long as possible.
He continues:
[…] if you do it more frequently, you can drastically reduce the pain. And this is what happens with Continuous Integration – by integrating every day, the pain of integration almost vanishes. It did hurt, so you did it more often, and now it no longer hurts.
But why is doing painful things over and over a good idea?
According to Fowler, there are three main reasons, all of them manifested in agile thinking:
-
Decomposition. Before you can execute tasks more frequently, you need to decompose large tasks into smaller chunks to make them easier to handle. Today we mainly talk about decomposing applications into microservices. However, breaking complex systems down into smaller classes or objects has been a best practice of object-oriented programming for decades.
-
Feedback. In software development, fast feedback is important in order to adjust more quickly to changes. Fast feedback involves reducing the time between modifying code and getting test results. Being able to do something more frequently, like integrating code changes, leads to faster feedback.
-
Automation. As I touched on earlier, practice – together with reflection – help you improve any skill. Having to redo a time-consuming task many times makes you want to automate it because you know that reliable automation increases speed and reduces errors. After feeling the pain for some time, you’re in a better position to automate the task based on newly acquired knowledge.
So pain doesn’t necessarily have to be a bad thing. It can lead to better systems that are decomposed, automated, and easier to change and reason about.
Our staging environment
We, the members of Jimdo’s Werkzeugschmiede team, also like to feel the pain before doing something about it.
For example, before investing time in setting up a proper staging environment, we had experienced how difficult it was to test changes prior to deploying them to production. Later, when staging was in place, we learned the hard way that our automation wasn’t as reliable as we thought. We ignored the problem for a while – again feeling the pain – until we finally decided to rebuild staging from scratch once a week, thereby ironing out any flaws in our automation.
There are still other things that hurt us in different ways. Let’s do those things more often and see where it leads us…