Do you worry about crappy code? Then face reality and grow up.

My colleague Age pointed me at a blog post by Uncle Bob about a presentation where a Mr. Josuttis presented the inevitability of crappy code because “businesses will do whatever it takes to cut costs and increase revenue, and therefore businesses will drive software quality inexorably downward”. Uncle Bob proceeds to go against that argument, but I find it to be a technocratic (DSLs and produce better code) and ultimately unsatisfying answer. My answer to the problem?
Face reality, grow up.

The main complaint is something along the lines of: “the business does understand the need for quality and make wrong decisions, trading in necessary quality for features”. So… it’s “their” fault, right? If only “they” would “take you seriously” and “just listen”? Well, what about making that happen instead of whining about it?
Fact of life: resources are finite.
Quality is a multi-headed beast where hundreds of trade-offs need to be made in design, architecture and features against the available resources. In any organization there is a finite amount of resources to go around. There are always more ideas, initiatives, problems and risks that need to be addressed than you have time and money. Every organization needs to make hard choices to allocate that finite amount for maximum effect. Everybody who has a stake of any kind has to justify the need for a slice of those resources: where in the rule book does it say that IT professionals are exempt from this responsibility?
There are many ways to achieve quality, and it is irresponsible and unprofessional not to take constraints into account.
Fact of life: “they” are not evil.
Funny enough, “they” is made up of people too. They live, eat and sleep, have hopes and dreams and love. The problem is not that “they don’t care about quality”, the problem is that “they” are not given a way to make an informed trade-off. In my experience quality is not unfairly pushed to the side when the value of quality can be clearly weighed against other needs. And if some quality is traded off, there at least is a valid business reason for it.
Fact of life: proving the business value of quality is YOUR responsibility: you are the only one who CAN.
It is not realistic to expect somebody who does not have the required expertise to judge the business value of quality based only on deep technical details. Therefore it is a responsibility of IT professionals to fill in that gap and translate those deep details into the business value it provides. This does not mean that you need to be a business expert all of a sudden: in practice it’s dead easy to just ask “Why?” a number of times until you’re at a level that is relevant and understandable to “them”.
“WHY do you need to upgrade component X?”.
– “Because it will improve its maintainability for that type of changes we see coming up”.
“WHY is maintainability good?”.
– “Because it will shorten our time to market by about a third”
– “Because it will reduce the effort required to implement that change by about 20% or so.”.
On a side note, this is the way to fix the – in my experience unfailing – trap of the bad “so that” clause in the “As a… I want… So that…” stanza. “I want a button so that I can go to the next screen” is cause and effect, not business value. The trick to fixing this is the same: ask “Why?” until you arrive at a level that allows you to compare user stories based on real business metrics. You can also use old “so that” clauses as the new “I want” so the team has more freedom: “I want to be able to go to the next screen so that…”. Stop doing that if it becomes to vague for the team, though.
Fact of life: to be taken seriously means to act responsibly.
When will you let go of a child’s hand in a busy street? When you trust that they are responsible enough not to run in front of a car. The analogy in an organization is that your opinion will be taken seriously if you are trusted to make a responsible trade-off between quality and other needs.
In Summary
So in summary this is what it takes to prevent crappy code:
– stop the “us-them” thinking. You are part of the business too, “they” are not evil.
– translate deep details into business value by answering a chain of “Why?” questions.
– make responsible trade-offs to be taken seriously and influence decisions
– AND ONLY THEN start implementing your favorite DSL.
I have not seen Mr. Josuttis’ presentation, so I am very aware that I do not know all the nuances in his opinion and story. So my answer is not so much to Mr. Josuttis as it is to the many IT professionals I’ve heard whining about “them”. Stop whining, grow up and do something about it.