I have to admit: I am not the world’s fastest programmer. Actually, it is probably fair to say, “I’m not the world’s fastest at anything”. But when it comes to programming, I consider this to be a blessing far more than a curse.
When writing code I find myself doing a rough draft first. I then “reboot” my brain and look at the code again. Now comes the tidy up: “Is there a simpler way of writing logic expressions?” “Are the variable names expressive but succinct?” “Are there comments explaining what I was aiming to achieve with the code?” Over my years in the industry, I’ve witnessed times when what I would consider to be the rough draft is what is committed to the Revision Control System and the task is declared complete.
If the biggest difference* between draft and final version are things like formatting, variable naming and additional comments, is the code really compromised by submitting it in “draft” format? Yes! Long term maintainability suffers and this matters. Once bad code is committed to Revision Control, it is very difficult to remove. It takes a brave (or foolish) developer to cut swaths of “working” code. In a large system, you end up with areas of “bad code” akin to an ancient burial chamber. Daring to upset the artefacts in there will likely end up leaving you cursed and release untold horrors upon the world. Good code is more akin to a well lit and ventilated room – you can see what you are doing and there is little threat of initiating the apocalypse by altering the contents of the room.
Don’t underestimate the damage that hastily written “draft” code can cause. The impact of creating a maintenance nightmare is that bugs in this code can hide forever. If you think of your technical support department as a group that charges the company every time a bug is reported, you will understand why having bugs is a bad thing. Well, guess what? Every time a bug is reported, it is costing your company money.
What I am suggesting is that it’s OK not to be fast. There is always a competitive need driving your “time to market”. When analysed, most disciplines exhibit some form of compromise. When writing software, this compromise is often the trade off between quality and time taken. In other words, it’s a balancing act. In my opinion the best developers know almost intuitively how (or rather when) to make this trade off.
* Quite often code simplification arises out of the second look. That’s always going to be worth it!