Stop Expensive Bugs With These Proven Methods

I do alot of code reviews, and I see bad code written by people quite often. While it is completely normal for newbies to mess up writing complex code, even experienced and senior programmers can often write bad code.

The Systems Sciences Institute at has reported that “the cost to fix an error found after product release was four to five times as much as one uncovered during design, and up to 100 times more than one identified in the maintenance phase.”

Let’s look at some steps which aim to improve quality and can be helpful for any programmer, old or new.

Top-down management styles don’t work well for highly intelligent people, so implementation can easily be the most difficult part, as it may require changes to the normal workflow of the team.

Management has to implement these changes in the right way, that is, getting buy-in from the team — and not interfering with what works for individual developers.

For instance, try not to interfere with techniques people use to get into the “zone”, or high-productive stretches during the day. I call these periods “open field running”.

Make sure defects are being tracked and actively worked. This is already done by most teams, and is certainly done more than it was in decades past, however I’ve seen Enterprise dev projects that, believe it or not, are not tracking defects in 2017.

Implement a Code review or “Peer review”, if you have not done so already. People can be a little touchy about others judging their work — but a second set of eyes can uncover fine details that even a very sharp technical person may have missed. Have peers do the review, if a manager or technical lead is not available, or if its more suitable for the team.

Implement a Style Guide, which gives required styles to use. This is done by the big tech cos, less often by other orgs. For instance, returning out of a function can be an easier style to read than big nested ifs.

Returning out of a function can be easier to read than a multi if statement

Less important than what is “right” or not, is getting everyone on the same page — especially for future folks who will inherit and need to support the codebase.

It doesn’t have to be huge, a style guide can be implemented in a single page cheat sheet!

Give importance to project knowledge. It is very important to check whether the team entrusted to code a particular project has the complete knowledge of requirements, and a feedback loop with stakeholders. Having incomplete ideas can lead to bad decisions which harms the stability of the project in the long run.

Focus on quality first, and not on metrics that aren’t directly related to quality. Some companies still insist on having ETA’s and other benchmarks like “commits per day” or “issues closed” per day, which causes them to rush in order to fulfil their per day quota limits. Precedence of quantity over quality leads to bad code.

Encourage more collaboration. Developers who share ideas tend to have less mistakes, as more discussions lead to less errors. There has been a correlation between developers who stay isolated and the number of mistakes in their code, so it is imperative that collaborative developers are hired to ensure general code quality is maintained.

Implementing these ideas in your team can help them be more productive and ensure quality, bug free, and clean looking code while avoiding costly mistakes.