[blasdel]

Yes.

If you can get fired for missing a deadline in non-egregious situations, you're working in the real world alright, but as a replaceable cog -- you're a typist, not a programmer.

Firing you means that they're declaring their investment in your thoughts a total loss, implying that they weren't paying you to think (or that you didn't do any of the thinking you were paid for!).

[nostrademons]

Entrepreneurs have deadlines too.

I interpreted that sentence to mean "If you don't have real-world constraints on your system, you aren't a real programmer." Which I think is true. It's easy to build the "perfect" academic system, exploring every detail until you've got things just right. Problem is, reality tends to bite you in areas that you don't expect (as in, real programmers have real performance/deadline/usability constraints), and those often aren't exposed in an academic paper.

[Retric]

I suspect most of that relates to incompetence. I rarely see unexpected performance issues bite me in the ass. Premature optimization may be the root of all evil, but having a long conversation with the back end database is FAIL.

Most Entrepreneurs are way to young to have the depth of experience to really understand what they are doing. But, they are judged on a separate scale. Twitter design is probably evolving to a reasonable design, and Facebook might be fairly elegant at this point, yet they both started as crap. These entrepreneurs had deadlines but they where not trying to send someone to the moon with the computing power of a watch. Business is about the last hack standing and not creating art, but evolution also works.

[nostrademons]

I don't think it's incompetence, at least not at the academic/professor level we're talking about. Most people who get to be professors at research universities understand the low-level details of performance quite well.

Rather, I think it's often because the details about how a system will be used aren't clear until the system is built and people actually use it. As you know, engineering involves tradeoffs. It's possible to make one operation run faster by making another slower, or it's possible to make the system easier to use by making them both slower. Academics - and startups - aren't in a position to make those tradeoffs, because they don't know how the system will be used. So they'll micro-optimize along one dimension, but it turns out that people really use the software in a completely different dimension.