There’s an old joke that goes along these lines: A fundamental law of programming is that a program’s complexity grows until it exceeds the capabilities of the programmer who must maintain it.
Although it’s a joke, there is an element of truth to this. If every program was only ever touched by a single programmer, and that person had a perfect memory and unlimited amounts of time to spend on refactoring their code, it’s unlikely that there would be any problems caused by code complexity. Of course, that’s not the way real life works.
But what makes an IBM Lotus Notes or Domino application complex? And why should we care? To answer the second question first, most of our customers who care about the complexity of their Notes applications do so because they are preparing for the future. That may mean they are planning to move away from the Notes/Domino platform, they may be migrating their application server infrastructure to the cloud, or perhaps they’re just concerned about a lack of Notes and Domino development skills in their organization.
Whatever the reason, most of the people we encounter who are interested in application complexity are seeking to build an inventory of the Notes and Domino applications in their environment, find out how much they are being used, and then get a sense of how complex they are. And that is usually with a view to either migrating to some other platform or ensuring that they have access to the right skills to be able to maintain or modernize the applications going forward. In other words, application complexity is something that most organizations should pay attention to.
So what about the first question I posed? What makes an IBM Lotus Notes/Domino application “complex”? And how to we apply a measure of complexity to our applications so that we can compare one with another?
I started my programming career in the early 80s, and back then, when we wrote pages and pages of code in long text files, we had tools such as cyclomatic complexity to tell us how complex our code was. Cyclomatic complexity measures the number of independent paths through a program. It’s fine in principle, but doesn’t translate very well to the world of IBM Notes & Domino apps, where applications are built using a heady cocktail of different languages and bits of code are hidden away in buttons, field formulas and code libraries.
How to measure complexity in a Notes app is a question that we had to address as we built Teamstudio Adviser. The Complexity module within Analyzer provides an indication of the effort that would be required to maintain or migrate a Notes/Domino application. The module combines a number of different factors such as the number of design elements of different types, the presence of certain hard-to-migrate elements and the presence of user-definable keywords to compute a complexity score. That score is then converted to a five-point complexity ranking from Very Low to Very High.
There are three main areas that are taken in to consideration when determining the complexity of a database design:
1. Common Problems
Based on our experience of building and maintaining Notes and Domino applications, we’ve defined a number of database design features which typically cause problems. These include an excessive number of fields used on a form, complex tables, the database being set to allow stored forms, a selection formula containing @IsResponseDoc, @AllChildren or @AllDescendants, as well as a number of other things.
Typically, the presence of one or more of these features implies higher complexity.
2. Design Elements
The number of each type of design element in the database design is often a good indicator of the complexity of the overall database design. In our model, a database with more than 15 agents would be a strong indicator of high complexity. A design with just a single script library would similarly receive a high score. The presence of one or more shared fields would contribute to the complexity equation, but not as strongly as a script library.
3. Search Terms
In addition to predefined common problems and design element counts, we consider that there are certain terms which, if found in the database design, are strong indicators of added complexity. Examples of these might be “ODBC”, “LDAP” or “LS2J”.
The search terms in Adviser are configurable, so it’s possible to add to the list if there are terms specific to your own environment.
In fact, all of the complexity parameters in Adviser are completely configurable. So if you disagree with our assessment of the relative impact on complexity of any of the items on the list above, you can tweak it to your heart’s content.
In summary, determining the complexity of any software application is not easy, and many people have their own opinions about the best way to do it. Our view is that the most important thing is to use the same method consistently across all the applications you are examining and that will give you at least a measure of relative complexity. That can be very helpful when it comes to determining a future path for the Notes and Domino applications in your organization.
To learn more about Teamstudio Adviser and how it can help you map your Notes and Domino application landscape, click below.