Modernization of Ortho-Team’s Reservation System, a success story

In 2017 Ortho-Team released a new version of their website, and the optics of the reservation system clashed with the new website. Something had to be done.

Ortho-Team is a leading Swiss provider of orthopaedic products. Most products are made to measure for its customer, which means every sale is linked to at least one appintment for advice and measurement. Ortho-Team had a reservation system based on its IBM Domino infrastructure. Customers can choose an appointment for the location and product they need. These appointments are dynamically calculated from the available free time of all Ortho-Team employees.

The original system was built using classic Domino Web technology and was working reliably and robustly. But the design had become old-fashioned, and crucially the reservation system was unusable on mobile phones.

Decision: keep as much of the existing system

After considering several different scenarios, we decided to stick to the classic, robust technology in the back-end and revamp the UI with a modern, reactive interface. The reasoning was that this had the lowest potential impact, and the costs would also be the lowest for the desired effect.

The User Interface Design and coding of the necessary HTML and JavaScript files were done by the talented team at e621.ch. The coding on the Domino side was done by Magerman GmbH.

We’ve shown the results in the following pictures. The transition is now seamless!

If you want to update your existing classic Domino Web applications, don’t hesitate to contact us!

Lessons learned:

  • If you have classic Domino Web applications, it’s possible and cost-effective to revamp the UI using modern, reactive Front-End technologies.
  • The biggest limitation is that we had to stick to the original workflow of consecutive sequential pages. In Classic Domino Web Development, business logic is carried out on the server by serving sequential pages, and we wanted to keep the business logic where it was. A ‘single-page’ UI was not conceivable.
  • We stumbled from time to time on technological limitations of the Domino platform, but could quickly find alternatives.
  • From the start, we set up a testing environment which was accessible to all parties involved. This proved to be very effective; we ended up finalising the end product through many small iterations.

Engage 2018 recap

Engage 2018 was the best Engage I’ve ever attended. Not only was the organisation and venue superlative, but the recent energy of the new HCL team was infectious.

IBM’s Bob Schulz delivered a soporific and uninspired Keynote speech, in sharp contradistinction to Richard Jeft’s and Andrew Manby’s energetic, and funny, presentation. Their enthusiasm was infectious.

OGS_Engage

New announcements:

HCL Nomad

Most promising was the presentation by Andrew Davis showcasing Nomad, which is a Notes Client running on an iPad. He demoed the current version, which only works online. They are working on improving the controls (dropdowns, checklists etc.) to work on a touchscreen, and that seemed to be working well. Links (doclinks, database links) are working.

The next necessary step is making Nomad work offline, which would imply implementing the replication engine, but also implementing a local full text indexing. I imagine that that will be challenging. Promising, also, is the extension of LotusScript to be able to access the mobile devices’ goodies such as cameras, location.

I can see a good use case for field service workers who need a fully offline machine, and I can also imagine this would be a very easy way to surface pure Notes Client applications to the iPad with very little cost (since the codebase must not be modified).

I’m not convinced with the attempt to make Notes applications work on the iPhone, the format is just not compatible with the existing application layouts.

Andrew_Harris_Engage

Andrew Davis showing how Node.js will be integrated into the Domino stack – architecturally elegant, methinks.

HCL Places

A surprise was Jason Gary’s prototype demonstration of ‘HCL Places’, an universal integrated chatclient/Notes Client which would run in a single application, with data storage on the Domino server. It’s one of those products that HCL can market independently. Looks promising, but probably needs a lot of work for it to fly.

HCL_Places

Notes Client:

Ram Krishnamurthy showed some of the new changes in the Notes Client. I found most of them small incremental UI changes. The Workspace is getting a makeover, and I hope that what was shown is not the latest offering – the spacing of the tiles was all wrong in my opinion.

The real improvements was the decision to merge both mac and Windows codebases for the client (presumably as a result of high mac usage within IBM) and the simultaneous release of all codebases (including Sametime, which caused much of the headaches of Domino 9.01FP10). Both these changes should improve the quality of the delivery.

