Skip to main content
    Country/region select      Terms of use
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

Nathan Freeman writes in a comment:

...the usage patterns of a successful application will tend to slow it down at a rate faster than Moore's Law will accelerate it.
There is no better example of this than a person's Notes Inbox.  As time goes by, the steady addition of new mail drags performance.  In the vast majority of real world situations, the performance degradation outpaces hardware updates, whether at the client, the server, or the network.
The history of the Notes platform in many implementations is one of non-scalable departmental applications thrown on bigger and bigger hardware, in an effort to find scalability out of something that was designed on the cheap and in a hurry in the first place.
There's something far more valuable than developer time.  It's user time.  A developer who spends an extra week or an extra month making sure an app is scalable and easy to use is investing wisely.  Banking on Moore's law ... is just a fool's errand.

A heavy burden of documentsIt's certainly worth discussing, and opinions can differ.

What I'm objecting to is a preoccupation with performance at the expense of developer productivity. I want efforts at maximizing performance targeted where they will do the most good -- i.e. where they will save end users lots of time. There's a definite trade-off of developer time versus user time, but it's not an even trade-off, even if you take any disparity in salaries into account. If you tie up a developer for weeks and months getting every last bit of performance out of an application, there's an opportunity cost. They're not working on other applications that could boost the productivity of other users.

What's more important -- getting it so 500 users can open a document in 1 second rather than 1.5, or fixing it so 500 users can collaborate to do a task in one day that used to take them five? The answer may not always be the same, because it depends how often the latter task needs to be done and whether the first group of users includes the president of the company, but I hope you see my point. Even aside from considerations of employee productivity, the new task may have business value (turning around their customers' requests faster) which also weighs in.

I agree that applications tend to get much slower as more documents are added, especially if they are poorly designed. It makes sense to think about performance and for developers to build habits that tend to give better performance, such as:

  • Avoid GetNthDocument.
  • Use keyword formulas that avoid doing a lookup in read mode.
  • Use Computed for Display fields rather than Computed if you don't really need the value stored.
These are things you can do as you go along without having to think much about it, especially if you use the Paste Information app or something like it to have your best-of-breed formulas and code snippets immediately to hand.

Any big deployment should have performance goals and test whether they are met, using a realistically large number of test documents. But as Nathan points out, the development path of many Notes apps doesn't follow a formal IT process; someone buys a copy of "Notes Development for Dummies" and cobbles something together, and it works fairly well for their department for a while before an accumulation of documents drags it down, down, into the ground.

It might be useless to argue about what a novice developer should do around performance, because they're not going to do it anyway. But consider this: many applications never get off the ground. Someone creates one he thinks'll be useful, but he hasn't really understood the work task, or the user interface he designed stinks, or people are unwilling to use it for some other reason. If he had put a week or a month into maximizing performance, that would be a week or a month wasted. Performance is never the problem for initial acceptance, unless it's a mass import of data from somewhere to start, and in that case the problem is obvious immediately.

Fortunately, Notes designs are malleable; once it's clear that an application is going to be useful, then is a good time to get IT support for formal performance testing and adjustments as necessary. That's when you know your developers' time is well spent working on performance. And of course, it means that good analysis tools are essential. Because the application wasn't created by someone with good habits, there's a need for a quick way to zip through it and find obvious problem areas -- such as the little list above. Fortunately, there are some excellent tools of this sort available from business partners (I suspect I shouldn't name names here).

And of course, an application doesn't necessarily get slower over time -- only if you let the documents accumulate. Adding archiving to a slow application can often rescue it from the doldrums, and that's relatively simple to do.

Andre Guirard | 9 May 2007 01:07:00 AM ET | Café Porch, Plymouth, MN, USA | Comments (3)

Search this blog 


    About IBM Privacy Contact