“And those who were seen dancing were thought to be insane by those who could not hear the music.”‍

— Friedrich Nietzsche

‍

Changing the way software gets built isn’t just an intellectual exercise for me. It’s personal.

In 2015, after exiting my last startup, a project from one of the world’s largest healthcare systems came across my desk: an Internet of Things (IoT) medical device. At that time, I loved doing IoT projects because they were complex: there were server components, mobile components, and hardware components. I agreed to take on the project.

The call I answered was fairly typical, I was asked to pull a failing product out of a ditch. The project was six months late and almost twice the budget. But this wasn’t a typical IoT project intended to pad a corporation’s bottom line. This device was a first-of-its-kind children’s diabetes monitor that would allow for non-invasive glucose monitoring. We were developing it years before similar devices would eventually hit the market. It would allow kids to monitor their diabetes without having to constantly prick their fingers and draw blood.

The CTO kept greenlighting the overages because he knew how transformative this device would be. As a father, I imagined my own kids going through that scenario and I knew I wanted to eliminate this small bit of cruelty and trauma from those children’s lives. I agreed to help immediately.

The reason the project was off track wasn’t due to the physical glucose-reading device, which worked incredibly well and reported accurate and precise numbers. Instead, the issue lay with the mobile companion app. The team couldn’t reliably produce the app to meet the quality control guidelines for FDA approval. My task was clear. I needed to save the mobile app so the device could be approved.

In my meetings with the team, they laid bare the challenges ahead. We needed to produce software to the FDA’s exacting standards, but were trying to do so with a development process that felt like it was from the digital stone age:

• No automated builds or tests
• No merge requests
• One code branch

I could keep going, but you get the point. This was incompetence bordering on malice.

As part of my due diligence, I went to visit one of the device testing sessions. They had medical volunteers (in other words, children) coming in twice a month to test the device, get readings, and let the dev team work different configurations and test various app builds.

I’ll never forget meeting one of the kids; he was so excited about the device because it made him feel like “Iron Man.” I wanted to make every kid feel like “Iron Man.” I was going to save this project. No pressure.

As anyone who knows me can attest, it doesn’t take much to work me into a fervor. I led with my heart on my sleeve, and put everything I had into my plan to get this project back on track. We were going to cut the team in half to control costs. We were going to bring in solid developers. We were going to onshore the team leads.

My plan was 12 pages of absolute vitriol aimed at the injustice this team served the world with their incompetence and indolence. I presented this plan to the leadership and was told: “It’s a great plan but we have a contract with this firm that we can’t break. You can’t change the team.” Fine, I thought. I’ll make this happen with whatever team you put around me.

I also secured a mandate from management to do anything contractually acceptable to fix the project. Over the next few weeks, we focused on the fundamentals. We built automated tests, automated builds, builds that people could pull from shared repositories, code branches, proper framework versioning, and more. We were making progress.

Five weeks later, just as we were hitting our stride, the client’s patience ran out. In an executive meeting, I fought with everything I had to save the project. I assured the team we were finally going in the right direction. Alas, the client did not agree. The CFO canceled the initiative. I was emotionally devastated but I couldn’t really blame him. After all, the project was 2.5x over budget.

That night, I went home and took a shower. I hung my head under the water, knowing I failed at the thing I thought I was best at. I failed those who thought I could rescue their project. I failed “Iron Man.”

Since that day, I’ve refused to look away from the inherent problems in the software industry. The problems are no longer conceptual—they exact a visceral human toll. Software powers the world around us, and when it’s done poorly, it directly impacts our lives.

I tried to make a dent in these issues via consulting, advising clients on best practices with Skiplist. I explored this problem in my podcast, Thoughtful Software. At each stage of my journey, I uncovered another layer of just how deeply rooted and widespread these issues are.

This is the underlying mission of Bloomfilter and the reason I’m on this journey. I’ve seen first hand the impact that comes from shipping software poorly. And I understand the impact of helping leaders release great products efficiently and on time. This time, we are not going to fail.