6.4 Who Is the Customer?

Usually, when a Java developer talks about extension, he's referring to ways that programmers can extend his application. That's only part of the total equation, though. Building an extensible API only lets your customer adapt your solution before build time. For some applications, the most useful extension happens after deployment! Your extension strategies for different customers will be different (Table 6-2). Understanding your options will allow you to accept an acceptable risk for your investment.

Table 6-2. Extension strategies

Customer	Strategy	Pros	Cons
All	No extension	Low startup costSimplicity	Poor flexibilityExpensive extension
Developer	Subclassing	Few lines of codeShared behavior	Reduced flexibilityCode time only Can complicate designs
Developer	Interfaces	High flexibility	More lines of codeCode time only
Admin	Plug-in	Best flexibilityPost-deploy timeAllows customization	Expensive to code
Admin	Standards + configuration	Allows replacementPost-deploy time	Limits choice

Table 6-2 shows how your customer affects extension. Although I haven't said it in this chapter yet, opting for simplicity over extension is perfectly valid. If you're coding a one-off solution that will be quickly replaced or has no possibility of changing in the future, extension is not a sound investment. Scaffolding code and quick interim solutions are but two examples of this type of application.

You should also understand your end customer. If you're building a custom application that has a very short, ongoing maintenance cycle, sophisticated configuration options have limited value, especially for services that are not likely to change—such as your RDBMS or your two million-class tax rules engine.

If your customer is not under your immediate control, or your cycle time is long enough to make coding changes painful, it pays to invest in extension. If you place hooks in the right places and think the configuration strategy through, your customers will surprise you. If you need evidence, look at projects that customers have extended well. James Duncan Davidson created the core of the Ant build tool on a five-hour flight to Europe. The core extension principles still exist, and now you see many thousands of Ant tasks. Consider your customers, your application, and the problem domain. Circumstances directly affect your decisions:

• The less you control your customer's requirements, the more you must consider extension.

• Commercial products usually need better configuration options than private IT projects.

• The longer the expected lifespan of a product, the more important post-deployment flexibility is.

• The longer your lifecycle, (specifically, the longer it takes you to respond to requirements), the more you've got to invest in post-deployment extension options.