Domino Upgrade

VersionSupport end
Upgrade to 9.x now!
(see the full Lotus lifcyle) To make your upgrade a success use the Upgrade Cheat Sheet.
Contemplating to replace Notes? You have to read this! (also available on Slideshare)


Other languages on request.


Useful Tools

Get Firefox
Use OpenDNS
The support for Windows XP has come to an end . Time to consider an alternative to move on.

About Me

I am the "IBM Collaboration & Productivity Advisor" for IBM Asia Pacific. I'm based in Singapore.
Reach out to me via:
Follow notessensei on Twitter
Amazon Store
Amazon Kindle
NotesSensei's Spreadshirt shop
profile for stwissel on Stack Exchange, a network of free, community-driven Q&A sites


So you want to be a Domino developer - revisited

It has been a long time since part 1 and a lot of things have changed since the original graphic. XPages came along, Dojo got some decent documentation and everything became social. However the the graphic hasn't changed that much:
Domino Development Skills
There's ServerSide JavaScript and XPages, which isn't hard to snap up if you had sufficient exposure to JavaScript and XML (as suggested before). For die-hard-LotusScript-Forms-Only developers the new HTML/JavaScript driven way of doing things is a big learning curve. There is a Domino Designer that looks more and more like an Eclipse plug-in (which IMHO is a good thing) and made you put SSD and RAM on the Christmas wish list. What is new (and don't tell me next year you haven't seen it coming) is the convergence in all IBM APIs towards a set of common standards. Moving forward you must make yourself familiar with them. In a future version of Notes they will become the API of choice for exceptional work experiences (I shamelessly borrow a term from IBM marketing here). Since you are already familiar with XML, HTTP and JSON, these APIs are actually easy to comprehend:
  • ATOM Publishing Protocol (AtomPub): XML based format for reading and writing information with structured meta data. Properly implemented is makes heavy use of Dublin Core meta data descriptions. ATOM is behind a lot of data exchange and API including OData (the format Microsoft and SAP have committed to). There is Apache Abdera for Java, support for Atom in Dojo and even jQuery
  • OpenSocial: Framework to build applications for integrated experiences. The title might be a bit misleading, since it is much more than "add a share this" button to your page. It is a complete widget definition and interaction standard. Extends iWidgets. Both IBM Portal as well as the IBM XPages server will be both OpenSocial containers and widget contributors. Already today a Domino server cann serve a component in RCP Widget and iWidget format, so we can expect that the component model will support OpenSocial too
  • ActivityStreams: While OpenSocial defines interaction up to the UI level, ActivityStreams are the pipes feeding new information into your experience. The ver brief definition: ActivityStreams are ATOM data feeds that have at minimum the agreed set of attributes ad defined by the ActivityStreams working group. I expect ready ActivityStreams controls to first appear in the XPages Extension Library before they move to the product core control set
  • Last not least the IBM Social Business Toolkit: It brings all the above components together. The real remarkable aspect: As of today there is no shipping IBM product supporting the full API, nevertheless IBM provides a working test environment, so you can test and be prepared
From my training experience I can tell: If you grew up with web standards, developing on the XPages platform is fast and fun.


Domino Servers and Anti-Virus

QuickImage Category  
You have build your High performance Domino Server but it doesn't perform. Besides running a proper OS, you need to ensure the right anti-virus configuration. All big Anti-virus vendors have plug-ins that intercept documents before they saved into a database and checked for integrity. So you are save (as far as you can say that). However when using the scanners default configuration the NSF are scanned again when you want to access them. And this is a bad idea. Pointless and an I/O killer. So go check: Does the Virus On-Access-Scanner leave your Notes databases alone (*.NSF/*.NTF in the notes data directory)? Excluding the various tmp locations and the transaction log is also a good idea. Works wonders on performance.


Code Quality and Decomposition