As a side note, it’s interesting that both HCL Places and Nomad are integrating the ‘pure’ C++ Notes client. This reinforces my feeling that there is true beauty and robustness in the ‘small’, ‘basic’ client, and that the 2008 revamp using Eclipse RCP is just a flaky, clumsy abomination whose costs (slowness, size, difficulty to configure, architecture breaks) are not compensated by its advantages. HCL announced they would sunset unused functionalities, and that is welcome. Hogne B. Pettersen suggested to ditch the RCP implementation entirely, and I  secretly cheered.

XPages:

some small improvements announced, but I think it’s clear XPages are a dead end.

New interesting technologies and skills:

Of particular interest was Knut Herrmann and Paul Harrison’s session on Progressive Web applications, an easy way to adapt a web application so that it behaves like a native mobile app, without the hassle of passing it through the testing of an app store.

ENGAGE_2018 - 2

Also fascinating was Paul Withers’ and John Jardin’s session ‘Domino and Javascript Development Master Class’. Node.RED is definitely a technology I’d like to look in. As a tip, Paul suggested making REST Tests directly with Node.RED, and not with Postman, for instance. And Node.RED is an easy way to deliver scheduled actions.

ENGAGE_2018 - 1

People

Most enjoyable is that Engage is meeting the community. Probably because of the long history of the platform, real ties of friendship make this community special, much more than any of the other gatherings I’ve attended over the past years. There is always somebody who can help!

IBM_Champtions_Engage

IBM Champions on stage

Can HCL deliver?

That’s the crucial question. Whereas I am impressed by the new team’s vision and obvious energy, my gut feeling is that they are overambitious and risk underdelivering. Jason Gary mentioned ‘we’re just like a startup’, which made me wince since in this space, with a large legacy codebase, you don’t have the luxury of a green field. The risk I see is V10 breaking existing functionality, which would be fatal.

During questions and answers I asked Richard Jefts: ‘who was responsible for the Notes 9.01FP10 release?’, as the quality assurance on that release was sub-par. Richard took it on the chin, to his credit, assumed responsibility, and told us that a separate QA post had been created to avoid this happening again. There again, the risk here is delivering under time pressure a software product that isn’t sufficiently tested.

Thanks to the Engage Team and the sponsors

Theo Heselmans made a sterling job of organising the event, as usual, and the venue was particularly well suited. The venue was the spectacular SS Rotterdam, a permanently moored cruise ship. The sessions were in the ship, we slept and ate in the ship. Many thanks to the sponsors which makes this event possible, and free!

SS_Rotterdam

On a personal note, the gods of luck were with me and I won two the two prizes that tickled my fancy: a LEGO set from OnTime and a Raspberry Pi housed in a BBC Micro B housing from LDC Via. Awesome!

andrew_magerman_ldc

Matt White from LDC Via presenting me with their awesome giveaway – a Raspberry Pi housed in a BBC Micro B

IBM Champion!

IBM announced the nominations for IBM Champions 2017 and I’m very happy to say that I was nominated.

It’s wonderful to have this sort of recognition and suddenly being part of a group who have made huge contributions to the IBM ICS Community of the years is humbling.

I strongly suspect that my nomination is linked to my co-organising the Swiss Notes User Group, so I’d like to mention at this point my co-conspirators, without whose work SNoUG wouldn’t happen:

Diana Leuenberger, Susanne Schugg and Helmut Sproll

And also many thanks to those that have contributed behind the scenes to make SNoUG a success – I think in particular here of Paul Harrison, with his wonderful AgendaWALL and AgendaPAD, as well as the very talented LDC Via Group, who help me whenever I’m stuck.

I’d also proud of strengthening the Swiss IBM Champions group – showing that plucky little Switzerland can pack a good punch!

From 3000 milliseconds to 200 to open a page: Speed up your Notes Client applications by discovering their bottlenecks.

I had inherited a template for a database which was taking 3 seconds to open any sort of document. It soon got to be irritating, and I noticed that the little lightning bolt at the bottom left side of the Notes client was flashing wildly, so I fired up the Notes RPC Parser to try and see what was all the traffic about.

