Never Lose Sight of What You Do
Today, as the result of the NTSB investigation into the fatal Uber autonomous vehicle crash that took the life of Elaine Herzberg, it was revealed that the software controlling Uber’s Volvo XC90 autonomous vehicle had a full six seconds to react to her presence, yet it did nothing. Notably, the disabled Volvo safety systems detected the woman and decided that action needed to be taken about a second and a half before the crash. What I don’t want to do is get into who is at fault or whether or not Uber or the car’s monitor is to blame, those are questions for someone else to answer; I want to spend some time on the software.
As a software engineer who works for a rather large bank its easy to forget that ultimately everything I do will impact our customers. My particular project isn’t directly public facing, nor is it open source, and my team’s customers are other developers inside the company. We tend to think in closed circles when it comes to who will consume our product and what kind of impact that has on the rest of the “food chain”, but maybe we’re wrong for limiting our thinking like that.
When I was younger and [probably] more stupid, some friends and I walked to a local brick factory to explore. We climbed on mounds of broken and discarded bricks, explored the factory building itself, and ran through the neatly stacked pallets of finished bricks waiting to be shipped out. The thing that impressed me the most was the kiln. It was massive. Spanning at least the length of a football field, the kiln stretched the entire length of the factory floor with doors and windows dotting the sides of it. It was open on either end so that motorized trollies could carry the unfinished bricks through the firing process without the intervention of any of the factory workers. Because it was open we could see down the entire length of it, its insides glowing yellow-white with the intense heat. Thinking back about it now I can see direct parallels between this factory and software development. My team are the brick-makers: we make building blocks for other people to use. Our deployment and testing pipeline is our kiln, with raw code going in one end and hardened tested code coming out the other. Our horizon ends at the shipping yard — Artifactory in our case — where other teams take what we’ve made and use it in their own products. Beyond the well-functioning of our product we don’t necessarily care what other teams are building or doing with our code, that’s not our scope, but it is still up to us to create the best product we can possibly make. Like the brick factory’s two different collections of bricks — piles of broken and discarded ones next to neatly stacked ready-to-go pallets of good bricks — we too have a responsibility for self-evaluation and self-governing over the quality of our work. Not only do we need to make sure that the products leaving our factory are good in and of themselves, but they also meet the needs and requirements of our customers, and that we give our consumers guidelines on when and how best to use our products. That is our responsibility and we take it seriously, because at the end of the day, if a bank customer losing all of their money, or being charged multiple times for a single thing, or some other mishap can be traced back to one of our lines of code, then we are ultimately at fault and bear the responsibility for that incident.
This is true not just for banking but for everything else as well. Defense, manufacturing, IoT, and even autonomous vehicles all require software and software engineers who care about where their code ends up, and be behooves us to write code as if our lives and our livelihoods depend on it. In some ways it does. Its a circle of trust among developers, a pledge that I will write good, solid, and bug-free code and I will trust others to do the same, because if I cannot be expected to do my job properly, then how can I expect the developer working on the software that drives my car, secures my home, or manages my money to do the same?
I can’t say what kind of code the developers at Uber write without seeing the code itself, nor can I make judgements about whether or not Uber or the monitor or the pedestrian were at fault. I don’t have enough information and that’s not for me to decide. What I can say is this: never lose sight of what you do, where your code goes, and how it is used, and make sure that all of your work is your best work. I know I will do the same.