> Finally, there's the non-technical angle to this, particularly when organizations grow to be large and there's no longer the "we're all on the same team" etho

> Finally, there's the non-technical angle to this, particularly when organizations grow to be large and there's no longer the "we're all on the same team" ethos. Sigh This is when the tug-of-war for resources start. Be it headcount, time, money, servers or db connections in this case. > Every time something broke and people got together to talk about it in a previous life, inevitably a question would come up: could we have caught this with a test, or with testing, or some other before-it-goes-to-the-world step? Many times, the question was just rote, since the answer was frequently "yes" or similar. This is the kind of question I get all the time, after you get a multidisciplinary team debugging an issue for hours. Yes, had we spent the required man hours to look into the system architecture and actual behavior under normal conditions, possibly, and a whole other host of issues that have yet to happen. Resources are rarely allocated to look into things that are not yet (completely) breaking...