Code Quality - Part I

How would you measure and ensure code quality? 

Would clearly written user stories, comprehensive unit testing and end to end regression testing do the trick?

A lot of companies invest significant resources (both human and capital) into product managers, scrum masters, QA engineers and automated testing.

Is that a correct recipe for success or the result of outsourcing critical engineering functions to another team?

If all unit testing and regression testing completes without issues, does it mean that it is production ready?

What about functionality vs user stories? If everything checks out, is that a quality product?

The short answer is that unit testing, regression testing and user acceptance testing will not ensure code quality.

The reasons are very simple. First, you can have code that passes all the criteria above but would never pass a code review.

It goes well beyond common culprits like memory management or defensive programming techniques that are not being enforced.

What unit testing, regression testing and user stories don’t take into account are the very common real life edge cases and poor programming choices.

Second, too often software engineers working in large teams don’t understand the impact of their programming decisions on the entire code base.

Unfortunately these kind of things will come to light after the fact. After your users are impacted and/or after new functionality is required.

The end result is bad user experience, lost revenue and additional time and resources required to address it. The most likely management response? More detailed user stories and more time allocated to QA testing 

The right way to fix it? 

First, bring engineers into product design and allow them to learn the business (including edge cases) and to have a voice in the design process.

Second, let engineers specialize. When you need a surgical procedure you are not going to a family doctor. Your plumber will not do masonry repairs. It is time to bring the same approach to software engineering.

Allowing specialization would bring higher quality software by allowing engineers to invest the necessary time to go from “look it up” code to quality code.

Don’t forget code reviews either.