“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 facil- ity. Now, the very mention of web services provokes some developers to say, “We’re going from Windows to Windows, and the literature recom- mends .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 XML4 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.
4XML documents are much like humans—they are cute and fun to deal with when they’re small but can get really annoying as they grow bigger.
ACTIVELYEVALUATETRADE-OFFS 111
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 tortu- ous 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 dif- ferent 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 ele- gant, what are the benefits of this approach?
Maybe you could simply ask the data tier to return a dataset or col- lection 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 per- formance 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.
Report erratum
ACTIVELYEVALUATETRADE-OFFS 112
But who decides whether the performance is adequate or whether the look of the application is “dazzling” enough? The customers or stake- holders must evaluate and make this decision (see Practice 10, Let Customers Make Decisions, on page 45). If your team thinks the per- formance 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 best solution
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, con- venience, productivity, cost, and time to market. If perfor- mance is adequate, then focus on improving the other fac- tors. 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 that way from the beginning.
• Premature optimization is the root of all evil.5
• 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.
5Donald Knuth’s pithy summary of Hoare’s dictum[Knu92]
CODE ININCREMENTS 113