The members of our team have written, architected, or directed the delivery of a lot of software in several different industries. Most of them are not proud of all of it. A good software engineer is often ashamed of code they’ve written in years past. While I experienced this myself, over time I learned to recognize this trait in other engineers as well.
Those of us who really cared about the process and craft of software engineering tended to have this problem. We were never happy with the software we wrote yesterday and sometimes this could delay what we were trying to deliver tomorrow. If you spend too much time second-guessing your less-experienced self you might lose track of the tasks ahead of you.
Years ago I had the great fortune of building the first version of Risk Watch Systems’ platform. It was the software that reminded me that what my software does, is way more important than how my software does it.
The Risk Watch Cloud platform certainly was work that fell into the pattern I mentioned above. If I were to pour over the application I would cringe at early decisions made, I’d see better patterns, want to change whole libraries, and deprecate others. This reality often makes software engineers grumpy. I learned to remind myself that this software was written under the best practices known to us at the time, it runs stable and has for many years. Most importantly, it operates in service of a good company. Thus was my truce with Risk Watch System’s applications and services. We will let them run stable, provide security patches, and do not fix a platform that isn’t broken. And then one-day they saved someone’s life.
Risk Watch Cloud is a set of services that among other things combine into a platform for ensuring the serviceability of medical devices. Generally, those devices are life-saving equipment like automated external defibrillators (AED’s), Fire Extinguishers, and various emergency response equipment. Saying it now, “life-saving devices” I’m not sure why I was so affected by the news that my software had done its job. But humans like me who are trained to talk to computers all day often fail to appreciate the ramifications of what they are doing. And then one day, they saved another person’s life.
I’ve certainly spent a lot of time in meetings debating the nuances of one software pattern over another or the soundness of a specific database engine, occasionally these architectural disagreements would delay a project, while other projects never saw the light of day. This was often a direct result of knowing that we’ve made technical decisions in the past that we disagree with now. We want to get things right the first time. But Risk Watch Systems had a small development team, building software quickly, pragmatic decisions needed to be made and focus needed to be maintained. Our job is to help people.
I’ve seen lots of start-ups fail because their engineering team doesn’t understand that a working software product is the ultimate goal. I think about my experiences writing an application that truly made a difference to someone every time I enter a board room to consult executives or jump into the copilot seat to mentor an engineer. Frequently I’m dropped in the middle of an engineering team unable to move forward, in full analysis paralysis, worried about every technological decision. So I take a deep breath, roll up my sleeves, remind myself that the goal is to deliver value to the organization I am helping, and say “Let’s go save some lives”.