Java Enterprise Best Practices

Profile Before Customizing

From an engineering perspective, any project contains two very different types of costs: people costs and performance costs. People costs are what working on a particular piece of code implies for the development team; they’re measured in terms of features not implemented, extra testing that might be required, and (in the long term) maintenance overhead. Performance costs deal with the runtime overhead of a program; they’re measured in terms of application performance, network overhead, and machine resource utilization.

The rule of thumb for getting projects in on time is very simple: don’t write bad code. But don’t trade people costs for performance costs unless you have to.

Following this rule doesn’t guarantee that your project will finish on time. But if you willfully ignore it, I guarantee that your project won’t. Thus, whenever you’re tempted to customize a working piece of code, some variant of the following scenario should play inside your head:

You: Hmmm. Maybe I’ll customize our marshalling code. I bet I can save a bunch of network and process overhead by optimizing it.

Your Internal Product Manager: Don’t you have some business logic to write?

This applies to marshalling and demarshalling in a very straightforward way. You should always make sure you can version your marshalled objects because it’s very hard to retrofit versioning into your codebase (therefore, not doing so is bad code). And you should write unit tests because they’re immediately ...