This post originated from an RSS feed registered with Agile Buzz by Keith Ray. Original Post: Speed Over Quality Feed Title: MemoRanda Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics. Latest Agile Buzz Posts Latest Agile Buzz Posts by Keith Ray Latest Posts From MemoRanda

On Artimage.com/weblogs, Robert Martin writes "...then why would our company want to pay for crap that slows us down? Wouldn't they rather have good clean code that keeps us running fast? ... We often blame managers for schedule pressure. We often complain that our companies set unreasonable deadlines and have unrealistic expectations. This might be true, but it's only half the problem. The other half, the most important half, is within us. We consider our worth as programmers to be more associated with speed than with quality. And that's a tragedy; because it leads us to create messes. It leads us down the slower path. By rushing we ruin our chance to truly go fast." This generated a lot of comments, and one of my comments was the following:

Why do some managers managers value speed over quality? I can think of two reasons: they believe the buggy software is normal, or they get rewarded for delivering buggy software early.

The two ideas are often combined. If buggy software is normal, let's set an "aggressive" date for it to be "finished" (we're rewarded for meeting that date, even though nothing is really working well), and then spend twice that amount of time removing the bugs that were put in (and blame those programmers or those testers for any delays).

How did the idea of buggy software come to be "normal"? Because so few programmers are taught bug-reduction techniques like code reviewing, pair-programming, unit testing or test-driven-development in college, and relatively many programmers [none of whom read blogs like this or even books on these subjects] learn these techniques after college. And managers (with MBAs or otherwise), haven't gotten training on the value of these practices either.

[and check out these books - they're very timeless and enlightening: http://www.geraldmweinberg.com/books.html ]

Some commenters said that sometimes meeting the deadline is more important than quality, but that is actually rather rare. Most of the time, considerable effort is spent on bug-fixings. If quality was not important, why are we fixing the bugs? As Johanna Rothman points out, some companies are spending more than 75% of their time fixing bugs (rework).