Improve your platforms early and often
If one thing’s true in the IT industry, it’s that technology is always moving forwards. This is true for things like devices we use day-to-day. Form factors continue to evolve, and processing power broadly still follows Moores Law. It’s also true for everything else — networking gets faster, operating systems are refined and reimplemented, tooling is made more efficient to use, languages evolve or run the risk of being left behind, new and improved frameworks pop up every day.
The march of technology is constant, so why shouldn’t we try to match this with the platforms and products we build?
Read on to learn a little about the humble beginnings of the Sharesies native apps, learnings from being early adopters of new technologies, and how you might grow your codebases, product and platforms alongside your understanding!
Fresh new native apps at Sharesies
At Sharesies, the Android and iOS app codebase began from scratch in September 2021. When starting a new codebase you have decisions to make around libraries, frameworks, and practices you wish to adopt. We opted to aim for simple, extensible native apps which are cohesive across platforms.
For simple, cohesive UI, the obvious choices were Jetpack Compose and SwiftUI. These technologies aren’t as battle-tested as the systems they look to replace, but are far more cohesive with one another, and therefore simpler for us to teach internally. The biggest hurdle we faced was experience.
Jetpack Compose hit its first stable release about a month prior, having progressed through various levels of public developer preview over the year before that. Most of the community was only just looking to adopt Compose in their larger-scale apps, which meant industry best practice was murky. We chose to adopt Compose anyway and figure it out as we went along. We were running the risk of having to drastically change our project as we discover gaps in our knowledge. However, we were confident enough in our team that we could keep our project in an industry-leading state over time.
The approach of starting before you know all the details and filling in the blanks as you go along has worked incredibly well for us over the past year, resulting in a highly engaged team committed to keeping the app ahead of the industry curve. We’ve found that the key to keeping our codebase innovative is to start early, and improve often!
Start early, improve often
A common principle of making changes to platforms we use is to minimise disruption. When adopting a new technology, the least disruptive strategy is usually to implement the bare minimum, work through all the edge-cases, document your suggested approach, and open it up to the world. The up-front cost of this approach can be pretty large, as you need to put in work to find and document your suggested approach. All the while, the technology you’re trying to drop in is changing beneath you, and there’s a chance you find yourself rolling out outdated tooling and guidance.
Instead, once you’re sure the thing you’re trying to roll out is valuable, why not just skip the “figuring out” bit and make it up as you go along? Instead of trying to roll out broad sweeping changes, why not take an iterative approach?
Reflect and refine
Taking an iterative approach to platform development involves a lot of the same steps as product development. Reflect as you go, and refine and refactor early.
This methodology is been coined “Refinement Code Review” by Martin Fowler. It acknowledges the fact that we learn more about the technology we’re using as we gain more experience. The most valuable and least impactful way of using our new knowledge is to apply it to our codebase as early as possible — revisiting the code we’ve written previously and refactoring it to be more performant, more idiomatic, or just serve its purpose more effectively. As you learn more about the technologies you’re using, try applying these learnings to code you’ve written in the past immediately, rather than waiting for the next big refactor.
Share insight often
In much the same vein as frequent refinement of our code, it’s easier to share this newfound knowledge with others as frequently as you can. This minimises the amount of information passing between people, easing cognitive load and allowing others to benefit from the insight you’ve gained earlier.
Figure out how your team prefers receiving technical insight. This might be done through short presentations, write ups in blog-post-y formats, or just through discussion on a pull request. Once you’ve nailed communication, opt to over-communicate, sharing insight as often as possible.
This is sounding an awful lot like agile
Well, yes! Rather than taking a waterfall approach to platform improvement, with this strategy you’re now treating your code-base as your product, and engineers in your organisation as both your customers, and your stakeholders. You can even opt to apply further agile methodologies, such as retrospectives, to inform which areas of your “product” need the most improvement.
Is this the right approach for your organisation?
This approach won’t suit all organisations, and pretty heavily relies on engineering culture, as well as the pre-work being done properly.
If trust of peers is low and enthusiasm for learning doesn’t run deep, you’ll be fighting an uphill battle to introduce new technology and share knowledge collectively. The solution for this is drumming up trust and enthusiasm, which in itself is a pretty big task.
Another thing to be wary of is how comprehensively you evaluate the new thing you’re adding to your platform. Be sure that the new technology is solving a problem, and that the value it brings outweighs the integration cost. If this technology is replacing something existing make sure it’s obvious why it’s better, to avoid a fragmented codebase and conflicting opinions.
Conclusions
At Sharesies, we started our apps with fresh new declarative UI frameworks before we knew all the ins and out, and the little tricks you learn with experience. We took the approach of starting early, improving our old code as we went along, and sharing knowledge as soon as we’d gained it. This reduced the cost of adoption for new technologies, and ultimately has lead to a high trust, highly enthusiastic team who are always looking for ways to make our platforms just a little bit better every day!
Taking an iterative approach to platform development won’t work for every organisation. However, if you can make it work in your organisation you’ll get value from new tools and techniques faster, build trust and enthusiasm with your peers, and walk alongside the march of technology.
Thanks for reading, I hope you’ve taken something away from this. This is my first step outside of the realm of Android, into engineering content in general. If you have any feedback, or would like to hear more about specific topics, please reach out!
If you want to see more, follow me on Medium. Alternatively, I’ll be cross posting to my own personal blog, and I occasionally tweet.
