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

Serge Beaumont

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.

Comments (8)

  1. Andrew Phillips - Reply

    April 24, 2009 at 1:03 pm

    "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?

  2. Serge Beaumont - Reply

    April 24, 2009 at 1:21 pm

    @Andrew: I intentionally left out the term "metrics" since that is not the answer, at least not the "techno-metrics" that we tend to use already. In many cases it is not necessary to come up with an exact number. The reasoning chain is a decision tool, not a mathematically correct formula that will give you the answer on a golden platter. You do the best you can: every bit of objectification, however small, helps.

    There is already value in clarifying what is being impacted without putting numbers on it. Does the "Why" chain lead you to time to market, or to cost per order? That is already very valuable information.

    Having said all that, my experience is that getting the numbers out is much easier than is commonly assumed. It's a bit too much to tell how in a comment, so I guess I should write a blog post about it. In the meantime you could have a look on I use Gilb's ideas to achieve this.

    On your question of measuring the value of "hard to measure things" like a refactoring: you don't have to measure at that level. If you have a chain of "Why?" answers you can also measure one of those, meaning you don't measure it directly, but its impact on a higher level measure. For instance, in a current assignment I don't measure all the details of deployment problems. I measure the end-to-end time needed to upgrade a whole environment, and improvements are valued as the expected impact on that end-to-end time. This works out very well in practice.

  3. Andrew Phillips - Reply

    April 24, 2009 at 1:59 pm

    "they" is made up of people too. They live, eat and sleep, have hopes and dreams and love.

    Are you sure? 😉

  4. Vincent Partington - Reply

    April 24, 2009 at 2:30 pm

    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.

  5. Serge Beaumont - Reply

    April 24, 2009 at 3:49 pm

    @Vincent, I never said I disagree with Robert Martin, just that his answer is not enough. He does not address what I see as the core problem: selling quality and getting the time and money needed.

    My post is a response to Bob's post combined with my own experience. I could have ended with "Mr. Josuttis, grow up", but that would have been silly since I've only seen Bob's response, not the original presentation. He might have put in many nuances that Bob didn't catch in his post.

  6. Rafael Alvarez - Reply

    April 24, 2009 at 5:45 pm

    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.

    • Serge Beaumont - Reply

      April 24, 2009 at 6:26 pm

      @Rafael, I guess I REALLY need to write an extra blog post :-). I have found that obtaining those "hard facts" is easier than you might think. So start with a switch in mindset: just start with the assumption that it is possible, and see how far you CAN go... 🙂

  7. Nicolai Josuttis - Reply

    May 9, 2009 at 5:08 pm

    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,

Add a Comment