What is the cost of failure in your line of work?
Now, I’m in the software engineering industry so this question comes up very often. Actually this question will come up in any field where success is valued… which means every field, every job, every line of work.
Let’s take some more obvious examples. If you’re a surgeon, the cost of failure could be that someone loses their life. If you’re a firefighter, the cost of failure could be that the forest burns down. If you’re an athlete, the cost of failure could be a life-threatening injury. If you’re a lawyer, the cost of failure could be someone being wrongly imprisoned. All of these have immediate and tangible impact.
So what about software engineering?
These days, software engineering is used for everything — yet is not everything, but a field like any other. Therefore the cost of failure in software engineering is whatever the cost of failure is in the field it is serving. For example, if you’re building a robot that performs surgery, the cost of failure is the same as that of a surgeon — someone may lose their life. On the other hand, if you’re making a dating app or a mobile game, it might be a different story.
A few years back, “mission critical” was the hot term on job descriptions. Join our team and work on mission critical applications! Everyone and their brother was mission critical, from aerospace to medicine to dating apps. Yes, success is a good thing. We all want our ventures to succeed. But how “critical” is a dating app, really? If a mobile game fails, is it the end of the world?
One can postulate that everything is important, simply because there are people doing those jobs. And it follows that everything is equally important, because each of those people is equally important. Sure. But… this would only be true when money is the only thing considered. Everyone working on a “mission critical” application has a job, and they stand to lose that job if they fail. However, that job is just a job, and there is a real purpose behind it. And not all purposes are created equal.
Here, I don’t mean “more” or “less” important. These days, we value the uniqueness of every person and every purpose. They are all equally important. Yet they are differently important. Saving someone’s life is differently important from finding a date. A dying person needs to be saved more than they need a date, but a lonely single needs a date more than they need their life saved. (I’m probably more confident about the first one.)
The cost of doing badly
So, we can assume that everything is worth doing, just not necessarily worth doing immediately. However, it’s very common in the software engineering industry to have deadlines. To ship things on time. To hurry up. They use the word “sprint” a lot, I mean all the time. What does that bring to mind? A sprinter sprinting to the finish line, or a rabbit being chased by a wolf? In the end, software engineers work for a company, which answers to shareholders, who are interested only in profits. If you fail to make profits, you’ve failed the entire mission. Luckily for software engineers, projects take time, which allows for a lot of wiggle room. The rabbit can run for a long time before the wolf catches it.
Outright failures are rare occurrences. What does happen more often is that the job is done badly. It’s not feasible to prevent all mistakes from occurring. It’s not feasible for every employee to be fully competent at all times. What happens when the job is done badly? The schedule slips, or the end product has bugs. And then what happens?
The answer: job security
More often than not, if the schedule slips or the end product has bugs, life goes on as usual — especially if what you’re building is “differently” important, such as a mobile game. Nevertheless, those shareholders still want their money. So what can they do? They will extend the schedule, or hire more people… all of which means more job security for the people who made the mess in the first place.
“Technical debt” is when a product has little problems which are left unsolved, which accumulate over time and create bigger problems later. People hope that the bigger problem never rears its head, and deal with it only when it does — very painfully. Similarly, a company can accumulate employees, who create problems, which causes the company to hire more employees to fix those problems, who create even more problems. It’s a never-ending cycle, which quite disturbingly resembles a pyramid scheme. (Somewhere along the line a product or two gets created, I suppose.)
Of course, there are software engineers who work in fields with more immediate costs of failure. They could be detecting cancer, launching spacecraft, controlling a utility grid, increasing healthcare access, and so on. There’s more at stake for them. But the majority of software engineers are not like that.
Yes, embracing “failure” is the hot thing these days. Iterate fast and fail fast. That’s not the kind of failure I’m talking about — that’s just finding a way which does not work. The kind of failure here, is when there is something at stake.
There are no solutions to be proposed here; I’m not sure there’s even a problem in the first place. The problem is all in our heads. But the problem is, everything in our heads is real. We want spiritual fulfillment, yes, even the software engineers. We want to have a connection to whatever we’re doing. Having an immediate and tangible cost of failure, having something at stake, is the surest sign of that connection.
Right now, it’s looking like we — many of us — have nothing at stake except our jobs. Rarely will you hear, say, an athlete, a musician, or anyone who puts their life on the line on a regular basis, describing their job as “soul-sucking.” They may say that their job is hard, is dangerous, pays poorly. Even with all that, it’s fulfilling on a spiritual level. It gives them purpose. And in the end, isn’t that what it all comes down to?