How *often* you click Ctrl+S can affect Lotus Notes application development
Continuing in our series of Lotus Notes secrets, we’d like to share a strange little tidbit about design element replication (this is one of the secrets that Ytria’s Eric Houvenaghel shared at his Lotusphere 2010 BoF session):
A tale of two Lotus Notes developers
Once upon a time two developers were each working on their own local replicas of the same Notes application.
One developer, we’ll call him Bob, was nervous about losing changes so he clicked Ctrl+S after every single change he made.
The other developer, who we’ll dub Henry, was a bit more laid back. He only saved his work periodically, after significant changes were made.
Now the problem:
Naturally enough, Henry and Bob would sometimes get their wires crossed and work on the same design elements at the same time. And since Designs can’t have conflicts, someone’s work would inevitably be lost after replication. But oddly, in these situations it was always Henry’s work that got lost–even if he was the last one to work on the design element in question.
But why?
Because every time Bob clicked Ctrl+S the sequence number would go up and it turns out that a higher sequence number trumps a more recent Modified date in design element replication.
Still don’t believe me?
For all you doubters out there, I performed a little experiment with scanEZ to confirm our observations (I used scanEZ because it lets you have multiple open sessions with different active IDs).
First, I did some modifications to a view being sure to save frequently, thus running up the sequence number (see the image below)…
Image A: The Ctrl+S Maniac
Next, I performed another modification on the same design element on a replica of this database using a different ID. This time I only saved once. But notice in the image below the Modified date is more recent than in the image above:
Image B: The changes are more recent but the dev saved his work only once
When I replicated, as expected, the version in Image A was the “winner”:
The “winner”
How to avoid this issue
A locking solution that prevents developers from working on the same design element is probably the simplest way to prevent this problem from occurring in your Notes shop.
Since you are picking on me, even though I am laid back, I assure you that I never work on a Domino project with more than one developer where we do not use Design Locking on the development code. Rule is, Lock what you are and might be working on. If you see an element that is locked, use Sametime to ask the other developer if they will unlock it for you.
Henry “Newbs”
Interesting… Is Design Locking built into Lotus Notes Designer or is this a bespoke util ypu are using?
Thanks for the comments fellows.
@Henry
Those are surely words to live by.
I like your idea for preemptively locking designs you think you’ll be working on and then keeping Sametime open.
-Peter