Code Quality Matters: Success

I’ve had a bit more time recently to reflect on the importance of Quality Code since I first defined it. If you don’t recall, my definition of Quality Code is this;

Quality code is code that can be changed, as needed.

In the introduction to that post I mentioned that I’ve experienced debate about whether or not code quality is important. I think it is and today I’ll give just one reason why.

Success is important.

Success is important isn’t it? It’s a bit nebulous though, so let’s be clear. I’m talking about real professional and raw commercial success. Making money. Gaining customers and revenue. For most of us that’s what it’s all about ultimately. If you’re a hobbyist then only your personal enjoyment defines success. Professionals have to compete.

You’ll be out of a job if you write bad code, sooner or later.

Many development teams hire on a trial basis. I’ve seen a few new hires that weren’t offered a full time position after their initial contract was up. The code they wrote just wasn’t good enough. It caused more work for the remainder of the team. It had hidden bugs that increased the burden on the maintenance team. It couldn’t be reused without refactoring it. Peer reviews took much longer because there were so many changes needed. Sometimes pair programming was necessary just to get anything done.

Sometimes even good programmers write bad code though. An approaching deadline is immutable and so are the requirements. Cutting corners is the only recourse, but that leads to bad code. It works, but it can’t be changed as needed. When it hits a critical mass…

Projects can fail.

It becomes too hard for the project to change to meet changing needs of the stakeholders. Or the project is too unstable. Customers are unhappy. Something has to be done to fix this. Sometimes that means starting over from scratch. You might not get a second chance to fix your mistakes. That’s just the nature of business. Would you choose any differently? Would you entrust a critical rebuild to the same team that made it necessary?

Here’s the kick on the way out though, it won’t be just you and your teammates. It might be the support staff your project supported. Administrators, testers, the project manager. As a developer you may have recruiters calling you that same day. Is the same true for the people you worked with?

Organizations can fail.

Even if the project isn’t ever scrapped, it can still be a failure. When that happens the organization itself can fail. Customers leave quietly. Sales drop. Staff reductions are necessary to stay in business at all. Soon the project is in maintenance mode, there aren’t enough resources to do anything but keep it alive. Ultimately the company goes out of business or is sold off by the owners.

Bad code can ruin a business, your career, and the careers of people you work with. The stakes are high in the professional world and the challenge is all the harder because many stakeholders don’t know they care about code quality. They do care about getting things done when and how it’s needed. Only Quality Code can enable developers to meet that standard. The responsibility for it is ours.

Written on December 12, 2014