(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.
The implication I am battling against is that you throw away the good coding rules in a lean startup. This is wrong. This is suicide. What you throw away is not good code. What you throw away is completeness.
The triad of "Good, Fast, Cheap" is missing a fourth element: "Done". Good, Fast, Cheap, Done: Pick any three. A lean prototype is a version of a product that is good, fast, and cheap; it's just not done.
A prototype, for the purpose of quick validation, can be buildt quickly, at low cost, with high quality. It can be good, cheap, and fast. What it will lack, over a final product, is completeness. It need not, and should not, be a mess. i.e. it should be a prototype of high quality.
But as a product, it won't be done. It will likely have a smaller feature set than the real product. Some of the features may be faked. Others may simply not function at all. It might not do all the validations the real project should. It might not be as secure as a real project should. It might not tie to all the external services the real project should. The UI might not be as fancy as the real product would. It might be written in a language or on a platform that cannot scale to the level the real product needs.
Still, though it is incomplete, it is not bad code. Indeed, if you want to slow down the development of the prototype, writing bad code is a very good way to do it. The fastest way to get that prototype in front of potential customers is to write the best code for that prototype that you can.
A prototype, for the purpose of a lean startup, should be carefully defined. The stakeholders should know what they are going to get, and what they are going to give up. If they are unwilling to give up anything, then they don't want a prototype, and they aren't a lean startup.
Once defined, the prototype should be written well, and should fulfill all it's defined functions. It should not crash, fail, or be unstable in any way. It should not leak resources. It should not have race conditions. It should not have bugs. No one should ever have to excuse a freeze or a crash with the words: "Well, it's just a prototype."
The one thing you don't want to communicate to your potential customers, is that you are hacks.