Careful with those invokations, Vijay.
As we have seen before in previous lives, and I'm pretty sure stephen stuart will step in, normalizing "throw the ethernet over the wall" school of design just leads to an incredible amount of pain when trying to operate, run and actually document what you've got.
The various replies have largely covered what I would say; that it's all about the OA&M. Yes, in the previous life that you mention (known currently as "the good old days"), some pain was suffered. If there is a spectrum roughly described as: - have no standards or documentation (and none of the pain of developing, following, maintaining them) and spend all your time doing discovery each time you have a problem to solve (so that all of your pain results from having no operational consistency) - have standards that you don't follow and documentation that you don't maintain and constantly trip over exception cases (suffer pain on both ends of the spectrum) - have standards that are followed and documentation that is maintained and achieve a high level of operational consistency (this is widely regarded as "better") then the pain that you describe came from moving along that spectrum. The pain came from moving, not necessarily from the direction that we chose. We moved in the direction that we did because the goals that we set for ourselves demanded it. Hopefully the folks still there continue to reap the benefits of that work. Each organization chooses (whether consciously or not) a point in the spectrum described above and operates there. They compete in the marketplace without that choice being a significant differentiator; an organization that lacks design skills might compensate by being able to debug problems quickly, for example, such that externally measurable metrics that drive purchasing decisions are roughly equivalent. There is no One Truth; you try to make your organizational strengths work for you to maximum benefit, while not getting tripped up by your weaknesses. What *is* a differentiator is how well you execute at the point in the spectrum that you've chosen. That choice is made over and over again within the lifecycle of an organization. The wheel turns, and administrations come and go, moving one way or the other, using "the previous administration did X and we must do Y" as justification for desired resources to travel in either direction (or to stay in one place, with the appropriate label engineering to make it look as though motion will occur). All the while, the benefits and drawbacks of various aspects of various choices will be debated on the NANOG mailing list. There's an analogy to samsara hiding in there, for those that like analogies. I'd elaborate, but it's time to take the dogma for a walk. Stephen