I spend the past few weeks reviewing code in Lotus Notes applications. While the robustness of the platform amazed me, the code I saw didn't (short of that one form with 1932 fields and 212 @DBLookups).There seems to be a common lack of coding quality among corporate LotusScript developers. I hear "C'mon what is your problem? The code is working." I reminds me of the guy who jumped from the 88 story building stating "So far everything is fine" when falling past the 10th floor. Unfortunately very often the person who writes the code (being a contractor) doesn't have to maintain it, so bad engineering kicks in. When you write code you should make one base assumption: "The guy who will have to maintain your code is an armed maniac and has your address".Sadly the statement "It is working" neglects the most basic principle of software engineering: we don't write code for machine, we write code for humans to understand. Machines don't "understand" code, they just execute it. Enough of the rant, what needs to be done, what makes good code? In a nutshell: decomposition. Decomposition is a fancy word for breaking down tasks into smaller units until a unit solves exactly one problem. The recommended approach for this is top-down development. The Stanford Computer Engineering class uses your morning routine as example. The big task is "Morning routine" Morning routine can be broken down into: Get out of bed, morning hygiene, breakfast, get to work. These tasks can be further broken down, lets take breakfast as example (Stanford uses the morning hygiene, so you have 2 now): Prepare Breakfast, Eat Breakfast, Read Newspaper. Prepare Breakfast can be broken down to: Kiss wife, make coffee, make eggs, get juice, make toast. Make coffee can be broken down to: get water, get coffee powder, fill machine, boil coffee. Get coffee powder can be broken down into: get box with beans, fill grinder, grind, get grinded powder.And so on. Whatever programming language you use (even in COBOL) you could just write down in natural language what you do and then implement the sub routine:
Sub Breakfast PrepareBreakfast EatBreakfast ReadNewsPaper End Sub Sub PrepareBreakfast Do until sheIsSmiling sheIsSmiling = KissWife End Do MakeCoffee 2 MakeEggs 4 MakeToast 2 End Sub
This LotusScript was converted to HTML using the ls2html routine,provided by Julian Robichaux at
There are a number of tips (lifted from the Stanford lesson without asking) around decomposition:
  • Break your program down until a routine solves just one problem. That one problem: HaveBreakfast then gets broken down into smaller tasks. This is a subject of heated discussion, when you reached that one problem. But you can for sure tell, that acquiring a collection of documents, looping through them and manipulate one document at a time are 3 problems.
  • Methods are short. In the Stanford lecture a number between 1 and 15 lines was stated. I would say: a method (function, subroutine) needs to be readable on screen without scrolling (so your methods get shorter when you develop on a netbook)
  • Methods have good names. If you read your program out aloud it should tell the story. function1 function2 doesn't cut it. The computer doesn't care, but keep in mind you write your code for other people to read and understand. (OK, nothing beats this COBOL statement: PERFORM makeMoney UNTIL rich [Fullstop])
  • Methods have comments. What does the routine do? Any special considerations. What are the pre- or post- conditions. For LotusScript use LSDOC to generate documentation out of the comments.
  • Decomposition is valid for procedural, functional and object oriented programming.
You want to know more? Take the free course and read books about OO Design and Software Engineering or complete and beautiful code.


Beef up your programming skills - Take a Stanford course - free

After a number of years in the field we all think of ourselfs as "seasoned developers". A lot of us (like me) came from other professions into IT. I studied economics during national service (where I had to learn COBOL), went to law school and hold a certification as counsellor. I also went through IBM training in their internship program in the 1980ties (COBOL again, but also hardware, mainframe, midrange, PC and 1-2-3). Despite all experience it makes a lot of sense to connect back to the roots. After all computer science is a university subject. Tim Tripcony thinks so too. He notifies us that Stanford Engineering Everywhere offers a free course in Programming Methodology. You now can get Stanford Quality education from the comfort of your home, hotel room, plane seat. The download of lectures and materials is a whooping 20GB (I downloaded the MP4 version) in 28 lessons taught by Mehran Sahami. You start by downloading the course material and then the videos for the individual lectures. Being a good net-citizen you use Bittorrent for that. Ubuntu comes pre-loaded with Transmission as Bittorrent client -or- for any platform you can use Vuze/Azureus (a Eclipse RCP application) or make your pick from a long list.


Estimating Notes projects

QuickImage Category    
Estimating software project cost and duration seems to have parallels with the local weather reports: You simply can't rely on them. Waterfall project approaches are partly to blame. Estimating the amount of work units for a requirement is another. How much work is "The system needs to be user friendly"? For the sake of this post lets us presume your have a magic box, typically labeled experience, either explicit or implicit, that gives you an insight how much code you need. Once you know how much code (a.k.a. LOC or "lines of code") you need to write, estimation becomes manageable. A good tool to estimate is COCOMOII. With the LOC, COCOMOII and your average hourly cost you can estimate the cost easily (Thanks Mitch).
However using a visual development environment (Visual Studio, Eclipse, Adobe Studio, Domino Designer) makes things a little more complicated. A form or a view you draw is not a line of code. The UML model you paint (that will turn into a database schema and code classed via generation) is not a line of code. So you need to expand your mental estimation model slightly. There are two new terms to get familiar with:
  • LOC_TE = "Lines of Code - Time Equivalent": The time for painting one form is equivalent to writing how many lines of code?
  • LOC_AL = "Lines of Code - Avoided Lines": When you paint one form how many lines of code can you avoid to write? The whole promise of any visual environment is, that LOC_AL > LOC_TE. This probably varies from platform to platform and makes an excellent subject for a bar brawl between competing developer camps. I guess you won't find much information about that ratio since nobody ourdays would afford to build a system twice.
