Land Ahoy Method

This is the practice of following the changelogs for new versions of your dependencies and mimicking the new features yourself before you are able to actually update the dependency.

Note: I am gifting this method and its name to the community, but if you use it anywhere, please provide a reference back to this page.

Note: This article will be easier for Cocoa developers to understand, as the examples are from the iOS world. However, the principles can be understood and applied by all software engineers.

TL;DR (For those too lazy to read)

If you can't update a dependency right away, take the time to thoroughly understand the changes in the new version. To prepare for these changes and ease the transition, implement the new functionalities yourself while still using the old version. Once you finally update the dependency, you can simply delete your custom implementation.

Example: The Result type

The Result type was announced in Swift 5. After downloading the beta version of Xcode and experimenting with this new feature, we implemented our own Result type in our app that still supported Swift 4. Later, as part of our Swift 5 migration tech debt, we deleted our custom version and adapted to the new native API at virtually zero cost.

Example: SwiftUI

SwiftUI was a revolution when it was introduced in 2019. Its philosophy shifted us from writing imperative code to declarative code. To put it simply, the UI and data are no longer on the same plane; the UI has become a direct function of the data (in truth, it always was, but now this relationship is enforced). SwiftUI has evolved significantly over the past few years; some APIs have been deprecated, and new ones have been added with each iOS release. It's now abundantly clear that SwiftUI will be an essential skill for teams wanting to develop UIs on Apple's platforms. It not only simplifies tasks that were once very difficult but also enables the creation of more functional, maintainable, and scalable code. Of course, it’s not without its problems, but I anticipate these will be ironed out, just as we've seen over the last few years.

So, how can we imitate SwiftUI within the framework of the Land Ahoy Method©? First, we need to understand the foundation of these changes. As mentioned, SwiftUI shifts the coding paradigm from imperative to declarative, forcing you into a different way of thinking. You can start by gradually applying this philosophy to your existing codebase, or at least writing new features with this declarative UI notion in mind. With this approach, you will learn by doing, understanding the direction the platform is heading, and dramatically reduce your team's future migration workload.

The Risk Factor - Combine

There is a risky side to this method. For instance, the Combine framework, which was announced at WWDC 2019 and forms the backbone of SwiftUI, did not evolve as much as expected in the following years. At subsequent WWDCs, it received minor updates or sometimes none at all. If we had assumed in 2019 that Combine was the future and prepared for migration by rewriting everything with it, it would not have been a sound investment. We realised this when Apple began solving some of the same problems that Combine addressed with another API: async/await. The async/await syntax not only handles many of the use cases of Combine but also offers additional benefits for asynchronous code development, such as improved local reasoning and type-safety.

The Combine example serves as a cautionary tale. It's crucial to be prudent and not immediately adopt every new technology a platform releases. Instead, it's wise to closely monitor how much the community, and especially the platform provider itself, is investing in the new technology. Sometimes, they even declare their long-term intentions.

Conclusion

Migration is a form of tech debt that can consume a significant amount of a team's time. In the teams I've joined, the primary motivation for migration is often the desire to use new APIs, though sometimes a critical security patch or performance improvements can be the driving factor. Whatever the motivation, to ensure a smooth transition, I recommend this method, which you can start implementing today to establish it as a best practice within your team.

---

Image taken at Fitzwilliam Museum - Cambridge