In our latest React Native Leadership Forum, we heard from energy technology business OVO on their use of the framework, its challenges and potential. The discussion was led by Daniel Tinkov, Software Engineering Manager for customer excellence (CE) and responsible for mobile strategy at OVO, and Tom Sherman, a senior engineer on the CE team.
Keeping up with change
The first point of discussion was around how OVO update and resolve issues with updating.
OVO went through a particularly rough update earlier this year, so decided to focus on things they could keep an eye on:
Breaking changes are not that scary. People think they are because most companies try to stick to older, more stable versions that might not be suitable for long-term support but React Native generally has good support to the latest versions of the release.
It’s better to break a few things early than the whole app later. One of OVO’s updates took about a month to complete (9 engineers). That came because the new version introduced a lot of changes that are fundamental to how React Native works with iOS.
Look for benefits. OVO look to see what benefits the new versions offer, but ultimately update anyway. This step is more for planning how fast they can update and how many hours will need to be dedicated to completing the task.
OVO also discussed how to avoid issues while updating. Their top tips were:
Update early and often
Don’t be scared to dedicate a sprint to an update – “we usually do short, one-week sprints”
Nothing is easy – be prepared and research ahead of time
Plan for updates in advance, and always update to the latest version or patch
To streamline processes, OVO upgrades everything at once. There are usually 5-6 patches with small background changes before updating to the next major version, so by staying in touch with developer teams and understanding their roadmaps, OVO can update as soon as a new patch is released.
As a carefully regulated business, they also need to maintain the latest security standards. There are sometimes issues where the GitHub Dependabot used doesn’t know whether an update will break anything, but reports are sent to developers and individual engineers across all areas (from pipeline to deployment) are involved, enabling full in-house visibility and maintenance.
Attendee question: Is there ever a case where PMs push back because they don’t see the benefits of keeping things up to date?
As Daniel explained,
“We decided that software engineering was a huge part of our business model, and as we provide green energy on slim margins (to make it affordable) by optimising our tech stacks to provide self-serving customer services, this created a culture where engineering is prioritised.
“When people need updates, engineering sits on the table and decides whether we can afford it or not, and we have also got a dedicated ‘tech time’ each week where we only work on tech tasks, with a separate ‘tech evaluation’ sprint to go through tickets and create metrics on how much value they provide for the business.
“We then go to the internal project manager to discuss; we tell them that this provides a specific value and estimate based on A/B testing or other feedback data, before deciding what exactly we need to create the best business case.”
However, as one of our attendees noted, working with external clients is much more difficult, especially when they’re not technical and can’t see the benefit as easily.
Attendee question: How often do you release to production?
OVO deploy a Native version update every week and are currently working on deploying code pushes every day. This allows them to test every single commit as they’re released and get continuous deployment on the mobile platform, as well as detecting error spikes so the team can roll back the release if needed. Every commit to the main branch can also be deployed individually. This is underpinned by a strong test coverage, and ownership-based engineering culture.
A bold new world
What is coming in the future?
Advancements in React Native and native platforms offer potential for great reach to customers.
Until recently, Chrome OS supported Android apps (as well as Windows via a plug-in) but OVO didn’t have overall coverage. A desktop app allows for a second line of communication; web infrastructure needs to be maintained constantly whereas a native app allows you to keep some information locally easily. All of this is achievable on web but harder to do.
OVO now has a MacOS desktop app based on an iPad app to make it more convenient for people to jump between devices using the same code and improve customer experience.
They are also looking at developing native visual widgets in order to provide more data to clients.
OVO are investigating how to use app snippets to allow customers to do small tasks like their meter readings without opening the app.
Plug-ins that allow Android app support on Windows have allowed OVO to consider expanding into this area for the future.
Potential for growth?
OVO’s primary potential for growth is centred around app snippets, as a better user experience, especially through their app, is a huge driver in why people stay with the company.
Issues are inevitable
Why use React Native instead of pure Native?
Shared business logic – OVO are required to do a lot of business logic on the client side because of how the server side operates – even with middleware, the way it’s managed depends on the priorities of the team managing it. Web/app discrepancies are frustrating, but the easiest way is to use the same module and share business logic, deploying from the pipeline to different places.
Maintainability – Shared business logic means you only have to write code once which helps in this regard. Projects like Expo try to rectify this, but the experience is not there, so OVO have found it much easier to develop React components then use the same logic for web and app.
Recruitment – Hiring native engineers is difficult, and this becomes more difficult when hiring separately for Android and iOS. It's easy to upskill React engineers, but it’s difficult to hire permanent React Native engineers because due to its high value as a skillset, most experts work contractually.
To combat this issue, OVO run a robust training programme for React engineers, providing comprehensive external React Native training for anyone interested in upskilling.
Q: How have you found transitioning from Native to React Native? We have two big native apps and while we’ve started to migrate the UI, not everything’s moved over so we have a constant tug-of-war between building in Native or not.
A: We had a lot of luck in terms of transitioning to RN – before that, our apps were simple native apps with a window to the web and it was easy to get away from that and start developing from scratch. This was effective and RN was so popular that we’ve started developing internal apps through the iOS enterprise programme. This increases the internal RN community!
Q: We’ve found it hard to upskill people who are purely React or Native; how have you managed to bridge the gap?
A: We had a lot of trouble doing this. People with React Native skills are premium, and we do hire contractors if we need to, as they are great for knowledge sharing.
Q: How did you get to a one-week sprint?
A: We started with 2-week sprints but with less established projects that require fast iterations, this didn’t work. We found that shortened planning and refinement sessions and one-week sprints work well with how senior stakeholders like to receive information. Sometimes we need to break bigger tasks down so we can fit each task in one week, and once people are in this mindset and ready to show what’s been completed on Monday, it’s easier for people to focus.
Alternatively, why not browse all our current software engineering jobs?