Coding without Code

One of my goals as a developer is to write as little code as possible.  That’s a bit flip, but it’s true.  I try to code in such a way that it is easy to access, re-do, or re-use code so that when requirements change or get added, the amount of work is required is minimal.

One of the requests that came up last week was to add an email reminder to a database that would send an email to anyone who had not yet submitted a particular form.  The form exists in the database, and the administrator has a view that shows whose documents are outstanding.

When we first designed databases, we knew we’d be sending emails to tell people that documents were available as well as other sorts of reminders.  My design had 3 parts:

1. a form where the administrators selected the type of reminder, entered the content of the email, and set a date and time for it to be sent;
2. an agent that checked the dates and times of these documents and sent emails as necessary;
3. A designer only form that gave a name to the reminders and told the agents where to find the list of people to whom the email should be sent;

Item #3 is what allowed me to add the requested functionality without any code.  All I had to do was create a new document from this desinger form and give it a name (for the administrator to pick from the list) and tell the agent the name of the view where the list to send to could be found and the name of the field where the email address exists.  Once I saved that document, the functionality was immediately available:  no design refresh and no new code required.

Of course, all my code doesn’t come out this way.  But it’s so nice when it does!

Formula Language vs Lotusscript

Like a lot of developers, I tend to you formula language for simple task and Lotusscript for more complicated tasks. I always figured that–at least for simple items–formula language was optimized and thus faster.

Yesterday, though, my tester commented that a particular action–a typical bulk approval–seemed to be running more slowly at one level than at the previous level. The previous level had a fair amount of logic and new field creation, so that agent was written in Lotusscript. This final approval was very simple, and so I had written an agent like the following in formula language:

FIELD AppDate:=@now;
FIELD Approver:=@name([cn];@username);
FIELD Status:=”Approved”;
select @all;

The agent ran on selected documents. Since it was slow, I quickly wrote the equivalent in lotusscript:

Option Public
Option Declare
%INCLUDE "lsconst.lss"

Sub Initialize
   Dim sess As New notessession
   Dim db As notesdatabase
   Dim dc As notesdocumentcollection
   Dim thisdoc As notesdocument
   Dim nextdoc As notesdocument
   Dim goodcount As Integer

   Set db = sess.currentdatabase
   Set dc = db.unprocesseddocuments
   Set thisdoc = dc.getfirstdocument

   If dc.count = 0 Then
      Messagebox "Please select at least 1 recommendation", MB_ICONStop + MB_OK, "Bulk Approval"
      Exit Sub
   End If

   Do Until thisDoc Is Nothing
      Set nextDoc=dc.GetNextDocument(thisDoc)
      With thisDoc
         .MCAppDate = Now
         .MCApp=sess.CommonUserName
         .status="Approved"
      End With
      goodcount=goodcount + 1
      Call thisdoc.Save(True, False)
      Set thisDoc=nextdoc
   Loop

   Messagebox goodcount & " compensation recommendations approved."  , MB_ICONInformation + MB_OK, "Bulk Submit"
End Sub

Sure enough, this simple Lotusscript agent ran much faster than the formula equivalent; my tester estimate 5x faster. The question is why? Is formula language simply not as fast as I thought? Is the overhead of the progress bar that automatically appears when users run a formula language agent so high that any optimization is overwhelmed? I’m not certain, but the performance upgrade is noticeable enough that I’m not likely to try to write even simple agents in formula language anymore.