Notes Dev Hall of Shame #2

The main topic for today is user-configurable data.

It is true that hard-coding data is bad. The values in various drop-down lists, etc, would ideally be populated from data that the business owners can update.

But somehow, the idea of “hard-coding is bad” got misunderstood. One former developer obviously missed the point… that the idea was to not require code changes when data changed.

So we have a database full of hundreds of configuration documents. When you put these documents into edit mode, a big red warning pops up. “Do NOT change these documents without checking with Notes Development staff — code changes will be required!!”

Ehh… what??

So I look at the code. While it is true that these documents populate drop-down lists, the agents that then process documents are full of hard-coded business logic…

“If docmuent.FieldA(0) = “Data from config doc” Then…”

So if the data changes, the agents all break. So not only does any data change require a code change, but we are actually inviting the business to break things, and doing so in a way we need to debug code instead of just updating a field.

And this is done all through the entire Notes platform. To the point that the business community here think that these kinds of configuration documents are a built-in feature of Notes, and all Notes apps will always work this way.

In an environment like this, is it any wonder that people think Notes is a hopeless platform? I have a strong suspicion that if the Notes system had been well built from the start, SharePoint would never even have been a consideration here.

Notes Dev Hall of Shame – #1

I’ll pull actual code samples for later installments of our Hall of Shame, but first I simply wanted to share a few choice items that have not only boggled our minds, but also caused endless amounts of helpdesk tickets.

1) The EmployeeID field in names.nsf

At first glance, it almost looks reasonable. They added a field to the person document, labelled “Employee ID”, called EmployeeID, and updated nightly from our HR system. All applications look to this field when they need to get user data, as it is the common data point between every platform in our enterprise.

Or is it??

As we started to get all kinds of calls that applications were breaking, we found that about 20% of the applications read this field. The other 80% read ‘EmplID’. Also in the person doc. NOT displayed in the UI. Nor was there and agent to set it.
Our old admin team set this field manually when they created new users, using agent local to their system. Only when we switched to a new admin team did the problem crop up.The new admin team was already setting the visible field, and we ended up hacking together a little agent to keep both EmployeeID fields in sync.

2) The Action bar of Doom and Despair

Let’s ignore for one second that this action bar has 125 actions, and all of them are the same code, copied and pasted with minor modifications.

Let’s even ignore that any given user only will see 2-3 of these actions, based on their role within the system, so there may have been a simpler way to do these functions.

Lets just focus on the hide-whens. The hide-whens that repeat the same DBLookup 5 times in each formula. Repeated across 125 actions. With some actions having 15-20 DBLookups, instead of the paltry 5.

Do the math — I counted 724 @DBLookups in this action bar just to determine which actions should display.

People wouldn’t even open the form. When I took this job, I was told that it takes 10 minutes to open that form, so they installed a Citrix system… because via Citrix, it is much faster. Really, is that the answer to an application coded so badly that it is unusable? To install Citrix to avoid the network bottleneck?

I rewrote all the code into a single function, wrote an agent that does all the lookups in a batch process each night, and sets your personal access in a profile document. One lookup to the profile document to know which actions to display. One set of actions with dynamic labels and a function call. I was left with 10 actions, 1 function, 1 agent, and 1 lookup. And the form now opens in 3 seconds.