Monday, September 17, 2018

Code Quality Deficiencies Demand Root Cause Analysis

Two cases of someone looking at water leaking from the ceiling. On the left, they look where the water lands and think "better get a mop". On the right, they look at the ceiling and think "Better find the leak". The former is labeled "not like this". The latter is labeled "like this".

Looking for code quality problems and then fixing them is really just another form of trying to test quality into a product at the end of the development process.

This simply doesn't work. Problems have root causes and. So long, as those causes are allowed to persist, new problems will continue to arise.

The more problems you face, the harder it will be to find or fix every one you have.

I'm not saying that you shouldn't fix a code quality problem. Of course, you should do that too, but it's not the end goal. Whenever there's a problem with your design, you should figure out what caused the problem and work to eliminate that cause.

Did it come from a lack of understanding about what kinds of designs work and what kinds don't? Spend some time investing in design patterns thinking.

Did it come from a lack of attention while you were attempting to expand scope too rapidly? Try to put something in place to remind you to clean as you go.

Did it come from a lack of communication? Figure out a way to make that better.

Finding issues and addressing them is a losing proposition. With processes and practices that generate design problems, the number of design issues generated will grow with the team and the product. Uncaught flaws make everything harder and take away time that could be spent perfecting the system, creating a compounding effect.

Your only real hope for sustainability is to stop problems at the source. So make that the primary focus and cleaning up coding issues the exception, rather than the other way around.