How Writing Good-Quality Code Reduces Expenses

There’s a reason why we want to build high-quality code - actually there are man. But in the end, it boils down to this one point. Good Quality Code Reduces Costs.

Longevity and Maintainability

When you create code quickly and cut corners, it’s like quickly building a house. Yeah, you can put up some walls really quick, but it’s not the kinda thing you’d brag about or feel safe in. It does block the elements, but it has low resale and it’s not very attractive. So, yes, you got the job done.

But what about when you need to add that second story on? Well, ok - you can try that, too - but it’s already pretty rickety. Now, you’re slapping up another level on to that unsteady base. Congratulations, you’ve got a 5 bedroom 3 bathroom 2 story house that the guy next to you in his 700 sqft. house is NOT jealous of. Yours even moves in the wind. But guess what? It accomplished the need. If you don’t look too close - if you don’t live in it - everyone can see you have a 2 story massive house now.

Time to add on a third story. Since it’s so unsteady, you have to build supports around the outside of the house to keep it from falling down before you build on the third story. Once that’s all done, you can remove the supports. That takes time - you never had to build supports and then attach them and then remove them. Now, there’s one thing you missed - so you have to run up there and fix it. You know… it’s hard to find people who want to go up on a third story rickety window and fix it - so you have to build those supports or get a specialized worker. But, it’s done faster than any neighbor’s houses - just its getting very difficult to add on to it and get workers to work on it.

When you build software too quickly, it can look flashy but it becomes like Jenga when you want to adjust things. Things that would take 10 minutes now, take 10 minutes + 30 minutes of testing/checking/defensive-coding to make sure any of the other hacks don’t break things. The longer this code runs in this format, the longer these ‘quick 10 minute changes’ take. It’s important to remember the more quick fixes you make NOW, the more technical debt you have - that is, the more ’testing’ and ‘checking’ you have to do in the future.

When you invest more money in the beginning, you can build a better piece of software. The argument I hear is that we will miss new sales opportunities! That’s right - you will - but that’s why you have to shift your project.

Shift Your Project

It’s fine to start out as a quick project. You actually have to do this to prove an idea, to get your first customers, etc.

But, as you get more customers and build out the product, you have to spend time to shore up the problems, and tie up lose ends. Time to make the software of better quality. If you keep quickly solving things, you end up getting new customers and new sales, but you’re jeopardizing your existing client base. Remember, when you have bugs, you reduce and erode trust - and those clients are hard to win back. It costs a lot more to win a customer than to keep existing customers happy. This is why you have to shift.

You can’t just build the Taj Mahal when you first start - but - it does make sense to look at the project as it matures and figure out when it’s time to shift to the better architecture. This helps reduce bugs in the long run - giving you something that his solid and predictable. And that’s what you want - predictability. It’s easier to estimate ROI that way - otherwise with the quick-short-cut method, it becomes less and less predictable how long a task will take.

Attracting and Retaining Talented Programmers

The higher quality your code base, generally, the higher quality the programmers that you can attract and retain. A less quality, less desirable programmer may focus on pumping stuff out the door - quick as possible. This, at first, seems attractive. But, you tend to realize this is bug-ridden code then. For the sake of speed, they start pushing out code that is half-finished - or - they don’t consider all edge cases. Before you know it, this is affecting your customer base. Yes, there are new features, but they are broken. Or even worse, the old features are no longer working. Trust me, your customers will notice this.

With these programmers and their software bugs, it means more of your time - as a business owner - is spent troubleshooting problems, testing software and dealing with customer service. Yes, the product got out the door quicker, but it’s a bad experience - and it’s wasting your time.

A good quality code base with a set of standards will help remove these type of people from your team - and this is what you want. The less quality programmer won’t be able to justify all of their decisions, they’ll miss important steps and basically be irritated with the whole process. The quality code becomes king - not their ability to release sub-par features. You want these people gone as soon as possible so you can make room for the quality programmers.

Great Programmers

Great programmers are proud of their work and want to write their best code. When you stifle this desire by pushing for “cheap” solutions, it can become a deterrent to stick with the team. Turnover becomes higher. “I want to write great code, that’s what I’m good at. But this company does not value that, so they don’t value me,” thinks the programmer. They move on. We know turnover is expensive.

With quality code, great programmers will want to stick with the project. Not only will they create more bug-free code, they’ll less likely to leave, reducing your HR and training costs. It’s cheaper in the long run to train developers to be better, and to keep up high-quality in the code than to have to rehire sub-par developers.

Summary

Writing great quality software may not be the immediate goal or direction, but it needs to happen, and happen quickly, in your project. You will have less bugs, higher stability, and attract a much higher caliber of programmers. All of this saves money and time in the long run.