Comments on: To Fix Or Not To Fix?: Another Good Question http://www.threeriversinstitute.org/blog/?p=321 Thoughts on programming Thu, 29 Jul 2010 21:19:43 -0400 hourly 1 http://wordpress.org/?v=3.0.1 By: Is Pair Programming THE Agile Practice? « PierG (aka Piergiorgio Grossi) http://www.threeriversinstitute.org/blog/?p=321&cpage=1#comment-1272 Is Pair Programming THE Agile Practice? « PierG (aka Piergiorgio Grossi) Wed, 26 Aug 2009 04:28:15 +0000 http://www.threeriversinstitute.org/blog/?p=321#comment-1272 [...] adhering to principles or practices. So I agree with what Kent Beck point out in a recent article To Fix Or Not To Fix?: Another Good Question When I noted that tests needed to be used thoughtfully on the runway I was accused of abandoning my [...] [...] adhering to principles or practices. So I agree with what Kent Beck point out in a recent article To Fix Or Not To Fix?: Another Good Question When I noted that tests needed to be used thoughtfully on the runway I was accused of abandoning my [...]

]]> By: Herb Lainchbury http://www.threeriversinstitute.org/blog/?p=321&cpage=1#comment-1240 Herb Lainchbury Thu, 20 Aug 2009 18:11:45 +0000 http://www.threeriversinstitute.org/blog/?p=321#comment-1240 Great post. I also find it useful to distinguish my project components. The components are separated into two groups, common (i.e. framework and framework enhancements) and experimental (i.e. custom code for this experiment). Defects in common code are worth fixing because I use that code in many experiments and doing so improves all of my experiments. Fixes to defects found in code classified as experimental are optional. Great post. I also find it useful to distinguish my project components. The components are separated into two groups, common (i.e. framework and framework enhancements) and experimental (i.e. custom code for this experiment). Defects in common code are worth fixing because I use that code in many experiments and doing so improves all of my experiments. Fixes to defects found in code classified as experimental are optional.

]]> By: Tathagata Chakraborty http://www.threeriversinstitute.org/blog/?p=321&cpage=1#comment-1116 Tathagata Chakraborty Fri, 07 Aug 2009 14:34:52 +0000 http://www.threeriversinstitute.org/blog/?p=321#comment-1116 A slightly different perspective (and a naive question) - if number of defects start increasing (or rather say the rate of defects increases) doesn't that indicate that you are going too fast even when you are on the runway, and you might never be able to come back to Defects Zero? Does it make sense to track your defect rate? A slightly different perspective (and a naive question) – if number of defects start increasing (or rather say the rate of defects increases) doesn’t that indicate that you are going too fast even when you are on the runway, and you might never be able to come back to Defects Zero? Does it make sense to track your defect rate?

]]> By: KentBeck http://www.threeriversinstitute.org/blog/?p=321&cpage=1#comment-1112 KentBeck Thu, 06 Aug 2009 19:04:00 +0000 http://www.threeriversinstitute.org/blog/?p=321#comment-1112 Bob, I think the cost of defects depends on the number and attitude of the people affected by them. If a few knowingly bleeding edge users encounter a defect, it doesn't cost the company in the long run as long as the users can still get their needs met soon. If someone pays to just use the service and they encounter a defect, it is much more expensive. As I said at the end of the piece, the transition from managing a defect backlog to Defects Zero is hard but necessary. Bob,

I think the cost of defects depends on the number and attitude of the people affected by them. If a few knowingly bleeding edge users encounter a defect, it doesn’t cost the company in the long run as long as the users can still get their needs met soon. If someone pays to just use the service and they encounter a defect, it is much more expensive. As I said at the end of the piece, the transition from managing a defect backlog to Defects Zero is hard but necessary.

]]> By: Bob MacNeal http://www.threeriversinstitute.org/blog/?p=321&cpage=1#comment-1110 Bob MacNeal Thu, 06 Aug 2009 18:13:27 +0000 http://www.threeriversinstitute.org/blog/?p=321#comment-1110 Given programmers have finite capacity, often the choice is simple: implement new features OR fix bugs (...or build a framework that converges toward Defects Zero). If you're piloting this startup down the runway, you get to decide the value of those choices. Once you have a v1 product, do you agree with Anna Forss in a recent blog post where she says "Bugs create more detractors than features create promoters"? Given programmers have finite capacity, often the choice is simple:
implement new features OR fix bugs (…or build a framework that converges toward Defects Zero).

If you’re piloting this startup down the runway, you get to decide the value of those choices.

Once you have a v1 product, do you agree with Anna Forss in a recent blog post where she says “Bugs create more detractors than features create promoters”?

]]> By: Sebastian Kübeck http://www.threeriversinstitute.org/blog/?p=321&cpage=1#comment-1106 Sebastian Kübeck Thu, 06 Aug 2009 13:04:03 +0000 http://www.threeriversinstitute.org/blog/?p=321#comment-1106 Great post! You could argue in the same direction with lean: Defects are waste. They don't add any value to the customer and fixing them is expensive. Conclusion: get rid of them. One question: Suppose there is a team in transition to XP with a product in the cruise. They are working on a legacy system without tests and loads of bugs and feature requests. What options to they have to archive Defects Zero? Great post! You could argue in the same direction with lean: Defects are waste. They don’t add any value to the customer and fixing them is expensive. Conclusion: get rid of them.

One question: Suppose there is a team in transition to XP with a product in the cruise. They are working on a legacy system without tests and loads of bugs and feature requests. What options to they have to archive Defects Zero?

]]> By: links for 2009-08-06 « Dan Creswell’s Linkblog http://www.threeriversinstitute.org/blog/?p=321&cpage=1#comment-1105 links for 2009-08-06 « Dan Creswell’s Linkblog Thu, 06 Aug 2009 12:07:16 +0000 http://www.threeriversinstitute.org/blog/?p=321#comment-1105 [...] To Fix Or Not To Fix?: Another Good Question Defects Zero is a strategy for maximizing throughput. When a defect is reported, the team tests for it, fixes it, performs a root cause analysis, and remediates the source of the defect. While this is an immediate investment, it pays off over time. The team goes faster when fewer defects are being reported in the first place and when they can trust in their tests to tell them if the system is healthy. [...] [...] To Fix Or Not To Fix?: Another Good Question Defects Zero is a strategy for maximizing throughput. When a defect is reported, the team tests for it, fixes it, performs a root cause analysis, and remediates the source of the defect. While this is an immediate investment, it pays off over time. The team goes faster when fewer defects are being reported in the first place and when they can trust in their tests to tell them if the system is healthy. [...]

]]>