[sigmaml]

> but you're also replacing the engine in flight!

Could you elaborate that, using a mainstream example, please?

> Also the specs on the parts are kind of spotty. ...

Are you referring to the moving parts of the Internet itself?

> There are layers upon layers of abstraction, and no one knows all of it. No one even knows most of it. In fact, most people don't care about any of it other than a cubic centimeter of their own few layers.

This is an invented problem. Scaling a one-off to work for the masses does not require `layers upon layers of abstraction'. Most of those layers are poor engineering backed by a lot money that is thrown at hardware and code maintenance.

One of the realisations that I had over years of `fixing crises', was that increasing numbers of `start up' programmers produce write-only code. Testing and debugging them is painful and expensive, even in the medium-term. Such code bases demonstrate a clear lack of basic engineering discipline. Nonetheless, such programmers are hailed as heroes, because they managed to cobble up a nice-looking mess in a week or two. Then, enormous amounts of effort are poured into making the mess work tolerably. It also consumes phenomenal time.

`Moon landing' projects cannot countdown and blast-off with a great `UX', and then start figuring out how an inertial navigation system should work, over the next week-end.

So, yes that page that `takes so long to load' is indeed `a miracle in proportions that are indescribable'. Only, in a mostly pathetic way!

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