🆕What is good/bad code? An illustrated example for non-programmers

🆕What is good/bad code? An illustrated example for non-programmers

date
Oct 13, 2023
slug
what-is-good-bad-code-an-illustrated-example-for-non-programmers
status
Published
tags
Chia sáș»
SÆ°u táș§m
Study
summary
It is a dangerously unregulated field, as a few lines of bad code could literally cause a loss of life, depending on the circumstances.
type
Post
I once read a quote somewhere that basically had the following content:
“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.
I seem to remember that this was in some kind of mainstream publication. The theme of the article, I guess, was “Watch out for bad code, it can kill you, oh, but wait, it’s invisible so never mind!” Certainly a soothing message for readers, don’t you think? Seems in retrospect that the article was simply trying to sensationalize the lurking presence of ‘bad code’ in the airliners, trains, and self-driving cars that increasingly surround us, and thus increase readership.

So what is ‘Bad Code’, as a layperson?

As a person who writes, reviews and refactors code (meaning, to re-write in a more concise and usable fashion) for about 5 hours a day, I know what code is (and what bad code is, believe you me!). I sometimes lose sight of the fact that many people don’t have a concept of what code is.
For those people, I offer the following answer to the question “You’re a coder, what do you do?”:
“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.”
Make no mistake, as the above answer states, software developers/coders/programmers are actually building things which have physical presence, but are just too small to see (which can be envisioned, however, as assemblies or sets of small doorways). That’s crazy enough in itself, but if you can at least imagine that, you have achieved a conceptual understanding of what “coding” is, congratulations! But back to the question in the title of this section — What is ’Bad Code?’
Keeping with our tiny assemblies of small doorways analogy, I will say that bad code means that you have too many doorways, arranged in an unnecessarily repetitive or complex manner.
As that is hard to visualize or explain any further with the doorways analogy, at this point I would like to offer another analogy, as written and illustrated below.

Build me a knob turner!

Say we want to build a knob-turner. A knob that can be rotated, which will in turn rotate another knob in a remote location. The product requirement is as shown below. Turn one knob, and another knob some distance away will turn as well:
notion imagenotion image
This is the system we need — a knob that turns another knob.
Bad code thinks only of the problem at hand, and proposes the easiest solution — a knob and a knob-turner, connected by a semi-flexible rod. Bad code wins the Occam’s razor prize, at this early stage. Good code seems to be an overkill at first, and makes use of a rubber belt and 2 wheels.
notion imagenotion image
One point for Bad Code! Simple, with few moving parts!

Requirement Change! The knob will be re-located!

As always happens in the development cycle, at some point, the customer requirement changes. In our analogy here, the customer now wants a knob turner that can rotate another knob located forward and to the side of the original knob, as shown below:
notion imagenotion image
Oops! Product requirement change!
Bad code needs to add a few jerry-rigged components, making the whole system more rickety and susceptible to failure. Good code needs only slight adjustment when new requirements come in, and simply uses a longer rubber belt to solve this problem.
notion imagenotion image
Bad code has become an amalgam of rickety components


Requirement Change! The knob needs to turn slower!

Finally, our customer has decided that they want the knobs to turn at different rates. A small turn of the input knob should result in a large turn of the connected knob.
In light of this new requirement, bad code needs to add even more components to the system, making it even more complex. On the other hand, good code again needs only slight adjustment, using a larger wheel on the connected knob side:
notion imagenotion image
Two inserts and a funny-shaped rod? Who whilst maintain thou, bad code?

Analogy Afterword: So what?

As shown above, good code often seems like an overkill when requirements are simple, but then really shines when customer requirements change (as they always do). In other words, it scales and changes well. Bad code, on the other hand, seems simple and great for simple problems, but becomes a nightmare when the system changes or increases in complexity.
But maybe you’re thinking, “Well, both of the systems outlined above achieve the same result — the knob turner works successfully in either case.”
That is true — and fine for solo-coding or hobbyist projects. Lord knows that I’ve written tens of thousands of lines of bad code (vanilla JS, in my case), but it was okay, as I never had to maintain the code or add to it in any way (check out these 2,422 lines of source code for www.python-gui-builder.com, one of my hobby sites from 2020). The code worked, and I deployed it, and have never looked back.
However, professional coding is at heart a collaborative effort, and whatever code you write will undoubtedly be read and edited continuously by other coders, either in the present or in the future. Those coders will have a much easier and more efficient workday if the code is as easy to understand as possible.
  1. “Here’s our knob turner, it consists of 2 wheels and a belt”, or
  1. “This is the insert to hold the connecting rod, this is the connecting rod, and you have to put the end of it into a little hole up here in this other insert
”
Which would you rather hear, as a junior developer taking over the code base from your senior? :)