Tech Revamp — Know-how
Tech Revamps are often overworked and underpaid
One shouldn’t tech revamp, unless there is a business impact or once in every 4 years.
Tech revamps often challenging as Engineering teams doesn’t get an approval and often fail to convince the leadership team on the need for doing the tech update. Leadership team feels that “tech revamp” is going to take away the team’s bandwidth and are worried about unknown unknowns.
To help the teams, who are planning for the tech revamp and how to pitch it for your leadership team to convince and how to measure after the tech revamp, I would like to share our success story at redBus that recently happened for our Mobile web
In order to go through the plan, first one should be asking the following,
1️⃣ Why tech revamp?
2️⃣ What constitutes of tech revamp?
3️⃣ How do we approach?
Business defines tech!
Here are some stats on internet on the increase in mobile share of organic search visits in the past 6 years(2013 to 2019)
It is evident from many of the stats around the internet, the Organic search on internet is moving towards mobile web and tremendous growth in terms of % share of mobile in the past 6 years (2013 to 2019). Due to the same, many of the mobile web browsers have been optimised for performance in case of low network and hardware keeping in mind, with the frontend applications capable of doing lot more things in the recent past. The technology in frontend development also evolved along with to leverage the same.
We have identified our tech stack is around ~4 years old and identified there is need for doing a tech revamp for getting the benefits of latest technologies in order to achieve,
- Responsiveness with the focus of new devices in the market,
- Performance improvement for the latest browsers,
- Seamless experience of the application across all devices.
Now comes the most important phase of convincing the organisation on your execution strategy. To explain, how we have approached here at redBus, there are 3-stages.
- Pitch 🅿️
- Execute 🏇
- Retrospect ⚖
PITCH 🅿️
This is most crucial phase where many techies fail to convince the leadership team about the need of the hour i.e. Tech Revamp. One should be prepared for the answers for the following before pitching,
- The importance of Tech Revamp,
- What are the benefits, explaining in terms of improvement in productivity or any business related?
- Plan of Action,
- Estimates along with the plan for smooth run of existing releases planned during this cycle,
- Backup plan, in case of deliveries getting delayed due to business requirements,
First, let’s convince the leadership team. Here is the pitch I have made for the same
A perfect pitch makes the deal.
Next step is, collecting feedback from cross-functional teams. To do the same, have taken slot for pitching my 3-slide presentation during one of our mashups explaining the following,
Problem Statement
Over 70% of websites are over budget, however there can be exceptions for websites like Facebook.com, Youtube.com, as the users have been trained to be on a good network for better experience. Whereas for direct revenue model businesses(B2C in particular), it is a huge risk.
Current situation
The number of critical requests and bundle sizes are huge hence there is need for optimisation and hence needed Performance improvement.
Approach
The strategy here is, Performance Budgeting with 150kb of JS files(and similarly the budget allocated for CSS, html, fonts and other static assets.)
After getting 100% approval from the teams, we could kick off the plan by creating a small dedicated team to work on(3 developers) and rest of the team(5) have followed 70–30 strategy on working on this project towards the end of the quarter(after successfully finishing their product stories).
EXECUTE 🏇
1⃣️ TECH STACK UPGRADE
The important part of this tech revamp is to upgrade the tech stack to leverage on the performance optimisations and improving the standards of coding, in terms of readability and maintainability.
For this, React + Typescript we have found more suitable as it is highly popular and widely accepted tech stack around the world. With React & Typescript’s popularity and tooling around the same, goes well for our teams’ learning curve.
Previously was on React(16.3) along with other stack includes jQuery and Backbone.js
2⃣️ LIVE ERROR TRACKING
As per CrossBrowserTesting.com, there are 2050+ Real Desktop & Mobile web browsers out there, hence the validation will happen for top browsers in each geo with coverage 90% and above. For the rest as well as for real world scenarios, need to build strong live error tracking, monitoring & observability, with the following features,
- Telemetry timeline
- Enhanced Stack trace
- APM (Application Performance Monitoring)
3⃣️ PWA REVAMP
PRPL pattern highly recommended by Google for,
- real-time users, and
- first time users has been adopted.
4⃣️ COMPONENT LIBRARY
In-house built component library using React Storybook had been huge advantage in terms of
- productivity,
- UI consistency, and
- Lesser bugs in production
5⃣️ SERVER SIDE RENDERING
Redbus Mobile web is a combination of SPA & SSR(Single Page Application & Server Side Rendering). Server Side Rendering is needed for our home page and Search page (for SEO funnel), hence achieved the same using ejs templates and react router.
During the course, we did encounter couple of challenges,
- Learning curve for the team with the new tech stack: React + Typescript, Storybook,
- Context switching for the team when they started working on new code base,
- Need to build the components in isolation for Component Library as part of Storybook,
- Optimising the previous Server Side Rendering on Search page had involved some re work,
- Third-party software like, Akamai, Gamooga, GA and GTM had been re-visited in optimising the load time, performance & security,
A bit of unlearning as well
6. Unavailability of exhaustive list of all features & geo combinations.
Here is the timeline that took for us in order to release mobile web tech revamp code base in different geo-wise(Singapore, Indonesia, Malaysia, India, Peru, and Colombia in that order)
Initial launch that planned for South East Asia (SEA), Singapore, Indonesia, and Malaysia(in that order) has been delayed for almost a month due to business demand.
Then vs Now
Here is how our input metrics have improved from 3 stages of improvement with phases like,
- Code splitting,
- Reducing the number of critical requests during initial load, and
- PRPL pattern
Couple more winnings,
- Boost in productivity — 4x,
The dimensions for measuring the improved productivity would be,
(velocity of releases for new features,
number of issues seen in the production,
time taken for fixing a production issue)
- Component library helped in faster release cycles, in terms of reducing the development efforts and reusing them efficiently across codebases for new products
- Compressed images for optimised performance & faster loading across the channels(Desktop Web, Android and iOS)
- Akamai rules optimised by creating containers for each Geo (Singapore, Malaysia etc.)
- CSP headers optimised for improved security and incorporated best practices
- Server Side Rendering & Performance optimisations gave edge over our competitors in international markets, for e.g., successfully surpassed all our competitors in SEO rankings in Malaysia.
RETROSPECT ⚖
Learning#1: Performance improvement is a marathon, not a sprint!Any application with the following behaviour tend to impact the performance metrics in real time:
- regular releases (we do 2 times in a week),
- Multiple combinations like for our case, serving for more than one geo,(total 6 geos, South East Asia, Latin America and India),
- 10+ developers contributing on daily basis.
It is very important to ensure the performance metrics intact. To achieve the same, enforced “performance budgeting” at build level (webpack)
Future Steps
With the lighthouse metrics changed and introduction of web vitals, there is more work in improving the input params.
Web vitals set to launch in May 2021, the new page experience signals combine core web vitals along with mobile-friendliness, safe-browsing, HTTPS-security.
Learning #2: Designing systems for component library - Atomic Design
Interfaces are made up of smaller components. This means we can break entire interfaces down into fundamental building blocks and work up from there. That’s the basic gist of atomic design.
With the success of storybook by collaborating across the projects, adopted “Atomic Design” approach for better reusability and performance optimisation.
The gains over Atomic Design,
- Mix and match components
- easy to create the styleguide
- quick understanding of layout
- consistent & fewer components
Accordion component developed at different places has been replaced with one single module by passing different styles for different needs.
- quicker prototyping
Learning #3: Need to build the frameworks around the processAfter the tech update, we need to ensure gate-keeping in certain places to maintain the consistency with the code changes on regular basis. To do the same, we have build the frameworks around the process to enforce. Here are couple of them which does the job.
- Heimdall
A configuration manager and version tracker for our mongo config changes in production, where one can enable/disable the features or update them in the production.
The version 2 planned with role-based access, with 3 roles
- Product, have the access to enable/disable the features in the production
- Dev, have the access to modify the config and input parameters
- Admin, super user access with control of updating the permissions
here we tried our hand with a new framework Svelte, to see what’s the buzz around? 😎
2. MR-tool
With the help of MR templates, some gate keeping for developers to follow the process, like,
entering the following details,
- Detailed description of the changes,
- relevant issue number/Jira link(s),
- Define the change (New Funnel, Funnel changes, Enhancement, config changes and Bug fixes
Benefits
- Best practices endowed by the team
- Semantic Versioning
- Documentation (features or releases wise)
Learning #4: More power to Live Error trackingElastic Stack comes with more flexibility in building the robust error tracking in the production for more error scenarios seen by the end user in real time, engaged two more ways of getting more information and less turn around for fixing the issues in production.
- Live Error tracking (flow wise)
With the advent of live error tracking using Elastic Stack and significantly reducing the number of errors in browser and node.js in the production, we are building the Error tracking for flow wise, like for e.g. Tentative booking is one flow of execution in the funnel, where we can track the complete flow end to end and find out the errors occurred during different steps.
2. Distributed tracing
Otherwise known as open tracing, helps in narrowing the issues from frontend to all the services that are involved in handling the request. Typically, the best use case for micro-service based architecture.
FINAL WORDS
To conclude, if one can strictly follow the steps Pitch 🅿️, Execute 🏇 and Retrospect ⚖ in that order, would make things easier for building the systems at scale and hassle-free in production. A successful Tech Revamps are proven to increase the productivity and business comes with it!
