Hawk Hill is one of my favorite places. When you sit there, you see the sea on one side and the bay on the other. You can clearly see the change of pattern in the water between the two sides. The bay shows the calm waters while the sea is full of waves. This view is awesome as it shows the two bodies of water at the same place (of course, the majestic view of the Golden Gate is present as well).
I was in a similar situation some time ago when our team was developing functionality for appointment scheduling for a popular retail chain.
On the one hand, we had their website written with traditional architecture and practices. And on the other, we created an application for appointment scheduling with our low-code platform. The comparison of traditional and modern RAD development never looked so enlightening before.
Appointment application included:
Screenshots of a few representative pages
The solution also involved changes to the existing website including:
The solution took around 6 weeks to deliver. But it clearly presented the comparison of 2 development methodologies.
For the proposal, we created a simple prototype of appointments functionality within a day
All of the above was done using the ready-to-use RAD components. A real working prototype of the application presented good clarity. The proposal was quickly accepted by the customer with very few changes.
The appointment application functionality was implemented with great-looking multi-device UI and Google Calendar-based backend and notifications. This also included authenticating with OAuth2 and using a Google Service Account for calendar service. Ready-to-use RAD connectors were utilized to reduce the code.
The application was developed for listing/searching/filtering the appointments using reusable card layout and reusable styles. This is used by the store persons to view the schedule in a micro-app container provided by SpotCues.
This was all built using RAD and was available in three weeks. The reuse of readily available connectors, UI components, and styles generated a modern application with APIs enabled and multi-device responsive UI.
The website changes were expected to be built by the customer’s IT team. But they were already under a lot of other work related to the website. The non-availability of the IT team specifically the UI developers to make the relevant changes is not a new challenge.
Our team was tasked with the changes to minimize integration efforts on the customer side. The buttons, styling, and multi-device behavior were all supposed to be handled in a jQuery script. This was all manual work. We ended up spending a substantial amount of work on that. Three weeks were spent just on the integration efforts.
A lot of information needed to be passed to the appointment application. APIs could have been very handy in this situation. The appointment application could have requested information about locations and hours of the stores to the website API if they were available. But unfortunately, the website application was but with Java Server Faces (JSF) and no APIs were available. A lot of scraping logic needed to be built which not only increased the time but also provided a solution inferior in quality and maintainability.
The script handled code to generate styles for different devices. This was duplicated for different screen sizes to adjust the size of the dialog and other related things. The default application built with RAD if rendered as is would have served well for all devices by default.
Hand-coded script code took more than double the time in QA. Hand-written code comes with its own uncertainties and manual errors. Generated applications on the other hand had most of the reusable components well tested and ready to go.
The website was a single monolithic application. The release of the appointments functionality was completely tied to the release of the website. The release of the website itself was stuck on a lot of other issues not related to the appointment application. A Microservice-based design of the website could have helped with continuous delivery.
Working on the edge of a traditional and modern low-code rapid application clearly presented the benefits we can achieve later. Modern RAD provides a great-looking multi-device UI and autogenerated backend and connectors to slash the development and QA times. Microservices and automated delivery options enable you to release much more frequently. Of course, we will also try to automate such integrations with our RAD platform in the future based on this experience.