Tips for Integrating Optimization Into the Development Cycle (Continued)

Point of Agreement: Unit Testing Is a Must
Even XP programmers (who like to leave all testing until the end) can generally agree that some unit testing is beneficial in the course of the cycle—gathering requirements, architecture, programming, testing and QA, production, and shipping. Otherwise, how do you really know if a component is going to behave the way you want? And how do you know how it will perform under heavy usage—say, 10,000 calls a minute?

You don't want to have to go back deep into the code to fix a little command button just because it's acting quirky. Doing something over is the last thing a developer wants to do.

Obviously, developers can't rely solely on compilers and code generators for optimizing their applications at the end of the process. They also can't depend on the latest processors to add much speed, even though they are always being improved, to run their apps at maximum efficiency. Finally, the demands for performance on differing hardware devices often requires customized optimization.

Guy Rish, an experienced .NET and Java enterprise developer based in Louisville, Kentucky, who created his own .NET runtime extension for ColdFusion called Black Knight, had three things to say about his own methodology.

"Unit test, unit test, unit test," he said. "Generally, write it first, optimize last. Most clients are interested in reliable functionality, not speed.

"For the average business application, speed is seldom really a factor, and most users would much rather have an app that doesn't blow up on them than one that is really fast and explodes," he said. "Unit testing all the time reduces bugs, and (in general) will give the developer acceptable speed. Waiting until the app is solidly written and (relatively) bug free to tweak the code in special ways will yield better results and introduce fewer bugs."