Subject: RE: Thanks for comment
I’m not upset with you. I have no problem with you disagreeing with me at all. Vehemently, even.
And, ok… You did read the documentation. You just didn’t fully understand and retain it. That’s no sin. I guarantee that even after 14+ years, there are still documented features in Notes and Domino that I have read about but don’t fully understand or retain.
That’s still no reason to change the way @DbLookup works with default arguments.
You say it’s “hard to imagine” that the great majority of Notes programs would be adversely affected? Where did I say anything about the “great majority”? What I said was “a huge number”. It can still be a minority of Notes apps, yet be a huge number, because the total is bigger than huge. And maybe I was indulging in a bit of hyperbole there, and with “much slower”, too. For that, I may be, as you say, “full of crap”. I still believe, however, that I’m right.
You didn’t notice any degradation in your app? That’s nice, but I’ve personally worked on or with many apps that absolutely do degrade severely when “NoCache” is used for lookups. As Ben has said, there are plenty of documented cases. If caching weren’t important, this IBM RedBook probably wouldn’t have mentioned it http://www.redbooks.ibm.com/abstracts/sg245602.html (see page 56). And though that particular RedBook was published only 7 years ago, I’m sure that that particular point was also included in performance whitepapers that Lotus published in the mid 90’s.
Out of tens of thousands of organizations using Notes applications, can you imagine that there are five apps such out there that are used by 100,000 people per day? Can you imagine that there are fifty such apps used by 10,000 people per day? Can you imagine that there are 500 such apps that are used by 1,000 per day. Or can you imagine some other combination of similar numbers? Those are modest numbers, not huge – but I, and I’m sure many others here, can easily imagine that numbers like that are well within reason, and in fact are probably a considerable underestimate of the scope of applications that would be affected. Put all three of those numbers together, and it accounts for 1.5 million Notes users working with such apps, and that’s what?.. less than 2% of the user base.
There’s a very old adage in our business that computer time is cheaper than programmer time, and this is absolutely true. Programmer time, however is far cheaper than user time. (It had better be, or we’d all be out of jobs.) This is what the people who decided what the default behavior of @DbLookup should be had in mind. The common consensus is that those folks were pretty smart, and having met a few of them I have to agree. (Though it’s really too bad they didn’t come up with “ReCache” until Notes 6. If you do start to notice the impact of “NoCache” in any of your apps, you may want to look into the benefits of using “ReCache” to allow your apps to get the advantage of caching while still avoiding stale data in cases where you know for sure that something has changed.)
Anyhow, let’s ignore the apps – huge number, or small – that are severely impacted. Those will be fixed, or discarded. There will be cost in doing that, but let’s agree to ignore that. Let’s just look at apps that will be slightly impacted… a tiny bit slower on each operation, instead of the “much slower” that I stated. Apps where you might not easily notice the impact, although it is real.
Let’s just say that changing the default behavior of @DbLookup slowed down a modest (not huge!) number of apps enough to cost each user an average of 1 second per day. For the numbers I suggested above (five used by 100,000 people, fifty by 10,000 people, 500 by 1,000 people), that works out to 52 person-work-days (8 hour days) lost every single day, or 13,000 person-work-days lost every single year. And remember, we’re ignoring the apps that are severely impacted, and we’re considering only a modest number of apps overall, so I think think a real estimate of the lost time is considerably greateer than 13,000 person-work-days.
But let’s just go with that number, and see where it balances out. Let’s imagine that a Notes developer’s time costs not just twice, but five times the average cost of an end-user’s time. If that were the case, then to balance out those 13,000 person-work-days, it would take 1300 Notes developers losing two work days per year. If I believed that 1300 Notes/Domino developers were losing two work days every year because they didn’t understand and retain the information in the Domino documentation about the “NoCache” option, I’d have to consider agreeing with you. I just don’t believe that that’s the case. And even if it were the case, I don’t believe that changing the behavior of @DbLookup for default arguments would be the best way to fix it.
There is, by the way, a method that IBM could use to change the way @DbLookup works with default args without having any effect at all on most existing apps. They could define a new token for @DbLookup and redefine the old token to @V8DbLookup, similar to the way they’ve redefined a small number of @Functions in the past. This would still have an impact on a small number of apps – ones that dynamically generate and execute @Function code. Since Notes actually accounts for that by disabling caching when @DbLookup is used within @Evaluate, this probably only impacts a very tiny fraction of apps, but those apps will mostly tend to be the largest, most complex, and most performance-intensive apps of all the hundreds of thousands of apps out there. And, much more importantly, doing this would introduce something that we all would have to struggle with regardless of whether we have performance issues: a new and potentially very large class of apps that, because they were written and compiled with a version 9 (or above) Domino Designer, would not work on Notes 8 or below. So even this way, on the whole I think it would be a bad idea.
Now, if you still can’t imagine any of this, and you still disagree vehemently… that’s fine. If you still think I’m full of crap, and continue to do so, that’s also fine. I’m pretty confident that my reputation will survive your assessment.
