Audible is the top audiobook service in the world. The company, which started as an independent start-up was later acquired by Amazon. I joined Audible in 2017, after my time at Roger, and I was part of what at the time was called the "Premium Team", which put simply was the team responsible for the main Android and iOS applications.
My Work at Audible
During my 2.5 years at Audible I worked on a lot of parts of the product, from its infrastructure to several feature projects. The company had some 20-30 engineers per mobile platform, and would then split into smaller cohorts of 2 to 6 engineers to focus on a specific area of the product. These changed with some regular cadence, every 6 months or so, as shifting priorities arised and needs changed.
Library rewrite
Perhaps the biggest project I owned that I'm the proudest about is the rewrite of the entire Library of the application. By library, I mean the screen that lists the audiobooks, its adjacent functionality such as sort and filter, and everything that it powers it - that means the network calls, the persistence of audiobooks' metadata to the client-side database, parsing of the proprietary format of the audio files, etc.
The whole project started when when I and another senior Android engineer got pulled into a vertical team composed of people from different technical background, and whose main task was to design and develop the new REST API for Library endpoints. As mobile engineers we helped define the unique needs of the mobile applications. My initial ask was to advice on the new API design, and to lead the effort of redesigning the network layer for the library components on the mobile client side. Knowing the state of the app, we've started prototyping and investigating the viability of a bigger redesign, and finally proposed a rewrite of this whole Library component client-side to product and management. To understand the motivations, a little context is needed. The library was of particular complexity and had been a problematic component to maintain for quite some time. Everyone on the engineering side agreed that it was long overdue for a cleanup, but being such a big task that no one deemed possible to tackle on their spare time, this tech debt just kept on growing. It was naturally the oldest component of the application, and when you take into account that Audible has been on iOS and Android for as long as Android and iOS have existed, and that this code had never been refactored or rewritten throughout the years you can begin to expect some degree of code smell. More concretely, the codebase consisted on a myriad of god classes that contained at times 10k or more lines of code per java class. There were just a handful of model objects that were meant to represent up to 15 different types of audible content, which resulted in a confusing and unmaintainable codebase. As a reflection of this, the local database which powered the offline mode and served as a cache, was essentially a couple of denormalized flat tables where for any given entry there were more null fields than actual fields with information. I recall at one point prior to this rewrite, an engineer from a separate team was tasked with writing documentation about how those handful of model objects mapped to our services - it was an incredible long and intricate document with several large tables, a map as impossible to navigate as the land you're trying to walk, which to me just conveyed how much this component was in need of a deep cleansing . It was the opposite of what good software design is meant to be; tight coupled and intertwining responsibilities instead of good separation of concerns; there were no easy to understand or common sense abstractions whatsoever.
Another aspect that informed the suggestion for a full-rewrite of this component came from a fortunate concurrent track I'd been pulled into. Almost parallel to this work, I had been pulled into sizing the effort of a UI rewrite for the Library for the coming quarter, and I got to see firsthand the new features that were being considered. The combination of these things added to the conviction that this was the right time to finally address this issue. If we did the rewrite we would save several sprints worth of work when attempting to develop new features that would follow it, since by then we'll have a modern and cleaner architecture, and a codebase that is easy to understand, add-upon and maintain. Plus, I knew it would solve one of the biggest issues of all, that we'd be able to do it more confidently than before - up until this point changing any line on the old Library was like walking on a minefield, one which was easy to make mistakes and to make it worst one of the key areas lacking unit tests at that stage still..
The management team reviewed, and approved our suggestion for a library rewrite. Hooray!
Above, various images of what constitutes the Library component of the Audible app.
Now for the actual technical work 🧑💻. Of the several teams working in parallel on the mobile apps, every single one of them depended to some degree or another on the Library or data provided by the Library. We projected our work to last several months, for one thing the new API was being developed in parallel and wouldn't be ready in at least the next 4 months. We didn't want to make a whole new change in isolation, and then have other teams have to rewrite portions of their work, in other words sidetracking ongoing projects. So our first step was to write a set of interfaces to define a functional bridge between the existing features of the app and the library. By decoupling it in this manner, we knew we could later replace the old library internals with the new one, and the rest of the app to a large degree would transparently still work as expected. We also wrote new Value Object classes, to replace the old monolithic ones. The VO classes focused on exposing only the necessary elements a given UI component would need - a much cleaner design, with well a defined contract that intuitively exposes intent between data and UI. Once those pieces were in place, we knew we could start to replace the internals of the Library, without interfering with other teams work or velocity, or prevent play stores updates to keep rolling out with their normal cadence.
By the end of this 8-months project we finally shipped it. Customers that had big libraries saw a reduction of 8 minutes to display any item on the list, to now just under 5 seconds! The biggest win here could be attributed the introduction of pagination, parallel fetching and HTTP/2 adoption. The new library was made with reactive programming, powered by ROOM ORM database that made sense, and had clear separation of concerns by following an MVVM-like architecture. Besides countless speed improvements to the application itself, the library-bug incidence was but down by a factor of 3x. The team that owned developing a new UI feature subsequent to the new library, had previously conservatively estimated their work to take 3.5 months to completion. After I onboarded them to this new architecture, they were able to get that work done (as-in, ready to ship) in just 15 days!
Elevating the team
At the time of joining, the Audible Android codebase was, for the most part, still using a very old architecture which made development frustrating, inefficient and error-prone. Even with a dedicated QA team and brilliant engineers, bugs would often still slip into the production builds because of this very reason. The state of the app was a result of dogmatic practice of a misinterpretation on what frugality meant, and lack of ownership and initiative from engineering to change that to drive fundamental change from the ground-up. After getting acquainted with the codebase, I tried to slowly shake things up by generating interest around the things that could have a substantial positive impact. This is a role that I pursued parallel to my main competencies, not something for which I was specifically brought in to do, but rather something that in my opinion was necessary to be done; to lift the whole Android app team up, and deliver the best experience possible to the business' customers. One of my early contributions was to inform and discuss the option of adopting the Kotlin language. It was easy to get consensus around the more engineering enthusiastic crowd around this topic, after all it had been praised by several worthy companies in the industry. But this endeavor still took several months to build momentum and gain majority consensus from the distributed teams across different geographies. In the process I've got to work with all of the Android trams at Audible, several other Android teams at Amazon and other subsidiaries, as well as security and compliance teams.
Hackathons
Having fun is always part of any job in my opinion, and innovation is a big part of how you can have fun while doing your job. During my time at Audible, the position and direction of the company was to rely strongly on its catalog offering - new audiobooks were seen as a bigger driver of revenue than technical innovations; therefore the culture was very conservative about making any significant changes to the product. Internal hackathons happened about twice a year, and were a great way to explore new concepts. Several of Audible's innovations came out or were inspired by these hackathons. I always had a lot of fun on these events, they are a great showcase of the creativity of people around you. Out of the 4 events I took part off, I got 1st place on 2 of them. One results in having my idea somewhat taken into production and a few virtual badges to brag about. In a big company like Audible, I always saw this as a great opportunity to collaborate with people from other departments and across functions.
Other work
Besides those bigger and wider strokes, I alone was responsible for owning and implementing App Indexing into the Android application. A task that typically wouldn't be that demanding, if not for the fact that as a policy Amazon was strictly in favor of not relying on 3rd party libraries, even those by Google which was the case - the rationale being that user data should be preserved within the company at all costs, thus any 3rd-party dependency that could send data over the network was therefore disfavored. Given the unorthodox route, and lack of documentation on this approach, I developed this feature on a basis of reverse engineering some system components and collaborating with Google engineering for added clarity.
At times I volunteered or got pulled into audio or security related tasks, given my prior experience on the topic and my eagerness to contribute there.
Another thing I liked about my time at Audible was the chance to work on an application that a wide range of surfaces, and to be part of the company's global expansion into new markets and regions. Given the nature of Android engineering being Java, our team was also responsible for maintaining Kindle and Alexa integrations of the product. At Audible I've also worked on Car integrations (Android Auto and dedicated car-mode within the app), as well as first-class support for Fire OS, the Android fork that powers Amazon Fire Tablets and Fire TV.
