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

24 Apr, 2009

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.

Newest Most Voted
Inline Feedbacks
View all comments
Andrew Phillips
Andrew Phillips
13 years ago

“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.”

If these kind of numbers were indeed readily accessible, that would make life a lot easier. In my experience at least, even getting “20% or so” out of someone can be difficult.
I’m certainly not trying to absolve developers from the responsibility of being able to provide these numbers. Even if that means smoothing out that timesheet from whose slavery we hoped Agile had released us, and actually measuring how much time an upgrade saves (and takes!).
But it seems that some things are just inherently hard to measure. Does anyone know of any good metrics that could evaluate the ROI of a significant refactoring? A metric that could really separate the value of the refactoring from all the other factors?

Andrew Phillips
Andrew Phillips
13 years ago

“they” is made up of people too. They live, eat and sleep, have hopes and dreams and love.
Are you sure? 😉

Vincent Partington
13 years ago

Serge, I’m confused. you start your blog referring to Robert Martin’s (he’s no uncle of mine ;-)) response to Nicolai Josuttis’s presentation. A response which you find “ultimately unsatisfying”. And you end your blog saying you haven’t actually seen Josuttis’s presentation and say that your blog is actually a response to _other_ IT professionals whining.
When I read Robert Martin’s blog I see a totally different story that does not actually disagree with your points. Robert Martin’s explains (once again) that quality is good and you explain that it is our duty as IT professionals to properly explain that to our stakeholders.
So how is Robert Martin’s answer really wrong? I get the idea that you are touching on different points than he addresses.

Rafael Alvarez
Rafael Alvarez
13 years ago

The main problem in selling “software quality” is that it is very difficult to prove that by enhancing the maintainability of your code you cut development time by 15%, because there is no hard facts to back you up.
One of the disappointing facts in the industry is that for the project manager “delivering late” is a lot worse than “delivering with bugs”. Have you never hear of some developer that committed a code that is wrong just to meet the date, knowing that it will later be fixed in the QA cycle?
I really wish that the only complain our user have is “they always deliver late”. At least they will receive something they can use.

Nicolai Josuttis
13 years ago

More about “a Mr. Josuttis” you can find at
And due to the reactions, I also started to prepare a web page about this keynote at
Best regards,

Explore related posts