As developers we assume that the right thing to do is add more code to our software to either fix bugs or add features. We assume that the code that’s already there is precious and there for a reason, and we assume that our actions should result in more code. Nobody can believe that you’d get MORE out of a piece of software by SUBTRACTION.
I’m not about to tell you that your features will grow the more code you delete. However, I am going to tell you that the bias towards adding to the codebase is something you need to actively resist to make great software.
Consider the following code segment:
# go into the selenium directory and remember the cwd pushd selenium ../lib/command1.sh ../lib/cleanup.sh # there's a bug on this line - command not found lib/bootDatabase.sh # reinstate the cwd popd
Looking at the above, you can easily see the bug. From the
selenium directory, a peer of
lib, the third command cannot be reached as it is missing the
I would bet that 75% of developers would fix the above by adding
../ to the buggy line. This is because of two biases:
- The developers must add code bias
- Tunnel vision on the broken line of code, assuming the rest is ok
If you’re shouting at this screen that the actual error lies around the three calls to
lib then buy yourself a coffee and send me a selfie of you drinking it. The issue here is that the
popd statements are, for this method, adding nothing. This routine would have been much better if the current working directory had either been left alone, or changed for
“Ah!”, you may cry. “What if the commands need a current working directory of selenium?”. Great question. Do they? With the above code segment, you could argue it either way. With your OWN CODEBASE, you can GO AND FIND OUT. Leave a note for the developer who follows you to explain anything they need to know about why this is not simpler.
In the real-life example I took this from, the
popd pattern (the first time I’d seen it used) was in many of the methods and this was just a copy and paste error where the
selenium runner script had been pasted in as a template and the commands hadn’t been removed/checked.
I think the above script example would naturally turn into:
lib/command1.sh lib/cleanup.sh lib/bootDatabase.sh
I have removed the push/pop because in this example, there’s no benefit of manipulating the current working directory; simplifying the path to a script being of modest benefit to me.
By double checking assumptions and trying to avoid biases, leaner and neater code can be achieved, with less chance of future error.