Low Quality Code, And How It Causes Failure in Software Development

I’d like to talk to address one of the most misunderstood, but common reasons for failure in Software Development. It’s the number one reason we see software development projects fail. It’s called “low-quality code,” and it might not be what you think it is. This document is meant for the project manager leading the software project. It’s so often a problem that it beats out the other

So, what makes low-quality code? A few things:

• Large functions (code duplication)
• No objects, few functions, no libraries
• No documentation
• Spelling mistakes, and short function/variable/object names.
• Security Flaws
• Lack of consistency

The Hero

Give a hero some problem, and they hack a solution out, with the only concern being the initial time it takes. Copying code is their default, and they don’t create methods or find ways to reuse past logic. They certainly do not refactor the code, or worry about creating meaningful names for their few methods and variables. Instead, they build giant files with functions and features throughout.

When developing, the Hero is fast to complete small tasks. When called upon, they provide quick results. Report a bug, it’s fixed fast! Need a feature, “Wow, what results!” The Hero certainly seems to be all the solutions to your problems. For a while.

Eventually, the Hero inevitably becomes overwhelmed. The bugs, they’re too great to handle. Fix a bug, but it only fixes it in one spot. You test one spot, but miss all the others. Your users are unhappy, and your system costs increase drastically.

Then, the Hero is busy. Or the costs increase too much, and in a last ditch attempt, you call on another developer. But the new developer just makes everything worse. They’re slow to address issues, and they just can’t seem to resolve the problem. They complain about “spaghetti code” and they struggle to solve problems fast. Soon you hear them urging a “redesign.”

The Hero, who’s always so fast, has just bankrupted the project.

The Proper Method

The Proper Method is different. We start by avoiding the Hero role, and its entire premise. The Proper Method’s approach begins with requirements gathering, planning, and documentation.

Then we code. And this too differs. In the Proper Method, we build reusable libraries of objects and functions that we document. Inline documentation helps other developers find and understand the library used, and what functions to call as the system development progresses.

The characteristics of the Proper Method are that initial development is slower. Bugs, they exist, and we find them through testing. Occasionally, we fix one bug, only to find it breaks the system somewhere else. We recognize that our library was used incorrectly. We respond by improving the library and documentation.

When things change, the developers can go in and change things. The lack of duplication means the system becomes increasingly secure, more ironclad. And system development starts to decrease, when compared to the hero’s way.

So which way is better?

Though every so often, the quick hack can do wonders, the majority of times it’s the prepared, carefully thought out approach that wins the race. While the Hero’s application starts to strain, and eventually fail, the proper way grows stronger and stronger. Maintenance becomes easier, and the ability to support the project becomes less expensive. Leading most to recommend the quick hack only for small code basis.