Comments on: Do you worry about crappy code? Then face reality and grow up. http://blog.xebia.com/2009/04/24/do-you-worry-about-crappy-code-then-face-reality-and-grow-up/ Software development done right! Wed, 08 Feb 2012 14:41:38 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Nicolai Josuttis http://blog.xebia.com/2009/04/24/do-you-worry-about-crappy-code-then-face-reality-and-grow-up/#comment-91704 Nicolai Josuttis Sat, 09 May 2009 16:08:30 +0000 http://blog.xebia.com/?p=1510#comment-91704 More about "a Mr. Josuttis" you can find at http://www.josuttis.com. And due to the reactions, I also started to prepare a web page about this keynote at http://www.josuttis.com/WelcomeCrappyCode.html. Best regards, Nico More about “a Mr. Josuttis” you can find at http://www.josuttis.com.

And due to the reactions, I also started to prepare a web page about this keynote at http://www.josuttis.com/WelcomeCrappyCode.html.

Best regards,
Nico

]]> By: Serge Beaumont http://blog.xebia.com/2009/04/24/do-you-worry-about-crappy-code-then-face-reality-and-grow-up/#comment-91603 Serge Beaumont Fri, 24 Apr 2009 17:26:27 +0000 http://blog.xebia.com/?p=1510#comment-91603 @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... :-) @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… :-)

]]> By: Rafael Alvarez http://blog.xebia.com/2009/04/24/do-you-worry-about-crappy-code-then-face-reality-and-grow-up/#comment-91602 Rafael Alvarez Fri, 24 Apr 2009 16:45:56 +0000 http://blog.xebia.com/?p=1510#comment-91602 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. 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.

]]> By: Serge Beaumont http://blog.xebia.com/2009/04/24/do-you-worry-about-crappy-code-then-face-reality-and-grow-up/#comment-91601 Serge Beaumont Fri, 24 Apr 2009 14:49:15 +0000 http://blog.xebia.com/?p=1510#comment-91601 @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. @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.

]]> By: Vincent Partington http://blog.xebia.com/2009/04/24/do-you-worry-about-crappy-code-then-face-reality-and-grow-up/#comment-91599 Vincent Partington Fri, 24 Apr 2009 13:30:50 +0000 http://blog.xebia.com/?p=1510#comment-91599 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. 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.

]]> By: Andrew Phillips http://blog.xebia.com/2009/04/24/do-you-worry-about-crappy-code-then-face-reality-and-grow-up/#comment-91598 Andrew Phillips Fri, 24 Apr 2009 12:59:05 +0000 http://blog.xebia.com/?p=1510#comment-91598 <em>"they" is made up of people too. They live, eat and sleep, have hopes and dreams and love.</em> <a href="http://www.dilbert.com/2009-04-18/" target="_new" rel="nofollow">Are you sure?</a> ;-) “they” is made up of people too. They live, eat and sleep, have hopes and dreams and love.

Are you sure? ;-)

]]> By: Serge Beaumont http://blog.xebia.com/2009/04/24/do-you-worry-about-crappy-code-then-face-reality-and-grow-up/#comment-91597 Serge Beaumont Fri, 24 Apr 2009 12:21:46 +0000 http://blog.xebia.com/?p=1510#comment-91597 @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 http://gilb.com: 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. @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 http://gilb.com: 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.

]]> By: Andrew Phillips http://blog.xebia.com/2009/04/24/do-you-worry-about-crappy-code-then-face-reality-and-grow-up/#comment-91596 Andrew Phillips Fri, 24 Apr 2009 12:03:25 +0000 http://blog.xebia.com/?p=1510#comment-91596 <em>"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."</em> 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 (<em>and</em> 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? “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?

]]>