Where does that leave you for Notes or Domino estimations? You need to find your magic number for LOC_TE for the various design elements (see graphic below) and then apply the COCOMOII estimation. Of course you could simply use time estimates (by revisiting your past projects), then however you need to calculate your own project variance based on project complexity and team experience. Neglecting experience and complexity are the great fallacies happily endulged in by project planners with too little experience in software project estimations. The difference for a similar sized project can be 500% from "very experienced team working on a low complexity project" to "unexperienced team working on a high complexity project". Even if you just consider experience you will still have to shell out more than double the money (230%), 70% more people and 40% more calendar time for an inexperienced team.
The orange boxes are most likely what you will get out of the discussion with the business users, including some of the yellow boxes. For the red ones you can directly insert lines of code. How do you estimate your projects?


Capturing Software Requirements

In an earlier post I was recommending Alistair Cockburn's book Writing Effective Use Cases (Agile Software Development Series). Now a new project on OpenNTF headed by Dave Parillo is implementing Alistair's approach outlined in the book. It is an early release for now, nevertheless deserves attention and support. Go get it.


Documenting Project Progress

Software projects are not started and completed in a single day (well except certain voting applications for certain design partners), so you need to track progress. The typical way is to estimate the amount of work, set this at 100% and have a line (or bar) chart that shows the percentage of completion over time. You all have seen those diagrams. But they suck big time. Inevitably popular methods try to live without. So while you work like a mad dog to complete a project your progress line starts looking like on from ER room that triggers the typical "We lost him". All the change requests don't get reflected in the percentage, so you don't seem to progress. But there is a better way!
Enter the Burn Chart. In a burn chart you document the "items of work left to do", so you get a line that somewhen hits the x-axis on project completion. When change happens, you simply draw a vertical line up that shows the additional amount of work. You then conveniently can project how the additional work units move the project completion date. I've been playing with Dojo gfx to visualize such a burn chart. I opted to have fat red changes and trajectory projections. With a few finishing touches (will take some days) I have a neat function that can take in a Notes view with 2 values (Units completed, Units added) and show the real time line. I can imagine quite some projects where the progress will look like Sonic the Hedgehog.
See what is really happening in your project over time?


Features and Requests (So you want to be a Domino developer - Part 1)

My little graphic drew a bit of attention. Patrick seems to be particular interested in Project Management and Prototyping (which I labeled "Software Lifecyle" and "Features & Requests"). So I start off with Features & requests. I will focus on the initial gathering of features, not on the tracking and change management (that will be covered in "Software Lifecyle" at a later point in time. We all have seen this:

Since Notes and Domino is a rapid development environment asking the right question, the right way, at the right time to the right people is essential. Changing functionality gets exponentially more expensive with the implementation progress of your project. You should so a reality check in your environment: how long does the initial feature set on a new rollout survive before it is "amended until you can't recognize it anymore" (this is a fancy expression for saying: "Thrown away and rewritten").
Depending on the time and intended scope you have different courses of action. When you think big (both time and scope) it is very smart to use a tool like ideaJam to collect features and feedback. When you are closer to the users, getting them into a room (buy them lunch) and brainstorm ideas there. Very important: talk to the actual (or future) users. Talking to the IT guys doesn't cut it. Sometimes, especially when you are an external consultant, that is hard. Nevertheless insist on it. It will bite you later on. When you only listen your project is at risk too. You need to watch what your users are doing. Collect some work artefacts. Watch out for the stickers that go with paper based processes (and all the handwritten notes on the margin), they show where processes are incomplete or broken. Users might not be comfortable being watched what they do, so reassurance and dialog are critical. If you take notes without sharing what you noted down you create suspicion and risk to alienating a potential supporter.


This site is in no way affiliated, endorsed, sanctioned, supported, nor enlightened by Lotus Software nor IBM Corporation. I may be an employee, but the opinions, theories, facts, etc. presented here are my own and are in now way given in any official capacity. In short, these are my words and this is my site, not IBM's - and don't even begin to think otherwise. (Disclaimer shamelessly plugged from Rocky Oliver)
© 2003 - 2017 Stephan H. Wissel - some rights reserved as listed here: Creative Commons License
Unless otherwise labeled by its originating author, the content found on this site is made available under the terms of an Attribution/NonCommercial/ShareAlike Creative Commons License, with the exception that no rights are granted -- since they are not mine to grant -- in any logo, graphic design, trademarks or trade names of any type. Code samples and code downloads on this site are, unless otherwise labeled, made available under an Apache 2.0 license. Other license models are available on written request and written confirmation.