by Don Jones

Ask nearly any user in any organization, using any application, what constitutes “poor application quality” and most of them will probably answer either “bugs” or “when it runs slow.” Bugs are something most developers know how to handle, at least in theory: thorough testing of as many code paths as possible, using quality test data and test procedures.

But performance is often left until last in the development process, if it’s ever even addressed at all. That’s a shame because performance is almost always something end users point to as a sign of poor application quality.

So how can you do better?

For starters, performance should be specified in the application’s requirements. “Runs fast” is not an acceptable requirement, either; instead, tie specific benchmarks to key operations. “Telephone sales agent must be able to enter a five-item order in under 60 seconds when the customer on the phone is an existing customer.” Not every operation needs a benchmark, but the really crucial ones do; those will drive performance for the remainder of the application.

Another trick is to include performance benchmarks in your nightly build tests (you are testing builds every night, using an automated testing suite, right?). Measure the time it takes to complete those critical transactions, and if you’re not meeting the benchmark, you’ll know to start working on the problem while the software is still in development.

A great technique is to empower developers with code-level performance testing tools. These tools won’t necessarily be able to tell you if a particular end-user operation can be accomplished in a given amount of time, but they can show developers-during unit testing-which bits of code are consuming the majority of the application’s run-time. If a particular module, for example, is consuming 62% of the run-time, then that module needs some attention. All other things being equal, no one piece of code should stand out as consuming an obvious majority of the run-time.

Sometimes, fixing performance problems will involve more than just rewriting some code. In many cases, performance problems can be traced to a single line of code, such as a command to retrieve data from a database. If that one line of code is already as efficient as it can be, then any remaining performance problems lie beneath that line of code, in the components and subsystems it accesses. Are your database drivers creating a performance bottleneck? Are user interface (UI) components causing screen displays to take too long to redraw? Code-level performance tools can help drive your attention to these problems, which may not be easy to fix but at least you’ll have the opportunity to make a decision about it rather than just letting poor performance “happen” with no explanation.

About the Author

Don Jones has more than a decade of professional experience in the IT industry. He's the author of more than 30 IT books, including Windows PowerShell: TFM; VBScript, WMI, and ADSI Unleashed; Managing Windows with VBScript and WMI; and many more. He's a top-rated and in-demand speaker at conferences such as Microsoft TechEd and TechMentor, and writes the monthly Windows PowerShell column for Microsoft TechNet Magazine. Don is a multiple-year recipient of Microsoft's "Most Valuable Professional" (MVP) Award with a specialization in Windows PowerShell. Don's broad IT experience includes work in the financial, telecommunications, software, manufacturing, consulting, training, and retail industries and he's one of the rare IT professionals who can not only "cross the line" between administration and software development, but also between IT workers and IT management. Don is a co-founder of Concentrated Technologies, and serves as author and series editor for Realtime Publishers.