Speed vs Quality vs Feedback

gistfile1.md

(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.

+1

One concrete scenario that comes to mind is what can be achieved with tools like http://optimizely.com . It allows non-technical people to change how the website looks to the final user in order to run A/B tests and learn about what changes could improve the system. It's clearly not a sustainable approach to grow an application, but is a valid approach to get quick feedback.

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.

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.

@unclebob - I think, not surprisingly, that we are in a fair bit of agreement. However, things like "should not crash" - well, that's quality right there. And I may not know all of the cases they could make it crash. Or have robust error handling for a server suddenly going down. There literally may be no other spec except, "For now, this will never happen". That's the nature of prototypes - we have a limited set of information, and we're rapidly trying to get feedback.

Perhaps I should compare and contrast two approaches from projects I've worked on. The first was a brand new way of handling reports. We had never done anything like it before, and the customer wasn't sure exactly what they wanted. So we responded by sketching out some ideas, and then building it in small increments, with high quality. We knew the end was going to be a report engine regardless - we just didn't know what it was going to look like. The approach took us 6 weeks, and the engine has been in place for over a year, and we've been able to extend it now several times.

The second is a client who had no idea what was going to happen with an in-field trial. Were the customers even going to trust it? Were they going to use it? What issues could they run into? So we basically scaffolded a back end Rails app and a front-end iPhone application with a web interface. We did not rush, but we also didn't look for opportunities across the system to really refactor, or test as thoroughly through all of the use cases. That's because we knew what we were trialing - a smaller part of the system - but had to show the larger system as well. Users were given instructions on exactly how to use the system to provide feedback. But if they went outside those parameters, it was likely the system could crash, not work, etc. Which /the customer accepted as risk/ since we had all agreed that once we figured out how the users were actually going to use the system that we'd be able to regroup and restart. It worked like a charm - and the customer got the proper amount of funding from the first demos to pay for the rest of the development.

I'm torn by the conversation - I believe strongly in quality code, as you know. But I also understand the forces at play for a startup with an extremely limited budget, and I believe that was the angle Abby was coming from as well.

For those wondering about quality release levels - here's Enthiosys and Luke Hohmann's Slides on it. Well worth reading: http://www.slideshare.net/innovgames/establishing-release-quality-levels-and-release-acceptance-tests

Cory, my point in all of this is that the forces at play for a startup with an extremely limited budget do not conflict with being careful, and writing good clean code. You may not implement everything, but what you implement you implement well.