Handling Fear

Fear happens. We are human beings and can’t avoid it but we can adopt practices to handle it.
Fear is related to the unknowns in software development, so we should work towards minimizing the unknowns by adopting practices already validated in the real world.
Let’s look at how the eXtreme Programming practices help us to handle fear.

Our experience tells us that when we have a piece of code without tests and we change it, we will certainly break it. Tests are our parachute, we can hurl ourselves from the airplane but we know that we’ll get hurt. We also know that the parachute is not infallible, we can make mistakes to prepare it or it can clog and fail to open while we are falling. We are afraid but with tests our fears decrease significantly. But fear is more subtle since, while we have tests, we also have memory of the past and if we got burned once, sometimes we are afraid to put our hands on the fire even with a fireproof glove. We are afraid, but also not brave. What can we do when we are in this situation?

• Don’t touch (100% fear, 0% courage). This is the most conservative solution, but if we have to fix a bug or to implement new features we can’t adopt it. In the real world there are very few scenarios where this strategy is actually applicable.
• Let’s head down (0% fear, 100% courage). We recklessly change the code and hope to not break anything. This is a very risky solution, most probably we will actually break things and spend a lot of time and effort to correct the mistakes.
• Small incremental changes (50% fear, 50% courage). To reduce the fear related to the uncertainty, we test and make small changes. With tests we know the current behavior of the code, so if we unexpectedly change it we’re immediately notified. Moreover, small incremental changes also mean that only a small piece of code can break, and that piece is easy to rollback or fix.

Romano Amerio says in his book (Zibaldone): “They say that the brave man has no fear. That’s false. Being brave means to dominate fear and where there is no fear there is no courage.”. I don’t know if we are brave, but certainly we are afraid.

In the light of this sentence, according to you which of the three solutions is the best? Unfortunately it is not always an easy choice.

Importance of Leaving Production Green

Deploys happen.

Actually, in a healthy web development environment deploys happen frequently, since there’s no point in keeping all those newly developed features only for ourselves.

When deploy time arrives, we take the current code from the continuous integration server, copy it to the staging servers and deploy it there. As a standard deploy step we also run a set of production tests, so that we’re reasonably sure that everything is working correctly. If the tests are green we consider the code ready for production, so we copy the code to the production servers and perform the deploy+test cycle there. If the tests are green, the deploy is successful.

Sometimes however the tests aren’t green.

Every morning in Africa, an xper wakes up. He knows he must run at full speed.

To run at full speed we always need to know where we are. Our mileage for the daily xp routine are some nice songs.
The day begins at 8:30 am with the reggae sound of “Get Up, Stand Up ” by Bob Marley which marks our standup meeting, if we are in the relaxation room (when we don’t code we are in relaxation room, more on this in a later post), we know that it’s time to end up in the development room.