A few years ago everyone was obsessed with Quality software. The Q in Quality was capitalized to emphasize the word's importance. Hours of procedures and inspection processes were introduced, along with reams of paperwork, in an attempt to make software less buggy. More recently, the trend has moved towards more lightweight processes with agile software and extreme programming. This is still a positive move since ensuring software quality remains important. Some analysts estimate that up to 60 percent of software faults can be automatically detected. Is there, then, anything we can do to build a bridge between yesterday's dinosaur of quality fixation with today's obsession to get things done quickly and cheaply? Joe Walker examines different types of bugs and seven tools to help you uncover them. (2,600 words; November 21, 2003)

Many people intermingle hard tabs (ASCII 09) with spaces in their source code, rather than using n spaces in the place of a single tab, where n is usually 8.
It's a matter of personal taste, but here's why I don't believe this is a good idea in general.
(...)

• It's less portable : since different editors/pagers render a hard tab as varying numbers of spaces, and most editors can have this number altered on a per-user basis too. (...)
• It makes context/unified diffs far harder to read, because of the way they use the first column to indication the manner in which the line has changed. (...)
• It makes re-indenting sections more difficult. (...)
• The `tabs are good because then you can choose your own tab width' argument doesn't work because
• Tabs aren't just used at the beginning of lines. (...)
• (...)