"Fail fast" is no excuse for being a moron, flake or scumbag

Well said, and there are ethical reasons why this is unacceptable.

Tech demos are supposed to be scrappy. Minimum viable product. Twitter put up a fail whale early in its lifespan. So what? I don't think anyone's career relied on it being 100% reliable, and anyone who did bet his career on such a thing was being reckless. Twitter did the right thing by getting something good enough out there and iterating.

Management affects too many people for that approach to be tolerable. You have to actually know what you're doing before you act.

I haven't read Eric Ries, so I have no opinion of him. I know that people are using "fail fast" to justify being ethically sloppy. I don't have any basis for assessing whether this has anything to do with Ries. Quite probably, it doesn't.

I've watched ethics deteriorate over the years in the Valley. I support the one person who can see through this ongoing shit-baggery.

Most of my direct experiences are in New York. I've never spent more than a week at one time in the Valley.

I don't think I'm the only person to spot the problem. Most people are afraid it will hurt their careers to speak up about it. I'm not as worried, because I know that I'm talented (i'm not worried about blackballing myself) and someone has to do the "dirty" work of blowing the whistle.

My first whistle-blowing experience was at Google, which was odd because people (a) acknowledged that some of this shit had been going on for a long time, but (b) really didn't want to hear it. They wanted to ignore it and still believe in their Googley workplace utopia. I literally have thousands of people (from G.) who've never met me but think I'm a loose cannon because I blew a whistle on someone else they never met. The thing is, though: it's a whistle, not a gun, that I'm waving. If you don't do scummy shit, you don't need to worry.

I feel that you're missing an important consequence of "failing fast". That consequence is something that struck me when I was reading Ries, but I don't think that one must read Ries to realize it. You write as if your peek from a systems perspective provides a ready answer to why "failing fast" could be a good thing, but it doesn't. Here is the best I can do to explain myself.

Startups are hard. People put a lot of work into them. Oftentimes, the work turns out to be in vain. The "in vain" part is precisely what makes startups hard. If the work one put into a startup was not in vain, then almost by definition doing a startup would become no different than holding a 9-5 job except with longer hours. Now, "failing fast" means that the moment when you learn that the work you did was in vain comes sooner rather than later. Thus "failing fast" reduces the amount of work you do in vain, which is generally a good thing. So far this is no different than the systems thinking and your analogy with compilation/runtime engineering process you describe.

Here is the crucial part though. By going somewhere and finding out it's a dead end, you learn something (gain information). Now fixing a bug early rather than late provides you with no new knowledge, so this is where the difference I'm talking about comes in. Think of knowledge that a certain directions are dead ends as if it was some surplus value. You accumulate that surplus value the more "dead ends" you try. If exploring dead ends had no associated cost (both timewise and monetary), it would be in your interest to explore as many "ends" as there are, in hope that perhaps one of them leads outside the maze, which would be a breakthrough. Note that it would never be in your interest to introduce as many bugs in a program as you possibly can. Coming back to startups, there is normally a cost associated with failure. If startups are run in a certain way, however, that cost is minimized, and then you find out that, at early stages at least, the benefits of exploring different directions may outweigh the risks.