I just skimmed through a Gamasutra article titled Game Coding Complete: Smart Design Practices (a book excerpt from an O'Reilly title) which lists a few practical tips for covering your ass codewise. Coming from the game development world, some of the practices are a bit irrelevant for the typical modern day business application developer doing J2EE but some of them hold equally well both sides of the chasm.

Avoid hidden code that performs nontrivial operations

The first practice is what I consider to be of high importance. The principle of least surprise is an important one and we should remember to keep that in mind when pounding away in our IDE's. Encapsulation is a good thing if done right but it can be misused for hiding details that the client code (or its author) really should be informed about. The obvious example is a getter method that one assumes to be a dirt-cheap operation while it's really hitting the database on every call. However, it's not about the performance -- it's about us knowing what our code is doing.

Keep your class hierarchies as flat as possible

Earlier today, a discussion passed the subject of frameworks that require one to extend a base class (examples include JUnit and Struts, among others) and how that's a smell, regardless of whether this restriction is a conscious design decision or a necessity dictated by the constraints of the technology in use. The fewer levels of inheritance in your system, the easier it is to understand--and evolve.

Be aware of the difference between inheritance and containment

Related to the previous point, it is important to realize when inheritance really is appropriate. In fact, I'd say that most of the time it's not! Aggregation has long proven to be much more flexible than inheritance. Inheritance is a good tool. It's just not for nails of all sizes.

Avoid abusing virtual functions

While virtual functions are not an issue for Java developers, the underlying theme of avoiding situations where bad things can happen is not to be dismissed lightly, either. Using the very latest features of the very latest technology or programming language might not be the best choice for the project or the company. "Right tool for the job" should not exclude the fact that there's people involved in software development, believe it or not. Thinking about your "audience" is hardly ever a bad idea...

Use interface classes and factories

'Nuff said. Abstraction is a powerful technique. Provided that we don't abuse it, that is. I've recently been subjected to a relatively big codebase on a portal project. Beyond the usual procedural-code-written-in-Java terror, I've come to realize that one of the major obstacles for getting new people up to speed quickly is that the system is missing at least one layer of abstraction between the application code and the underlying portal product's API.

Use streams in addition to constructors to initialize objects

This last one is very much game development specific so I don't have much to say about it. It makes sense, but I must say I don't quite see why McShaffry included this particular practice among the others. It's almost like he's mixing two levels of abstraction here ;)