I, I mean, my friend, just wrapped up an article on object stereotypes.  At the last minute I decided to use an example from a system I worked on several years ago and many employers ago.  I think it was a great illustration of a particular design concept, but it's a better example of why small design decisions can have dramatic consequences for a company.  Let's hope that everybody involved with this system has moved on onto a happier place, and is wiser for the experience.  Just to start up the old argument about the relevance of architects on a project, I think the decision I'm criticizing here would be below the purview of many architects, but yet it had some sweeping consequences.

Here we go, a little bug goes kachewww!

•  A very complicated business process is kicked off when a physical scanning device sends a socket message
• Listening to the socket and the business processing is effectively the same piece of code.  IP addresses are hard-coded into the VB6 code.
• The very complicated business process can NOT be simulated except in a testing lab that is set up with physical scanners.
• Developers cannot adequately unit test the code, so more bugs make it into testing
• The code does not exhibit separation of concerns, so it is very easy for a developer to cause regression bugs, which aren't easy to catch because...
• Developers cannot efficiently unit test the code!
• Testing is very laborious, making all projects in this codebase more expensive because of the increased time to adequately test the system.
  
• Testing is very laborious, so the testers cannot adequately run enough test scenarios to completely test the system in the allotted time, which means...
• An alarming number of bugs occur in production...
• Leading to lost productivity in the factories...
• Leading to lost revenue and decreased profitability...
  
• Leading to angriness, bad feelings, and bad morale all the way around...
• Leading to many good people leaving the division or the company...
• Leading to a general loss of ability in the I/T division
  
• Possibly contributing to the company trying very hard to move all software development overseas? -- that might not be justified, but I wonder if the offshoring plans would really be there if the I/T organization was achieving better result.
  

Oh yeah, at the time I was involved, there were not automated unit tests or deployment automation that could have made regression testing cheaper and test migrations easier and quicker.  Given better project automation, maybe the design wouldn't have been so bad.

Morale of the story?  You need to apply real design skill at the point of attack, regardless of whatever that person(s) happens to be called.  Pay attention to the little design decisions too.