Last week, crowdfunding giant Kickstarter announced its engineering team has begun to open source its Android and iOS apps. The platform revealed that it is currently focused on writing well-tested code built with parts that can be easily understood on their own and it has adopted many functional programming techniques.
“The native engineering team at Kickstarter is coming off a hectic period of development. A year-and-a-half ago, we were only two iOS engineers: Brandon and Gina, who worked on a four-year-old Objective-C codebase, the majority of which was written by Brandon in the early days of Kickstarter. We didn’t even have an Android app. One winter day, Chris, a backend engineer, expressed interest in building the Android app. He moved over to work on it full-time. Along the way, we hired Lisa, a former summer intern, to help out with Android. Brandon and Gina also jumped in and made great contributions to the project.
“In less than eight months, four engineers who had never written production Java code, let alone production Android code, shipped a 1.0. It was a grueling but rewarding experience. The final product was well-received, stable, and a great way for our backers to explore projects. One of the tools we employed from the start in our Java code was functional programming. Regardless of how difficult it was to write truly functional code in Java, we knew that if we embraced immutable data structures and pure functions to the best of our ability, we would be able to avoid a lot of complexity that creeps into applications. We were naturally led to using RxJava for wrangling UI interactions in a declarative fashion, and we came up with a simplified way of separating the pure logic from the side-effects in our code, very much in the spirit of the Functional Core, Imperative Shell.
“The result was a highly testable code base most of which could be fully understood, in isolation, with no concern for how it interacted with the rest of the system. We were quite proud of our code! But once the dust settled from releasing Kickstarter for Android 1.0, we were left with the sinking feeling that we still had this — now four-year-old — Objective-C codebase to poke back alive. Luckily, our team was quite familiar with Swift and where the community was headed. Brandon had been co-organizing the Functional Swift Conference and Gina co-hosts the Brooklyn Swift Meetup. We not only had extensive knowledge of how we could leverage Swift’s type system to better express the problems we wanted to model, but also, with our Android experience, had the knowledge of how to build an application, from ground up, in a way that allowed us to piece together functional parts with side-effects at the boundaries.”
Kickstarter then noted it then went on to rewrite its iOS app in Swift and its team applied all of the things they learned from their work on the Android app. The team was extremely excited about these developments and went to give two separate talks at the 2016 Functional Swift Conference. The crowdfunding portal also revealed:
“As a native engineering team, we often look back at functional programming as the most important tool that empowered us to work the way we do. We were a team of mixed skills, backgrounds and experience levels, and we became a team that could write understandable, well-tested code on both Android and iOS platforms. We found a common philosophical basis of development through functional programming. Most importantly, we tried not to over-identify ourselves as engineers of a specific platform, but rather look at software development as a more holistic discipline. There’s no “I” in open source software. This would not have been possible without the efforts of the entire native squad.”
In regards to future developments, Kickstarter added:
“We’re excited be working in the open and able to share the cool things we come up with more freely, and the challenges we face more honestly. There are quite a few things we look forward to in 2017, including writing our first Kotlin code in Android, exploring new ways of writing declarative views and, of course, the big Swift 3 migration.”