So, recently, during an interview I have been asked if actually it was faster to write bad code. It got me thinking, I’ve read the point of view of Bob C. Martin, where he thoroughly explains that it is actually faster to write better code, but not having a chronometer, I just kept thinking about it, trying to find an answer that makes me happy.

Let’s start with the questions I asked myself. What is good code? In my opinion, good code is code that can respond quickly to change of requirements, that can be maintained and understood. So from this concept, I thought that possibly if I am the only maintainer of a code base, and I am aware of all the moving parts around it, can remember easily what to do when I need to do something, then good code for me could possibly also be a transaction script. I can just put around a bunch of if else, and production here we come! (God forbid testability)

So what should be good code? In real-world scenarios, good code should be code that is maintainable and understandable by anyone except the guy who wrote it, we use design patterns and principles that are known and shared between peers in order to get to write code that we can all work on.

So possibly the answer if it is fast or not to write good or bad code lies in “If you are already aware of shared good coding practices”, possibly going backwards to transaction scripts for some would be painful and slow.

News at 11? :D

How much I love the concept of “It depends”