Management Doesn't Care about Code Quality?... 3 Ways to Cope

You’ve been given a tight deadline. You just read Domain Driven Design by Eric Evans. *“The business NEEDS to put effort into code quality!”* you say.

You know that good code quality leads to: testability, readability, maintainability, and overall developer happiness. But your boss doesn’t. He understands the plight, but he wants “quick and dirty.”

*“Just put ALL the logic in the code-behind”* he says. For the business, DRY, SOLID, Decoupled isn’t profitable.

There are a few perspectives to look at this from. I’m calling it 3 “Ways to Stay Cool” because your view of the problem has a lot to do with the shaping of the problem into a frustration.

1. Don’t try to convince the business to care about code quality

Even though you know that thousand-line code-behind pages with WebForms couples the business logic with the presentation layer (aka the “Smart UI Antipattern” (Evans, 2003)), you don’t necessarily need to convince your boss of this.

It’s likely that your boss has a better pulse on the business and its customers than you do. Especially if his/her resistance comes from the unprofitability of internal quality.

Are the customers asking for changes to the application? Are they turning to other businesses because your internal code quality is low? If not, then you can totally improve your ability to write code with high internal quality without your boss being on board. You can even meet tight deadlines while doing so.

2. Show the business that high code quality enables you to deliver faster results

Martin Fowler describes a hypothesis that developers mistakenly adopt called the “Tradable Quality Hypothesis”. It is a hypothesis that we tend to make that internal quality of software is “tradable.”

We assume that internal quality is something we can trade for time and resources - i.e. put more hours into. In addition, we also assume that putting time into internal quality “slows us down” - the “Design Stamina Hypothesis”.

This isn’t the case in the long run, especially when you are dealing with more than CRUD complexity…

”…Instead it’s vital to focus on the true value of internal quality - that it’s the enabler to speed” (Fowler, 2011)

3. Prove that high code quality CAN: reduce bug reports, reduce speed to delivery, make change less painful, etc.

This requires that you be disciplined. Discipline yourself to focus on measurable quality improvement.

For example: a) count the number of reactive issues that your team has had to fix over the last month for a specific feature, b) perform some refactorings that allow you to c) wrap some better testing around the code responsible for this feature. d) measure the reduction in time spent (wasted) reacting to issues

This kind of cost-benefit analysis - though simple and obvious - might be the way for you to show management that technical debt costs money.