In my previous post, I discussed symptoms of bad code. Here I’m going to look into some of the reasons we end up writing bad code:
- Deadlines – You’ll hear excuses like we have a deadline to meet so we don’t have time to test or to make the necessary design change.
- Broken Window Theory – Another contributing factor is the broken window theory. This refers to the study that Police conducted in NYC where they parked a car in a bad neighborhood for a couple of days and observed what would happen. Well, nothing happened. They waited and waited and no one touched the car. They then broke the small rear window to observe if behaviors would change. Within 4 hours, the car was totally stripped. Gone were the tires, wheels, electronics, steering wheel, seats, mats, and engine. What was left was a skeleton of a car popped up on cinder blocks. Well the same thing happens with code. You start out and things are clean. Once you introduce one sign of bad code, things quickly get out of hand. As developers, we’ll say, well we are already doing things wrong here, so it does not matter if we do it wrong over here as well. Doing it the not so right way is a lot easier and faster so why bother putting the extra effort to clean things up and doing it correctly. One by one and soon things spread and quickly spiral out of control.
- Over Architecting – We attempt to envision all possible future scenarios and create unnecessary layers of complexity to support things that are not really requirements and might never actually become one. As developers, we think we have a crystal ball and can predict future requirements even though the client is not asking for it. Sometimes things pan out, but in most cases, things go in a different direction and we end building something that is not needed or does not quite fit the desired solution.
- Bad Design – Sometimes the design is just bad, and instead of stopping to fix it we continue building on top of it and creating an even bigger mess.
- Poor Skills – Of course, poor skills or lack of proper training is also a major contributor to bad code.
In my next post, I’ll introduce the concept of technical debt and discuss good debt vs. bad debt.
