This blog post serves as a response to the article Software Testing Craft by Markus Gärtner, which can be found in the first issue of Agile Record.
As an apprentice, I remember thinking that solutions to software were either right or wrong. Later this was able to be simplified to either the solution works or doesn’t work. This became my base level understanding of a software solution.
Then came the time I thought solutions should be judged by how clean or efficient they were. This was my renaissance of aesthetics in the code. How to code your intentions expressively was the goal. This too became a new base level of understanding.
Now I am of the understanding that software solutions are a judged by factors of time. Making all the trade offs correctly so the code works and is readable, but also in the shortest amount of time possible.
The key thing here is to take the long term view of time. Not how much time in a single sitting, but every time you come back to the same solution. How often do you come back? How hard is it to change?
From the article, Markus says:
“As a software tester, you should take responsibility for the out- come of every decision you make. I call this the zeroth rule of professionalism.”
I think this is an elegant way of stating my understanding of software solutions. Every decision you make is a function of time and understanding. By taking responsibility for each of your decisions software becomes a series of trade offs that you have to live with and learn from. When a design works and is written well, it becomes easier to live with the outcomes of your decisions.
It is much like how I learned to play chess. At first I would make a move and try to understand the consequences in position and strength. Then I learned the common openings and endgames which helped me express my strategic creativity and play moves that had aesthetic value.
Finally came the important skill. Being able to project moves forward and do a risk analysis of each possible move. This let me take the previous skills and put them together in a coherent fashion.
I could understand how a move fatal to my king was a consequence of a move made much earlier in the game and learn from that decision. This skill is when I started playing chess as a game rather than a set of moves.
For me, it was only through the out-comes of my design decisions that I learn this lesson. It was very important for me to be in a position transparent to the positive and negative consequences of the code I write. Like the chess analogy, I need to project forward to attempt to understand the consequences of a decision before I make it.