27   Actively Evaluate Trade-Offs

“Performance, productivity, elegance, cost, and time to market are the most important, critical issues in software development. You have to maximize all of them.”

You may be part of a team where the manager or customer places a lot of emphasis on the appearance of your application. There are also teams where clients place much importance on performance. Within the team, you may find a lead developer or architect who emphasizes following the “right” paradigm more than anything else. Such exclusive emphasis—on anything—without regard to whether it’s essential for the success of the project is a recipe for disaster.

It is reasonable to think that performance is important, because poor performance can kill an application’s chance of success in the market. However, if your application’s performance is reasonable, should you still work on getting it faster? Probably not. Many other aspects of an application are also important. Rather than spend time eking out the last millisecond, perhaps it’s more important to bring the application to market sooner, with less development effort and at a lower cost.

For example, consider the case of a .NET Windows application that has to communicate with a remote Windows server. You can choose between using .NET remoting and web services to implement this facility. Now, the very mention of web services provokes some developers to say, “We’re going from Windows to Windows, and the literature recommends .NET remoting in this case. Besides, web services are slow, and we’ll have performance problems.” That is, indeed, the party line.

However, in this case, going the web services route was easier to develop. A quick measure of performance showed that the size of the XML^[28] was pretty small, and the time spent in creating and parsing XML was negligible compared to the time the application itself took to respond. Going the web services route not only saved time in the short run but proved to be wiser when the team was forced to switch to using a third-party service later.

Andy says:

Taking Things to Extremes

I once had a client who was a firm believer in configurability, so much so, in fact, that their application had something like 10,000 configuration variables. Adding code became tortuous because of the overhead of maintaining the configuration application and database. But they swore they needed this level of flexibility because every one of their customers had different requirements, and needed different settings.

But they had only nineteen customers and didn’t expect to grow beyond fifty. That was not a good trade-off.

Consider an application where you have to fetch data from a database and tabularize it for display. You could use an elegant object-oriented approach to get the data from the database, creating objects and returning them to the UI tier. In the UI tier, you can then fetch the data from the objects and populate your table. Other than being elegant, what are the benefits of this approach?

Maybe you could simply ask the data tier to return a dataset or collection of data and then populate the table with that data. You could avoid the overhead of object creation and destruction. If all you need is to display data, why go through the hassle of creating objects? By not doing OO by the book, you will have saved effort (and gained some performance as well). There are significant drawbacks to this approach, of course, but the point is to be aware of them, not just take the long road out of habit.

After all, the cost of development and time you take to get to market both have significant impact on the success of your application. And because computers are getting cheaper and faster every day, you can spend money on hardware to buy performance and invest the time that you save on other aspects of the application.

Of course, that is true only to a point: if your hardware needs are so great that you require a large grid of computers and a sizeable support staff to keep it running (something the size of Google, say), then the balance may tip back the other way.

But who decides whether the performance is adequate or whether the look of the application is “dazzling” enough? The customers or stakeholders must evaluate and make this decision (see ​Let Customers Make Decisions​). If your team thinks the performance can be improved or you can make something more attractive, then consult the stakeholder and let them decide where you should focus your efforts.

No one best solution fits all circumstances. You have to evaluate the problem on hand and arrive at a solution that is the most suitable. Each design is very specific to the particular problem—the better ones are found by explicitly evaluating the trade-offs.

Actively evaluate trade-offs. Consider performance, convenience, productivity, cost, and time to market. If performance is adequate, then focus on improving the other factors. Don’t complicate the design for the sake of perceived performance or elegance.

What It Feels Like

Even though you can’t have everything, it should feel like you have the important things—the features important to the customer.

Keeping Your Balance

• If you’re investing extra effort now for a perceived benefit later, make sure the investment will pay off (most of the time, it probably won’t).

• True high-performance systems are designed to be that way from the beginning.

• Premature optimization is the root of all evil.^[29]

• A solution or approach you have used in the past may—or may not—be appropriate to the current problem. Don’t automatically assume either position; check it out.