The culprit was soon found: it was a subform containing buttons whose label was dynamically computed depending on the user’s desired language. And, unfortunately, it was making an @DbLookup for every single button, and an uncached one at that. If you look at the screenshot, you’ll see that an @DbLookup generates 3 NRPC Calls, for a total of 50ms – and this was done 30 times each time a document was opened.

That, and another issue that I corrected, meant that I could massively improve the performance of the application for only about half a day’s worth of work.

screen-shot-2016-11-30-at-16-58-34

Feel free to use the tool, or if you can’t be bothered, hire me to solve your Notes Client performance issues.

P.S. I’ve just released a new version of the tool Notes RPC Parser, which you can download here:

Why do Software Developers always squawk when inheriting a foreign codebase?

The first thing that Software Engineers do when they inherit a codebase that they haven’t written is to squawk loudly.

This is terrible! That’s not the way to do it! We need to re-write this completely!

I recently had an experience when a project manager suddenly lost his developer and asked me to take over. ‘Here is the list of requirements from the customer, they’re just small changes’.

I said ‘OK, I’ll give this a look, doesn’t look too difficult‘. And then I started looking into the code, and I started grumbling more and more. There were no comments. No source control. No test code. The code I had in front of me what not working correctly, and I had no access to a codebase which was working. And within the code, there were so many times when I was thinking ‘Oh no, why would you do that? I’d really do it differently’.

So I promptly squawked. And the project manager expressed his incredulity. ‘It’s always the same with developers! They always complain of code that they haven’t written themselves!’.

So, here’s a little guide to explain why this happens.

We’re not masons.

That’s the crux. The job of building walls is well defined, and if a wall is not complete, you can hire another mason to finish the job. He’ll come to the site and the tools that he sees are familiar and he can start right where the previous person stopped. Easy.

That’s not how it works with software. There is a wide range of ways you can solve something, the wider since we basically can write your own tools. Another persons’ building site is going to be completely unfamiliar.

So here are my insights for non-developers, in the hope that you will get over the impression that we are whiners, and understand that software development is not masonry.

Software is easier to write than to read.

After about six months, even the code you have written yourself becomes more difficult to read. A good developer will be writing his code not just well enough for the machine to understand (bad developers stop at that point), but well enough for humans to understand.

This is a pretty accurate picture of what it’s like reading other people’s code from somebody else:

Software can be really badly written, and you can’t see it from outside.

This rejoins the points I was making in a previous post. Here we’re talking about maintainability, the ease with which a particular codebase can be modified.  Here are some best practices which you should insist that your developers follow:

  • One is to separate the responsibility of code into little independent boxes, which only do one specific thing. If you need to change something, there is only one place to look for. This is called modularity and follows the concept of separation of concern.
  • Another one is having Source Control. This shows all the changes that have been done on the codebase over time, including who did it, and enables us to revert code to what it was in the past (when a bug has been inserted, for instance.)
  • Automated tests make every small bit of the code run through its logic, often by trying to make it break. There is one thing that we software developers are scared of, and which happens a lot: we change a bit of code here and then notice that loads of other bits of code are no longer working. Automated tests enable you to be able to make bold changes because you immediately get feedback on whether you’ve broken something.
  • Finally, documentation really helps. And please note that I’m not talking about some separate Word Document that was once done for the client, I’m talking about comments explaining why things were done in a particular way embedded within the code.

If a software developer inherits a codebase which didn’t follow these guidelines, then that code is going to be a pain to maintain and to change. And as a developer, it’s a large source of frustration because we are in effect far slower at delivering changes than our predecessor, and our customer is not going to be impressed.

So, if you are a customer, request that these basics are followed, or else you’ve got a bad case of developer lock-in, where Bob is the only person who can maintain the code.

In conclusion:

If you are a customer and switch developers or provider for a project, you’ll have to factor in some budget and time just for the new developer to get acquainted with the project. You’ll also see that it will initially take longer to effect changes, depending on how well and maintainable the software was written in the first place.