>There are a couple of good blog entries on Quality and Speed.
- Ron Jefferies has an entry on why you can have both. Quality in your code, and timeliness to market.
- Uncle Bob has a follow up post in which he further explores the dangers of going for just speed of delivery (i.e. fix it and move on), over taking a bit of time to make it a quality implementation as well.
Many times, I see bugs fixed, or code that is added left in a draft state because it works. Mostly this has to do with the fact that people have way to many bugs and enhancement requests on their plate, and do not feel they have the time to address them all the way they should. However, not taking the time to make sure we have a quality implementation backed up by unit tests and other functional tests is just asking for more work later.
intellectualcramps 