The solution for your process problems is healthy paranoia. :D Let me first define unhealthy paranoia: that everyone else's code is untrustworthy. Thus healthy paranoia: that everyone's code is untrustworthy. :D The solution in an untrusted situation is to torture your code until it confesses what it is guilty of. For other people's code, use exception handling, and lots of it. If you can't trust anything, then exception handling is your friend. If someone tells you that a bug has been fixed, don't believe them until you've run that code yourself and verified it with your own eyes. The file system, network and databse really are out to get you. ;-) Oh, and move as much of the coding out of XML and into Java as possible, since someone else will bork up the XML, which will fail silently until you go to prod, wherein it will go rambo on the rest of your app. Lastly, the solution for waterfall is more paranoia. :D In this case, what you need to do is a bit of upfront design, specifically thinking about how to deal with the sorts of changes that you are likely to get tossed at you. Changes to the business rules, data format, that kind of thing. Particularly cute is when your design needs to support two conflicting requirements. In this scenario the keyword static is not your friend. Since the fastest way to route around this kind of goalpost moving collateral damage is usually to slap down a subclass.