Do business people care about clean code? They behave like they don’t. Well, they do and I can prove it using proof by contradiction. For the best results, read this proof first.
Suppose that a business person does not care about clean code. The business person wants features and they want them fast. So they pressure engineers to just get the code working. This causes the code to deteriorate. The business person wants more features, but the code is a mess so features take longer to add and things that work start to break. If the business person wants features fast, they need clean code and if they need clean code they must care about it too, which contradicts the statement that business people don’t care about clean code. The contradiction proves the original supposition to be false, proving that business people care about code structure, even if they don’t realize it.
Sorry, but business people really don’t care about clean code. Believe it or not, but clean code is the responsibility of the programmers.
Thanks for the comment Daniel. Business people don’t care about code at all, except they need it. Would you say that business people care about the consequence of not having clean code?
BTW: I am totally clear on whose responsibility clean code is. Unfortunately many don’t know how to keep it that way and some blame business people for not letting them.
Which leads to “business people cannot see the causal relationship between clean code and getting features fast”
I think they can see the causal relationship, if someone points it out.
Business people care about the economics. A good business person would concern himself/herself with important issues that materially affect the economics. The accrual of high levels of technical debt has significant economic consequences and therefore should be something businesspeople care about. They may not care anything about the specific issues surrounding the structure of code in a given module, but they do care if technical decisions made in the module significantly affect the risk profile of the system (or their ability to make business requests with respect to the system) and therefore the economic outcome.
This proof only works if the feedback cycle is short enough for the “business people” to notice that the sizable tech debt is causing the slowdown in delivery of new features vs. that’s just how it is. If the feedback cycle is measured in months or years, there’s no way to tie the
Also, unlike actual debt, tech debt is difficult to quantify to the “business people” as it’s subjective. If the “technical people” can’t agree on the quantity of tech debt, it will be ignored by the “business people”.
Finally, “business people” are not rational — none of us are. We are not “Econs” (acting rationally to economic inputs), we’re Humans and therefore subject to cognitive biases and fallacies.
Business people care about software that works. If the code is not clean and leads to a brittle system, it leads to software that does not work. It’s the development team’s responsibility to educate the business in this way, as well as to make sure the pressures of delivery quickly do not cause them to reduce quality.