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 at has reported that “the cost to fix an error found after product release was as one uncovered during design, and up to than one identified in the maintenance phase.” Systems Sciences Institute four to five times as much 100 times more 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”. 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. Make sure defects are being tracked , if you have not done so already. People can be a little touchy about others 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 Code review or “Peer review” judging 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. Implement a Style Guide, 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 folks who will inherit and need to support the . future codebase It doesn’t have to be huge, a style guide can be implemented in a single page cheat sheet! 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. Give importance to project knowledge. 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. Focus on quality first, and not on metrics that aren’t directly related to quality. 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. Encourage more collaboration. 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.
