What Is the Difference Between Bad Code and Good Code?
How coding practices impact your team, your product, your organization, and your bottom line. Learn the strategies of successful software development and the true cost of technical debt.
Bill grunted, his wrench slipping again. Sweat dripped on the old car engine.
Mike walked over: "What's up, Bill? Looks like a tough one."
”This stupid car won't work!" – Bill grumbled.
Mike pointed to the computer on the bench. "Maybe that could help? Find the problem faster."
Bill shook his head. "Ain't got time for that fancy stuff! This car needs to be running yesterday!", Bill scoffed. "I just need to dig in deeper."
"Your choice," Mike shrugged. "But you might be here all night."
Hours later, Bill was tired and frustrated. Hours passed and the car still wouldn't run.
Why The Code Matters?
Why did I decide to put this joke as an introduction to the article, you may ask? Well, let me explain. Like everywhere else in software development, the code is the running base foundation. The state of the code can slow down development more than tenfold, and continue to slow down exponentially…
Bill felt like the old car he was fixing – stuck and refusing to budge. He'd been tinkering for hours, but the engine still sputtered and choked. It was the same problem that had him stumped last week, and the week before that. Every time he thought he had a solution, something else broke.
"Sure," he'd tell customers, "I can fix it." But those words felt more and more hollow with each passing struggle. Sometimes, it seemed like he spent more time fixing past repairs than fixing the actual problem.
If you are a software engineer, it must sound familiar. The struggle with complex, poorly maintained systems is something many of us know all too well. And the frustrating part is, it's only 10% of the time we actually write code – the rest is spent reading and trying to understand existing code.
Among inexperienced developers, you can sometimes hear that they have no time to write high-quality code, since they have little time, or/and no one will read this code anyway. This mentality is a recipe for long-term disaster.
The truth is that in the process of constructing code, 90% of the time is spent reading the code and struggling with complexity, and only 10% of the time is spent typing characters on the keyboard (for some it’s no more than 1% of the time). And this ratio is also applies for high-quality code. This means that rushing to write sloppy code is like shooting yourself in the foot – you save a tiny bit of time upfront, only to create immense pain later on.
Moreover, the developer writes the code alone and only once. But all the developers on the team read the code, many times. A single developer's shortcuts can snowball into a massive time-waster for the entire team.
Thus, poorly written code contributes more than 90% (this percentage is, of course, purely an estimate) to slow down the development rate of the entire team. It's a hidden cost that cripples the entire organisation productivity in the long run.
The Self-Deception Trap
The phrases "there's no time to write correctly" and "we'll fix it later" are insidious forms of self-deception in software development. They blind us to the reality that over 90% of a developer's time is spent battling the complexity of existing code, not writing new lines. Therefore, poorly written code is the primary cause of a project's slowdown and the exponential decrease in development speed over time.
It's tempting to agree to write a poorer version of code as a shortcut, thinking it will save time and that problems will be fixed later. However, this mentality is also a trap that backfires in the long run. In the wise words of Randy Shoup:
If you don't have time to do it right, what makes you think you'll have time to do it twice?
Rushing to meet deadlines by cutting corners with bad code only creates a vicious cycle, where future work becomes harder, slower, and more stressful.
What makes code highly efficient?
The path to writing efficient code begins with acquiring specialized knowledge. Yes, I know that's obviously boring, but that's the hard truth. The same is true for any complex skill – we must study the tools before we can master their use.
I remember my own transformation upon diving into the literature on software design. The code I had once been proud of suddenly seemed embarrassingly crude. This echoes the experience of Mike in the opening story: learning how to use advanced diagnostic tools offers a clear advantage over struggling with bare hands and a wrench, knowing that sloppy work would inevitably need fixing.
So, what sets good code apart? At its core, good code embodies simplicity and fulfills the central development imperative of managing complexity. Dijkstra, a pioneering computer scientist and mathematician known for his significant contributions to the field of computer science once said:
Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.
Dijkstra also emphasizes the inherent limitations of human cognition when dealing with the vast complexity of modern software. To combat this, software engineers should not try to grasp the entire program at once. Instead, programs must be organised so that one can safely work on individual fragments in turn. This minimizes the mental workload at any given moment, reducing errors and design flaws.
At the software architecture level, the complexity of the problem can be reduced by dividing the system into subsystems. Several simple pieces of information are easier to understand than one complex one. Breaking down a complex problem into simple pieces is the goal of all software design techniques.
Keeping that approach helps to reduce the mental load. This is also facilitated by writing a program in terms of the problem domain, rather than low-level implementation details, as well as working at the highest level of abstraction.
Engineers who account for the inherent limitations and pitfalls of the human mind tend to write code that is clearer and contains fewer errors.
The true power also lies in adopting a whole new mindset. More than any specific book or technique, this internal shift is what takes your code to the next level:
Prioritise Software Design Principles;
Embrace Clean Coding Principles;
Use The Art of Refactoring;
Know Algorithms and Data Structures;
Understand The Value of Readability;
Embrace Continuous Improvement;
Even the most complex computer systems are built upon surprisingly simple concepts. At the end, good code is a code that is simple and understandable. If you find yourself struggling to grasp the logic and flow of the code, it's likely a sign that there's room for improvement.
Assessing the code quality from a management point of view
Understanding code quality may seem daunting for managers without a technical background. Yet, the impact of code – whether poorly written or excellently crafted – inevitably reveals itself through the rhythm of development activities. The pace of development serves as a check sign; a well-oiled team outpaces others, slowly but surely earning the trust and confidence of management.
Sometimes, you might find it hard to teach the team directly, especially if you're not in a leading role or can't always show by example. To management focused on immediate results, your focus on good coding practices might seem counterproductive, mirroring Bill's frustration when Mike initially suggested a more efficient approach. You're faced with a choice: try to protect management from their own decisions, knowing they might not appreciate it, or just go with the flow, even if it means not doing things the best way. Larry Prusak, one of the founder figures of Knowledge Management, once said:
Those companies that don’t adapt to understanding knowledge as a force of production more important than land labour and capital, will slowly die, and will never know what killed them.
This means if companies don’t see how important knowledge and good practices are, they’re going to fall behind without knowing why. But does this imply we should strictly prioritise code quality? Because in most cases, as outlined above, this contradicts the idea of immediate results or time to market.
Time-to-market vs Code Quality
The answer to whether companies should prioritize code quality over immediate results isn't black and white; it depends. Unfortunately, due to a lack of knowledge understanding, the trend leans more towards choosing speed over quality more often than not. This choice isn't always made wisely, leading to a preference for rapid development at the expense of sustainability and efficiency.
This mindset can culminate in a organisation where the mantra "everyone does it this way" becomes a justification for cutting corners. Developers may actively resist direction or advice, perceiving it as a distraction from their immediate tasks. “We've been doing it this way for years, and it's been okay..”, becomes a common refrain. Additionally, there's a defensive stance against improving practices, with some claiming that "books are written by theoretical consultants looking to profit off us, but we're the ones quickly producing the real code that the business needs."
Such attitudes not only undermine the importance of knowledge and best practices in software development but it further reinforces vicious cycle of poor quality work that becomes increasingly difficult to break over time.
The reality is, while fast delivery might meet immediate business needs, it often introduces long-term challenges, which will slow your productivity later.
Martin Fowler presents an insightful way to navigate the speed versus quality dilemma with the hypothesis of the Design Stamina. It offers a compelling perspective on the trade-offs between initial speed and long-term sustainability in software development. It posits that investing time and effort into good design may yield slower initial results but ultimately leads to greater cumulative functionality and a more maintainable project.
This hypothesis emphasises the deceptive nature of short-term gains achieved by sacrificing design. Investing in the code quality becomes not just a best practice – it becomes critical for ensuring projects can adapt, grow, and deliver greater value over time.
Good Code Saves You Money
It is also worth mentioning that we usually perceive that it costs more to get higher quality code, but in reality software internal quality actually reduces costs. Unfortunately, many good engineers, especially those in charge don't do a good job of explaining this situation:
The whole point of clean code and good architecture is to make you go faster
If this were not the case, individuals recognised as experts in their field, such as Uncle Bob, Kent Beck, and Ward Cunningham, would not devote their time to advocating for it.
As an example imagine this situation: your team starts with a burst of progress, rapidly adding features. But soon, changing the codebase feels less like development and more like an archaeological expedition. Each modification requires deciphering a tangled web of legacy decisions, and every change risks unearthing a cascade of bugs. This is the hidden tax of ignoring internal quality – and it's not just about wasted time. You're still paying developers to struggle with bad code, significantly increasing the long-term costs of maintaining the project.
TLDR;
The parable of Bill and his stubborn car repair mirrors the short-sighted mentality that plagues far too many software projects. Sacrificing code quality for the illusion of short-term speed creates a quicksand of complexity that grinds development to a halt in the long run.
Good code is built by skilled engineers, and if you're interested in how to find and nurture top talent, check out "The Hidden Power of Strategic Talent Acquisition" here:
All too often, I hear development teams complain that "management won't let us write good code... it takes too long." Developers try to make their case based on professionalism and they’re doing the right thing – a well-intentioned, but flawed strategy. It sets up a false choice between quality and speed, making good code seem like a costly luxury.
But in reality, good code is an investment, not a luxury. It's about respecting your time, the time of your colleagues, and ultimately, the longevity of the product itself. By embracing design principles, clean coding practices, refactoring, knowledge of algorithms, and a commitment to readability, you create code that is understandable, adaptable, and efficient.
For managers, the benefits of good code may not be immediately obvious, but they will be undeniable. A well-functioning codebase translates to a faster, more reliable development process, and ultimately, a happier and more productive teams. It's crucial to see the big picture, understand that initial investments in quality save money, boost efficiency, and increase product value over time.
The choice is clear: we can either be like Bill, stubbornly clinging to old habits, or we can embrace the wisdom of Mike and invest in the tools, knowledge, and mindset that empower us to write truly excellent code. Code that not only works today but will continue to work well into the future.
🔎 Explore more: