wissel.net

wissel.net

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

Frozen Notes Applications

While discussing AutoUser, the top tool to run functional test for your Notes Client applications, with Lucius (Smart Touchan's CEO) we compared Notes (pun intended) about the state of Notes applications. We identified a phaenomenon which Lucius labeled " frozen Notes applications" (Accenture seems to have still quite a lot of them).
A frozen Notes application isn't one that is crashing or mis-behaving. It is one, mostly at the core, supporting a critical business process with tentacles interfaces in all directions. Since it has grown over the years there are quite some layers and imprints of developer generations in it. It typically does what it should do well, but there is great reluctancy to touch it. Its interface shows signs of age and enthropy. Neither adding or altering features nor moving it to a new version is considered a risk worth taking by the IT people (I actually have seen R4.6 servers still in operation for exactly that reason). Updating this application is what Wikipedia calls Brownfield development (a term borrowed from civil engineering).
What to do in such situations? The tempation is great to just rewrite the whole thing on a platform that is more in vouge. Joel Spolsky has warned against such attempts and reports coming in of rewrites (regardless of what platform, just ask about VB to VB.NET rewrites) are not very encouraging. A step by step modernisation looks more tedious in theorie but appears to be way more robust in practice.
So what is the right course of action? Document your apps (watch this space for an upcoming feature about that) and put them into a test harness. Way back there used to be LoadRunner (not sure if it is still around) supporting Notes clients. Now there is AutoUser wich is capable of testing applications against a multitude of clients. Refactor your applications when adding new features. Lucius is musing to make AutoUser more widely available. I'm looking forward to that.

Posted by on 22 March 2010 | Comments (3) | categories: Show-N-Tell Thursday

Comments

  1. posted by Peter Presnell on Tuesday 23 March 2010 AD:
    Hi Stephan. I would suggest many applications get frozen because there is a lack of detailed information about what the application is required to do. This makes it hard (if not impossible) to test any major enhancements or a rewrite to ensure that the application continues to operate the way it is intended. The longer such applications are left this way the worse the problem becomes. If it was my call i would usually vote to rewrite the aopplication in Notes (unless there is compelling evidence of perfromance issues). Notes excels at RAD making it ideal to use prototyping as a way of developing a more modern (and supportable) application while taking a large number of turns as the company rediscovers what the application does. Only this time I would make sure it requirements are now clearly documented. And remember, old tired Notes applications (Especially mission critical ones) tarnish the reputation of the product merely by being there....
  2. posted by Eric Mack on Tuesday 23 March 2010 AD:
    Hi Stephan, good to see you ahead of the game on SNTT.

    You have mentioned AutoUser. I hope you will eventually blog more about your experience as I'm interested in the web site claims... How well does it work for you?
  3. posted by Andrew Magerman on Wednesday 24 March 2010 AD:
    This concurs with my experience - I have seen at my main customer applications which are business-critical and used by a very large amount of users (15000+) on 1300 databases using the same template. The problem is, even a small change entails a lot of necessary testing.

    Typically, the customer does not want to pay for, say, 3 days of testing for a change which will take 0.5 days of programming. So it ends up being the customers making the testing, with a resulting grumbling about quality in Notes applications.

    A similar situation I have encountered is "silo programming" which happens when an application has been updated by many different programmers/ISVs. No-one wants to touch the existing code base, so every new function comes with its own itsy bitsy script library, its own views (keywords, etc), its own agents. One ends up having monsters with hundreds of views and agents, and because one cannot really test everything manually, one gets bloated databases.

    Autouser gives us the opportunity to rethink how notes client development is done. It impressed me so much that I am a partner of Lucius (disclaimer).

    That being said, I think it makes sense only for larger/complex products, as small projects do not really need that kind of overhead.