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: 1. Deadlines You’ll hear excuses like we have a deadline to meet so we don’t have time to test or make the necessary design change. 2. The Broken Window […]
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:
You’ll hear excuses like we have a deadline to meet so we don’t have time to test or make the necessary design change.
Another contributing factor is the broken window theory. Here Philip Zimbardo, a Stanford psychologist, conducted a study where he parked a car in a well-to-do neighborhood for a couple of days and observed it. Well, nothing happened. He waited and waited and no one touched the car. He then broke a small window to observe if behaviors would change. Within a couple of 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’re already doing things wrong here, so it does not matter if we do it wrong here as well. Doing it the not so right way is a lot easier and faster, so why bother putting in extra effort to clean things up and do it correctly? One by one, mistakes spread and quickly spiral out of control.
Here, 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.
Sometimes the design is just bad, and instead of stopping to fix it we continue building on top of it and create an even bigger mess.
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.
The Top 5 Reasons Writing Bad Code Happens is the Second in a seven-part series on Technical Debt from Excella Software Development Lead Fadi Stephan.
Part 1: Top 4 Symptoms of Bad Code
Part 3: What is Technical Debt?
Scaling, like Agile itself, can become a target objective rather than the means to an...
You have individual, self-organizing Agile teams and they’re working effectively but struggling in certain areas....