The Approach of Not Stopping for a Massive Rewrite

Problem

My company is 14 years into its mission of helping salons to grow their business. We have seen industries shift, new technologies emerge, and competitors try to copy us. We have had to rebuild our product on multiple occasions. We've been able to keep innovating and upgrading our system without letting newcomers eat our lunch by incrementally changing our product screen by screen. Here's a look at the steps we took, how they have played out- either successfully or failing, and our overall approach to rewrites.

Actions taken

Early days  -  Memento 6 We started off in 2006 by building a basic appointment screen which was connected to our SMS engine. It was built in Delphi and on-premise. As we got product market fit we focused on building out hair and beauty specific functionality. We called it Memento 6, even though it was version 1, because we wanted to be more credible to potential customers. Moving to cloud  - Memento 7 The Memento 6 application was quite problematic. We needed to rebuild and move to the cloud for many reasons:

• It was built when we were in startup mode so the quality was not up to best standards.
• The language and framework was very old and people didn't want to work on it.
• As it was on-premise, customers could lose their data if they weren't backing up their systems or if their PC crashed.
• Services like AWS were opening up opportunities for SAAS businesses to adopt cloud computing and the other industries were trending this way.
• We wanted to capture digital bookings which was  not possible with on-prem databases.
• Logging in remotely to troubleshoot and update customers databases was extremely difficult to manage and caused a lot of support overhead. Our product is relied by upon by thousands of people to do their job. Drastic changes to the visual design and information architecture would have resulted in revolt. When building the UI layer for the new cloud backend we made a very conscious effort to keep it the same. We hired a dedicated team to work on Memento 7, while putting Memento 6 in maintenance mode. That team created a cloud backend, replicating all existing functionality, creating a hosted infrastructure on AWS, and solving some distributed system challenges  - for example, what happens when an appointment changes on one GUI or on the backend. When functionality was complete for Memento 7, all new customers were by default on this product. We then built an export / import tool which would migrate customers from Memento 6 to Memento 7. Memento 7  - rework Memento 7 had two big overhauls in its time.
• A look and feel facelift  -  screen by screen initiative to modernise the product. This was because we copied the look and feel from Memento 6 to reduce the friction of change.
• An infrastructure overhaul to resolve growth pains due to the traction of the product. Phorest Web (not Memento 8) Memento 7 was written in Java Swing, a 23 year old UI toolkit for building applications which has been deprecated for many years. It's a native client that is installed on our customers' PCs. We strive to give our customers the best tools to retain clients and grow their business. As we grew past 4,000 customers we saw the release frequency and friction of upgrades was limiting the speed at which we could make changes, improvements, or experiments with the system. Swing was holding us back, it didn't enable us to deliver on our engineering endeavours, everything was custom built and that's extremely slow and expensive to deliver. Engineers became very frustrated working with the technology. Phorest Web is the future of our platform:
• We can leverage other SAAS products to improve ours.
• Use open-source libraries and frameworks.
• Adopt best in class technologies and modern software development practices.
• We can make our interface more responsive and intuitive.
• The ability to ship fixes, improvements, features, and experiments without having to push new installers. We are in the fortunate position that our backend has stood the test of time. Our past scaling work and continuous improvements have meant we don't need to do a big overhaul. Our approach Having learned from our past experience on rewrites, it's very important for our web move that we make gradual, incremental changes -  not disturbing users in one big bang. In order to achieve that goal, there have been some instrumentally important parts to our web rebuild approach. Embedded web browser We achieve this by embedding a chromium web view inside of our native Swing application. Allowing us to embed new features and panels into the swing app. We use a powerful tool called Jxbrowser to achieve this. Feature flags We leverage feature flags and their ability to allow us to quickly iterate on features, safely release features to customers, quickly preview work in progress and to allow non technical people to take responsibility for when customers see new features. Controlling the navigation Jxbrowser gives us the capability to interact with the DOM and for the DOM to interact back with Swing. So, for example, you can set some values in the web application or even get the web application to call some functionality back in the Swing app. This is extremely powerful for us because we are able to navigate from web screens back to older Swing ones, giving us a controlled experience. This approach allowed us to pick the prioritise differently, so we can solve specific problems rather than in smaller batches, ship, learn, and iterate.

Lessons learned

Common problems with scaling product There are two commons challenges we see products facing as it grows in usage and functionality.

• The quality of the system decays and engineers push for a rewrite because they can't work with it anymore.
• The frameworks age and become deprecated, unmaintained, and stagnant. Inevitably this will come up in Phorest, but my goal is to prolong that conversation for as long as possible. We'll do this with a high bar for technical standards, having a high bar for the people that join our team, a shared set of values and guiding principles of how we build product. Missionaries (not mercenaries) -  who care about their craft and the quality of the system that they build. People who value SOLID principles, scalability, and reusability. We also choose technologies that can stand the test of time — not the shiny new trend. Our web framework of choice is Ember.js. It's built for ambitious projects, has an amazing community, and designed for ambitious long-term projects. Engineers working with these types of technologies, who value best practices and have a continuous improvement mindset will be our approach to not having to build a Phorest Web 2 in a few years. Source: https://nothingventured.rocks/our-approach-to-product-rewrites-95dc82f2f2c6