Usability - Productivity - Business - The web - Singapore & Twins

AD111 - What's your investment in Notes Applications?

One of the items in our AD111 presentation that got a lot of attention was the CoCoMo II analysis of existing Notes applications. I'll explain what it is and how to run your own analysis:
CoCoMo stands for COnstructive  COst  MOdel, first published in 1981 by Dr. Barry Boehm of the Center for Systems and Software Engineering of the University of Southern California and later refined in version 2 (you can read all about it on their website). In a nutshell: If you know how much lines of code you need, how complex the task is and how experienced your developers as a team are, then CoCoMo II can determine how long it will take to develop a software, both in calendar as well as person month. So you will know your staffing requirements and by adding your average hourly cost the total project price. The number your get out of such an CoCoMo II analysis is easy to communicate to business users:
" Rewriting/migrating application A costs X dollars, needs Y developers and will be ready in Z month, backed by 30 years of research in software development efforts"
(then lean back and wait for the howling). When deciding about the fate of a Notes application a CoCoMo analysis can provide a much more accurate account than the 4 bucket approach certain migration tools try to sell you (bucket 1: standard IBM templates, bucket 2: lightly modified, bucket 3: highly modified, bucket 4: to be retired -- shame on you for your lack of control if bucket 4 contains a single database).
You can make a few simple assumptions: Migrating the application to a different platform will need at least the same amount of code. This is already generous since you can write fully functional applications in Notes with almost no code and you have hierarchical and solid access protection build into Notes which can be complicated to reproduce with other databases (read: needing lots of extra code). XPage enabling on the other hand will need less than half of the original lines of code. We don't have solid statistics but the effort is typically between 5-35%. The more apps you have, the less the percentage since XPages components are primed for reuse.
The big question: how to get the SLOC (source lines of code) count for a Notes application that you can then fill into the online CoCoMo II calculator? Enter DXL and DXLMagic. The process has 4 steps:
  1. Extract your database as one DXL file. You can do that using the DXLMagic GUI, the command line or the DXL Exporter wizard. To setup DXLMagic to run from the command line check this post (where you actually should/could use the Java runtime of the Notes client) and the section about DXL in the DomDoc Redbook. This is the step that takes the most time, so be patient. You only need to do that once for every database since the exported DXL doesn't get modified. I also recommend to only export local NSF/NTF to avoid network congestion
  2. Run the DocumentDesignTags task for DXLMagic. It takes as file name or a directory name as parameter. What it does: checks for its configuration file com.ibm.sg.dxlmagic.DocumentDesignTags.properties in the current directory and creates it with default settings if missing. Then parses all the tags inside the given DXL or for each DXL file in the given directory and subdirectories. For each DXL file one .metrics file gets created. In that file the number of tags found are listed as well as line of code counts for everything inside a <code> tag. The properties file helps to classify code entries (e.g. UI Code, DBCode)
  3. Run the DocumentDesignMetrics task for DXLMagic. It picks up all .metrics files in a given directory including subdirectories and creates one file that contains one row for each file found. The com.ibm.sg.dxlmagic.DocumentDesignMetrics.properties file contains the list of tags you want to see in the output file. If missing the properties file gets created with default entries
  4. Open the result from step 3 in your favorite spreadsheet and add row and column sums. The grand total is the magic number. One could argue "a form is graphically created, that isn't LoC", but counting the paragraphs and fields is a good approximation for that. Some developers argue: a field definition should have a factor > 1 since it takes more time to code a field that to do a "Create - Field" in Domino Designer. Our experience shows the approximation is pretty good. But feel free to experiment
I use the following 2 command files (actually their Linux equivalents) to do the work (presuming your Notes install is in C:\Notes, and your output goes to C:\Work)
@echo off
REM Export Utility for NSF
ECHO Exporting %1
SET CLASSPATH=.;C:\Notes\jvm\lib\ext\*;%CLASSPATH%
java -Xmx2048m com.ibm.sg.dxlmagic.DesignExporter C:\Work %1
SET OLDClassPath=

Using this command file I can export nsf/ntf easily, e.g.: exportnsf crm\customers.nsf. Once all databases are exported I run a second batch file:
@echo off
REM Document Utility for DXL
ECHO Documenting C:\Work
SET CLASSPATH=.;C:\Notes\jvm\lib\ext\*;%CLASSPATH%
java -Xmx1024m com.ibm.sg.dxlmagic.DocumentDesignTags C:\Work
java -Xmx1024m com.ibm.sg.dxlmagic.DocumentDesignMetrics C:\Work C:\Work\Report.csv
SET OLDClassPath=

This will result in the file C:\Work\Report.csv you can open in your favorite spreadsheet to add the final totals. For detail setting this up on Linux or Mac, please check the Redbook. I wonder if we should build that into Domino Designer an optionally allow to post statistics to IBM on that. As usual: YMMV

Posted by on 24 January 2012 | Comments (4) | categories: Lotusphere


  1. posted by LongLiveLotus on Thursday 26 January 2012 AD:
    Good post and one that should be extended further and quantified by IBM salespeople.
    2 points -
    a. my contacts (BP's that are both M$ & IBM houses) tell me that a good rule of thumb is double the time invested in development to convert an app to $harepoint. Go figure.
    b. we have invested 50 man years of coding effort in Domino and paid IBM hundreds of thousands in support fees and received absoultely nothing, even when asking for a little something to support the cause. ziltch. nada. nowt. Not happy.
  2. posted by Stephan H. Wissel on Thursday 26 January 2012 AD:
    @LongLiveLotus: Reach out to Ed Brill (or eMail me) and we'll find help for you.
    Interesting rule of thumb for Sharepoint (the x2)
  3. posted by Sean Burgess on Monday 30 January 2012 AD:
    I am getting an error when running it against the 8.5.4 CD2 Client. Here's the error I am getting:

    Exception in thread "Thread-17" java.util.ConcurrentModificationException
    at java.util.LinkedList$LinkIterator.next(LinkedList.java:119)
    at com.ibm.sg.dxlmagic.DesignExporter.getNsfToExport(DesignExporter.java
    at com.ibm.sg.dxlmagic.DesignExporter.run(DesignExporter.java:893)
    Empty document returned, can't inspect design
    Exception in thread "ExportThread" java.lang.NullPointerException
    at java.io.File.<init>(File.java:233)
    at com.ibm.sg.dxlmagic.DomHelper.file2Dom(DomHelper.java:299)
    at com.ibm.sg.dxlmagic.CoreUIRunnerExport.splitDatbaseIntoPieces(CoreUIR
    at com.ibm.sg.dxlmagic.CoreUIRunnerExport.run(CoreUIRunnerExport.java:79

    Hope this is something easily fixed.
  4. posted by Stephan H. Wissel on Monday 30 January 2012 AD:
    Can you open the design in designer? It looks like nothing got exported here. It looks like it is not getting the NSF you want to export. You need to have a local database and provide the path relative to the data directory. Ran nicely on my 8.5.4 CD2