We talk with Tim about his current projects, aspects of continuous delivery in the mobile app context and creating community-focused software.
You’re currently working as Director of Engineering at Resolve to Save Lives and leading on the development of the Simple mobile app. Please let us know more about this Open Source project and how does it actually save people’s lives?
Resolve to Save Lives is a global non-profit with the goal of saving 100 million lives by improving cardiovascular health. Heart disease kills more people than anything else, but it doesn’t have to be that way. We know that high blood pressure is a leading cause of heart disease, and we also know how to treat it. The key is tracking a patient’s blood pressure over time, and getting them to come back for the medications they need for the rest of their lives.
However, there are billions of people worldwide with high blood pressure. Traditional paper systems just don’t scale well, and monitoring heart health for an entire population becomes a major issue. You can’t improve what you can’t measure.
To this end, we’re building Simple, an extremely lightweight electronic health record that runs on Android devices. Simple allows nurses and doctors to easily record a patient’s contact information, blood pressure, medications, and keep this record up to date over time. This data can then be used to make sure patients receive the treatment they need and allows health officials to monitor overall population health. Simple also allows healthcare workers to quickly contact patients and encourage them to return for follow up blood pressure measurement, a critical step in treating hypertension.
Your product is currently at an early demo stage. What were the most crucial things you had to focus on before shipping the currently-available version in terms of code delivery and deployment?
We now have nearly 100,000 patients registered and we’re operating in 2 states in India. Our goal is to grow orders of magnitude larger, along with launching Simple in other countries.
That said, getting to this point required a laser focus on keeping the app simple, fast, and easy to understand. This doesn’t happen without also focusing on user research, prototyping, and spending time in the field. Good software does not come from sitting in an office; you need to talk to and truly understand your users and their environment.
In our case, nurses and doctors barely have enough time to talk to patients, let alone using an app. Simple needed to be respectful of the fact that patient care always comes before software and data, and even our demo needed to be relatively polished. However, we also wanted to get Simple into peoples’ hands and learn quickly. This lead to optimizing our deployment process very early on, so we could maintain quality but have short release cycles.
We chose to build an offline-first Android app, allowing nearly every user interaction to happen locally, with a Rails backend for syncing data when network is available. This choice leads to making sure we have a solid working relationship between our mobile app and backend teams, and of course, requires a good foundation of automated unit and integration testing.
We also have to pay close attention to allowing time for manual QA cycles. It’s really easy to make changes that seem right, but break under scrutiny.
Why have you chosen using Semaphore for the Ruby part of your application?
I used Semaphore at a previous employer with multiple production Rails apps, and I was always pleased with how easy it was to set up. I also love CI solutions that seem to really understand the software platform and provide insights that let you debug quickly. Semaphore does all of that for Rails apps really well.
It’s also really easy to understand as a customer. There’s no complicated pricing schemes or calculators to figure out my bill. Setting up automated deployments is trivial. Sharing secrets and setting up test environments is intuitive. What’s not to like?
What do you think are the common pitfalls of doing continuous deployment with mobile apps?
There are obvious challenges, such as app store reviews and longer release cycles than web apps. However, we’ve found that the most frustrating part of CI for mobile apps is testing our app across the wide array of Android devices and OS versions. Our customers have a very diverse set of hardware, and our app can’t be too picky about what to support. Whatever CI solution we use has to give us some confidence that our app won’t break in the field.
How much are you able to automate with continuous delivery of mobile apps (bearing in mind that you have to run tests on an emulator/simulator or a physical device and deploy to production which often means meeting the requirements of Apple and Google virtual storefronts)?
We’ve done quite a bit of automation on full integration tests, where our mobile app hits the backend APIs end to end. This has been critical, as our sync APIs can be a bit tricky and break in unusual ways. However, continuous delivery of mobile apps has a long way to go. Web app developers have it so easy.
While we mention Google – you’re an ex-Googler yourself, you’ve also worked at AOL. There has been a shift in your approach towards work – you’ve initiated and worked for more community-focused software endeavors (General Assembly, Umba and now RTSL). What drives you to focus your efforts on creating software that influences people’s lives and supports communities?
In short, I love people.
When I first learned to program, of course, I was excited about making a computer do stuff. That eventually transformed into a deep curiosity about how systems worked, leading to my career at Google working on massive infrastructure and site reliability. I came to love building insanely huge, ambitious projects, but it always felt too abstract in some way. As I matured as an engineer, I realized that I need to build software that solves human problems.
Startups are interesting in that you can have much more individual impact. Not only can you build more of the product, but you can transform the culture of the company and the way it treats its customers. In my experience, you also form much closer bonds with your team and, in good companies, focus on creating value. My shift towards community-focused software is just a long arc in that direction. I’ve reached a point where I’m not that interested in technical problems; I’m interested in hard problems that tangibly make lives better. I want to make software that’s built with empathy and tries to celebrate and lift humanity in some way.
There has been a lot said and written lately about “the ethical responsibility of the software engineer”. You have over 20 years of experience as a full-stack engineer, product manager, and entrepreneur. Can you share your perspective on this topic with us? Has it been neglected for too many years or is it just a fad?
I think philosophy and critical thinking is far too underappreciated in society in general, and the software industry is a reflection of that. It’s often said that our industry is still so nascent that it’s no surprise we’re still figuring things out. I think that’s wrong. Humans have been thinking about these patterns of problems for a long time, and it’s a cop-out to think that programming being a new industry means you can skip ethics.
Ultimately, I think it’s vital for programmers, designers, everyone to take time to consider their core values. It’s a difficult exercise, but a worthy one. If you know what you celebrate as virtues, you tend to try and create products that align with them.
Are there any Open Source or software community initiatives that you’re especially excited about these days?
I’m not as involved in the Open Source community as I used to be, so my answer may be kind of dated. However, I still think Let’s Encrypt is doing amazing work. GitBook is one of my favorite new products, and I’ve just recently switched back to using Firefox. Of course, where would I be without Rails for the last 10 years I’ve been using it. The Ruby and Rails communities are the reasons I chose that platform to begin with, and that hasn’t changed at all.