The main business goals of code quality improvements are to 1) reduce the number of problems customers encounter thereby reducing customer support costs 2) red

The main business goals of code quality improvements are to 1) reduce the number of problems customers encounter thereby reducing customer support costs 2) reduce the amount of unplanned work/firefighting engineers do and 3) increase the pace of innovation. Therefore along with code metrics you should be tying these quality changes out to business metrics such as number of customer-filed bugs per a month, number of customer support calls a month, etc. This should provide validation to code quality improvements, and give you a way to sell further improvements to management. Also keep in mind that there are non-technical ways to improve IT efficiency (improve project management, improve release management, improve testing etc) So how do you go about making code quality improvements: 1) See if you can remove unused code/dependencies/features. Less code means less code to support, and faster compile and testing times. Look at metrics like code removed 2) Focus on the most problematic areas of the code and eliminate errors and bugs. If you can eliminate a significant source of unplanned work/firefighting, you'll have more time to spend on planning development instead of just reacting to work. These problematic areas are where tests will be most useful 3) Add static analyzers and linters to easily detect simple problems (like unused variables, style problems, problematic constructs such as if(foo = bar). As you develop your coding guidelines, implement the rules in these tools to automatically find these minor problems. This will allow your code reviews to focus on the big picture instead of nit-picky implementation details. 4) Do things to close the feedback loops for development. Consider running testing throughout the day. Maybe try to increase release cycles. Maybe add UX earlier in the cycle