“The lives of many people in the modern world depend on software, such as that which controls flight systems in large commercial airliners, and yet the field of software development is mostly unregulated. Anybody can become a self-taught software developer, and there are none of the certifications or rigors in place as there are for other high-stakes professions, such as sky-rise architecture or neurosurgery. It is a dangerously unregulated field, as a few lines of bad code could literally cause a loss of life, depending on the circumstances.
This quote being published in a mainstream publication, and its underlying theme appeared to be the sensationalization of the hidden threat posed by ‘bad code’ in the technology that surrounds us, including airplanes, trains, and self-driving cars. It seemed as though the article aimed to captivate readers’ attention, even though the danger it highlighted was largely invisible.”
So, what exactly is ‘Bad Code’ for the layperson?
For those unfamiliar with coding, here’s a simplified explanation of what a coder does:
“I build tiny assemblies of small doorways, that open and close in various ways and in various configurations. When the doorways open, electrons can pass through, and when they close, electrons are blocked. As the doorways are too small to build by hand, I have to have them built by my computer. Depending on the words I type into my computer, it builds various types of these small doorways on my behalf.”
This description conveys that software developers, coders, or programmers create things with a physical presence, albeit too small to see, which can be imagined as sets of small doorways. This in itself is quite remarkable. However, let’s return to the main question: What is ‘Bad Code’?
Sticking with the analogy of small doorways, bad code can be likened to having an excessive number of these doorways arranged in a needlessly repetitive or complex manner. Since visualizing this can be challenging, let me provide another analogy.
Imagine we need to build a device that turns a knob. This knob, when turned, should also rotate another knob located at a distance:
Poorly written code focuses solely on the immediate problem and suggests the simplest solution – a knob and a knob-turner, linked by a somewhat flexible rod. This type of code often appears to adhere to Occam’s razor, favoring simplicity at the outset. In contrast, well-crafted code might initially seem like overkill, utilizing a rubber belt and two wheels.
Requirement Change! The knob will be re-located!
As is customary in the development cycle, there comes a time when customer requirements evolve. In our analogy, the customer’s new request entails a knob turner capable of rotating another knob situated ahead and to the side of the original knob, as illustrated below:
Poorly written code necessitates the incorporation of makeshift components, rendering the entire system less stable and prone to failures. Conversely, well-crafted code only requires minor modifications when faced with new requirements and can easily address this issue by employing a longer rubber belt.
Requirement Change! The knob needs to turn slower!
At last, our customer has made it clear that they desire the knobs to rotate at different speeds. A slight turn of the input knob should result in a significant turn of the connected knob.
Given this fresh requirement, poorly constructed code must introduce even more components into the system, further complicating it. In contrast, well-designed code, once again, requires only minor adjustments, achieved by utilizing a larger wheel on the side connected to the knob:
In summary, good code may initially appear to be over-engineered for simple tasks but truly shines when requirements change or complexity increases. Bad code, on the other hand, seems adequate for straightforward problems but becomes a nightmare when the system evolves or becomes more intricate.
You might wonder, “Both systems achieve the same result, so what’s the issue?” This is acceptable for personal or hobby projects, where you might not need to maintain or expand the code. However, professional coding often involves collaboration, and your code will likely be read and modified by other developers, either now or in the future. For their sake, it’s best if the code is as easy to understand as possible.
Imagine being a junior developer inheriting a codebase from a senior colleague. Which scenario would you prefer: a straightforward explanation like “Here’s our knob turner; it consists of two wheels and a belt,” or a convoluted description involving intricate components and their interactions…
Fill-in the form to contact us about your project and we will write you a simple and clear code!👇
