I've always been impressed by the backward compatibility of Notes. Late in 2008 I re-met an old client who was still running a Notes database I had built in Notes R1 (yes, R1) some 20 years ago. His Domino server had moved up to R7 by then but the app was still chugging along storing client records and printing sales summaries. It sounded like a story for the IBM marketing machine except for the fact that he was in the process of replacing the system with a purpose-built CRM product.
Then there's the customer who wants me to paste a quick-and-dirty XPage front end onto a database he had downloaded from Open NTF. In the end I advised against that approach since it would take a couple of weeks to reverse-engineer and rebuild the undocumented lotusscript agents buried within the existing Forms.
We can also consider one Business Partner's six figure commercial software development project that was originally designed with R7 Lotusscript and is now being retrofitted with XPages to make it more appealing to new customers. I know there are some good people working on that project but maybe they can't see the forest for the trees - new clothes do not make a new man in the world of software.
So how far can you stretch the rubber-band? Sure you can take an existing DB, upgrade the ODS and whack in some XPages over the weekend but is that a good thing? Aren't we just creating the 21st Century equivalent of 1980's COBOL spaghetti code?
Maybe Microsoft does have some benefits with their 'rip and replace' approach to technology. Applications developed with their tools may be over-budget and over-schedule but at least the code is fresh.
.
Subscribe to:
Post Comments (Atom)
Posts
6 comments:
Well, I think this has to be taken on a case by case basis. Depending on the business criticality of the application, it might be worth it to reengineer it with features that were added in the subsequent Notes/Domino releases.
I have done a few overhauls and some were basically rewriting the application, others were just changing the UI. In both situations, it was all about making the application more functional for the users.
: )
http://www.joelonsoftware.com/articles/fog0000000069.html
Nuff said ;-)
@ Patrik,
I agree with Joel's comments in your link, especially the bit about...
First, there are architectural problems. The code is not factored correctly. The networking code is popping up its own dialog boxes from the middle of nowhere; this should have been handled in the UI code. These problems can be solved, one at a time, by carefully moving code, refactoring, changing interfaces. They can be done by one programmer working carefully and checking in his changes all at once, so that nobody else is disrupted. Even fairly major architectural changes can be done without throwing away the code. On the Juno project we spent several months rearchitecting at one point: just moving things around, cleaning them up, creating base classes that made sense, and creating sharp interfaces between the modules. But we did it carefully, with our existing code base, and we didn't introduce new bugs or throw away working code."
My point is that this type of serious re-architecting is exactly the sort of work that needs to be done with old Notes apps but it rarely occurs. These guys took months to clean up the app but I fear that many Notes apps will be "upgraded" to XPages over a couple of weekends by a junior UI guy who is treating the whole thing as a learning exercise prior to doing his R8.5 certification.
.
I am not sure if Joel does not live in a multi-tier architecture world with separated presentation, application processing and data management logic. Older Lotus Notes applications often have a monolithic approach that make changes a bit harder. XPages to the rescue as they offer a way to upgrade the presentation while leaving your old code 100% intact (if you want that). I do believe that sometimes a forced rewrite could improve things. But there are so many old Notes applications out there that still work but would not survive any rip & replace approach. In that case customers would probably reconsider your options and use something else. Short version. If you do rip & replace, do it often so that people get used to it. It still would be great if IBM would upgrade the old design elements. Simple server upgrade would then bring Notes applications to the 21th century.
If it ain't broke, don't fix it.
There is nothing in the Lotus Notes architecture that stops people from updating the design of older applications. However, the main criticsm of the Rip & Replace method is that often changes MUST BE MADE simply to allow the existing application to run.
Lotus Notes applications don't suffer from this problem because of the huge effort made by IBM/Lotus to maintain backward compatibility.
But even with the Rip & Replace approach, there is no guarantee that an existing application will be upgraded and reengineered to take advantage of all the latest technology and features.
I wonder if anyone has done a cost comparison of the well established history of Lotus backward compatibility vs the Rip & Replace approach of other vendors to get a true picture of the cost differences.
The downside of backward compaitibility is that older Notes applications don't always look as pretty. But the alternative is a pretty application that can easily break during each upgrade or can significantly delay a necessary system upgrade because of compatibility issues.
Post a Comment