(From this thread: https://twitter.com/unclebobmartin/status/326189060311891970)
Abby is talking about speed of feedback. Why would we invest in something high quality if we have no idea if it is going to work? In the Agile world, Fast in exchange for Quality certainly does appear - we just call it "Prototypes" or "Spikes". Those are specifically designed to eliicit feedback without spending a ton of time on a solution we may or may not need.
Lean Startup principles take that a bit further - build something quickly to get feeback so that you know if the direction you are going in is the right one. That gives you customer feedback - and dollars - to be able to build a high quality solution. If something has bugs or doesn't work correctly for all cases, who cares if we are directing people only down one path to see how they respond to the system?
Like spikes, it has the danger of turning into the final product, at which point quality is a big concern. But I see no problem with advising customers who are trying to learn if a market is even feasible to build something quickly to get feedback, and then throw it away.
Going fast sustainably is only possible with quality - I think we all agree with that. But I can guarantee you I can beat out someone building an application with quality to build a prototype rapidly if we are only looking for feedback - not sustained growth.
I have seen quality code get trashed for external reasons, and spikes that never get thrown away. (I've got 5-year old FIXMEs in the Rails app I'm trying to rehab now.) The same uncertainty about the future that applies to validating your business model also applies to your code. You cannot know what will be thrown away and what will be kept. Even if you have the discipline to stick to your principles, you may not be the one making the decision. Code that works, for even the smallest values of 'works' tends to stick around and infect new code with its own level of quality, good or bad.
I completely agree with Uncle Bob on this - fast and good are not exclusive, and the time lost to crappy code outweighs any time saved on delivering (probably buggy) features almost immediately.