1. The network is reliableThese are assumptions developers make when building distributed systems -- like web applications. Of course, each assumption is completely wrong.
2. Latency is zero
3. Bandwidth is infinite
4. The network is secure
5. Topology doesn't change
6. There is one administrator
7. Transport cost is zero
8. The network is homogeneous
And here's the really sad part: Developers can make these false assumptions, show excellent progress against their schedule, and deliver a system that is unreliable, slow, and impossible to administer. Software development managers often don't know about these problems until it is too late. Indeed, you could argue managers encourage wrong behavior by tracking progress on the wrong things.
But this is not a diatribe against managers. In many ways, I think managers and developers are co-conspirators. To correct these false assumptions would make it obvious that building distributed systems is wicked hard and can take a long time. In other words, we pretend problems don't exist to compress schedules.
I think this is where the Software Architect comes in. A good architect has seen it all before. He knows the pitfalls. Like James Gosling, he has the Eight Fallacies (or some other canonical rules) pinned to his door. And here's the really important part: In a healthy organization, the architect has the power to change the schedule, to give developers guidance and enough time to do it right.