This article is based on numerous real life events. The names have been obscured to protect both the guilty, and the many innocent bystanders that have been harmed by their bad code.
Those that create code, and have to maintain code, live in a separate reality from the other stakeholders in the development process, whether they be the ultimate “owners” of the project, or the managers of the project. In the web development world, “code” can be HTML, CSS, JavaScript, or a server language like PHP or Ruby. “Bad code” can infest any of these.
The fruits of the web developer’s efforts are almost universally judged by how something looks, as if we were creating screenshots. It seems to be assumed if something doesn’t have glaring glitches, then the code behind it must be OK.
Maybe. Maybe not.
How often does it happen at the end of any project, that anyone (other than the developers), asks or cares about the quality of the code? Why should they? They can’t see it. They can’t read it. And obviously they can’t judge it. They only see the results of that code, much like judging a screenshot. So what’s easily perceived is weighed more heavily. Part of the problem we are addressing is that the problem itself is invisible.
The experienced among us have all seen many projects that are deemed “successful” by most yardsticks, yet hide some horrendous code underneath. So the question is, if most everyone is happy, why we should we want to rock the boat and say, “that’s not all there is to it”? Why should anyone but developers really care about good code vs bad code? You can still get a really nice screenshot with really awful code.
Here is the case against bad code:
- Bad code will be harder to read and understand. This will cause those who are working the code after the fact to take longer to edit something that might seem very easy and straight forward and this often manifests in serious time delays. There is a direct cost component to this.
- Bad code is fragile. Innocent updates and changes are more likely to go awry with new bugs. Seemingly unrelated features might break, leaving everyone to do some head scratching. This makes the person making the changes look bad, even though the blame should be placed elsewhere.
- Bad code is more difficult to extend and add features to. This is true for the entire lifetime of the application.
- Bad code takes longer to write in the first place than “good code”. Good code is clear, succinct, and to the point. One of the hallmarks of bad code is that it takes too many lines of code to get something done. It meanders. “Spaghetti code” is a catchphrase for code that jumps around too much.
What exactly is Bad Code?
Good question. Bad code is also sometimes referred to as having “code smell.” It can be difficult to look at isolated blocks of code and say “yea” or “nay”. While some bad code is visible to the average user, bad code is more likely to be very subjective and takes a trained eye (or nose) to spot. As a point of reference, some examples of bad code include: code that does nothing (yes!), inline styling, using tables for layout, incorrectly nested elements, duplicated code, lack of proper escaping, invalid HTML, excessively long functions or methods, too few functions or methods, poor or missing error trapping, not properly commented, and so on.
The bottom line is that bad code has hidden costs. It probably took too long to write, and it definitely will be more of a challenge to maintain. Think of it like building a house, and the builder uses substandard materials or hires inexperienced workers. The house will probably look just fine when it’s signed off on (or no one will buy it). The real costs of the poor workmanship is realized later when things start causing problems like wearing out prematurely.
So now we know bad code is, well, uh….bad. (And we don’t like “bad.”) To prevent something, we first must understand it. So then, where does bad code come from? Nobody ever starts out deliberately saying, “Let’s go create some bad code!”
While its always tempting to blame lack of experience, that is just one potential cause. Even an experienced coder that wanders into a new and unknown system or framework will require extra time in training, and will probably make mistakes the first few times using a new system.
Lack of experience can, and should, be offset by increased training, supervision and auditing. Everyone has to start somewhere, and none of us were really very good at this the first time out of the gate. We had to learn from those around us and from our own mistakes. Without proper coaching before, during and after a project, the less experienced will tend to create less than desirable code.
Poorly spec’d projects are another cause of “bad code”. Writing code is all about the smallest levels of details and connecting the dots of various internal components. The more those very small details are defined, and the relationships between components are understood, the better the chances of having a high quality finished product. Vagueness is our enemy.
And, projects that are perhaps well defined initially, but change course mid-stream, can result in band-aiding existing code to make it adapt to those changes. It’s the duct tape and bailing wire approach. There is a reluctance to go back and rewrite code that has taken significant time and effort already. This can lead to the “Winchester House” effect, where there are doors and stairways that lead nowhere, or are mysteriously located, and will be a nightmare to maintain, even if it looks great.
Finally, unrealistic budgets can put pressure on a development team to get something out the door on time and on budget. There’s always a way to cut corners, and curb appeal usually isn’t where that happens. It’s in the “invisible” part of a project — the coding. Low budget projects are fine, just make sure the specifications are low budget specifications and that whatever budget there is, is adequate for the tasks at hand.
The Fix Is In
So what’s the fix? How to make a project successful inside and out? For the planners, projects need to be well defined such that the people writing the code know enough to be able to write “good code”. A sentence or a paragraph is not an explanation, it’s a summary. Dig deep; create detailed sitemaps, workflows and wire-frames as needed for each feature. Make sure the project “details” can be handled by the project budget. If not, scale the project back, or increase the budget.
Use a framework, like WordPress, and adhere to the framework’s best practice. This will help create manageable code.
For the managers, projects should be restarted (at least the coding), if significant changes are made. Don’t allow “band aids” into a project. Make sure the development team has the information and resources they need. Don’t push them into guessing at how something should work. Lastly, inexperienced developers simply need more TLC before, during and after a project. It’s a learning experience for them, and teaching experience for everyone else around them.
