[dasil003]

I have to disagree with you. The root problem is not that people are undisciplined, but that the problem is undefined. Take the time and effort to do things in a verifiable and provable way is useless if the solution is the wrong thing. The biggest risk in a startup is to take some investment money and build something which doesn't lead to any kind of user traction or revenue stream. That is such a big risk that it's worth writing shoddy code to chase that. If and when you find a real business idea then you can rewrite the code with the knowledge of what it needs to be genuinely useful.

But if you start with the idea that you're going to write solid code on principle then you're just throwing good money after bad.

[sigmaml]

> The root problem is not that people are undisciplined, but that the problem is undefined. > If and when you find a real business idea then you can rewrite the code with the knowledge of what it needs to be genuinely useful.

I have seen several start ups - invested in a few, contracted for several more - of the nature that you describe.

With the benefit of hindsight, what is there so very laudable (thanks Jane Austen) about a culture that does not have a `real business idea', but `rushes to take some investment money and build something'? When you start without a clue of what sustainable value you can provide, most of your problems are invented problems.

Another thing while we are on this topic: it is exceedingly rarely that a start up really loses out because another beat it by a few weeks. Yet, shoddy work is encouraged or condoned in the name of the necessity to move at `Internet speed'.

The `real business idea's of most start ups offer little incremental or differentiating value. The ratio of successful start ups to the unsuccessful ones speaks volumes!

[dasil003]

> When you start without a clue of what sustainable value you can provide, most of your problems are invented problems.

What an obscene strawman.

The point isn't that you go into it without a clue what you are doing. The point is that you learn so much faster once you actually have something out there. Before that you are living in a fantasy world where many assumptions both large and small will turn out to be false.

Software development practices are not so binary. They are on a continuum from NASA-like pursuit of perfection down to hackathon throwaway code. You need to decide what is appropriate for the problem at hand and the stage of your company. If you insist there is only one acceptable standard of quality then I'll run circles around you in terms of converging on the right solutions to the right problems just by writing one off shell scripts while you are busy setting up your testing framework and assertions to prove that what you are doing is correct.