Or when you have a large, old codebase, Fear Driven Development means touching the code as little as possible for fear of breaking something that's huge, complex, 10 years old and largely undocumented, which nobody understands. This often results in the kludges becoming the majority of the code, and any actual knowledge of the system existing only in corrupted form in gray matter.

It's also similar to the one described above where every time someone needs a piece of functionality, he just writes it, instead of searching for what already exists because, again, no one understands it.

It also goes hand-in-hand with SWDD, Squeaky Wheel Driven Development, where no matter how bad the code is, or how slow or unstable it is, nothing gets fixed unless an important-enough customer complains loudly enough.

It also goes well with the Fire Ready Aim Development where the teams spend 3 months developing new features and 9 months fixing them. Agile is supposed to help with this, but if you don't have a robust automated testing infrastructure, good documentation and at least a little coding discipline, it won't. It's not hard for Agile to become nothing more than taking your huge bug-fixing and hardening phases and breaking them down into two-week-long chunks.

Then there's ITWWSTD, It's Done When We Stop Testing Development, where you plant a stake in the ground and shop what you have because you've run out of time before you've run out of bugs.