«    »

Would You Trust Your Life To Your Code?

Would you trust your life to your code? It is a simple question that you might find extreme. But is it really?

You might argue that the answer to this question depends on the criticality of the software you are producing. Software like the control software for the space shuttle or software to control medical devices is literally life-critical: if the software fails, people can die. The majority of software, however, is far less critical. Business software, in particular, is often financially-critical (failure of the software leads to loss of money) rather than life-critical. So let me ask a related question. Would your trust your financial assets to your code? How much would you wager that your code is correct?

This question might still make you uncomfortable. If you are at all experienced as a software developer, I expect you know that everyone, no matter how experienced, introduces defects in the code they write. What matters in terms of correctness is the code that is shipped or released into production, and the quality level of this code depends on your team's overall software development process, not just your personal efforts. So the question could be applied instead to your team: would you trust your life or your financial assets to the software you deploy into production. (If you are working on the online banking / investment software that I use, I hope you do trust your personal assets to the software you write :)

Notwithstanding the efforts of your team, you personally need to be confident in the correctness of your code before you pass it on to others to review or test. Passing on code that you are not confident in is in essence passing on code that you suspect is wrong. Can you do this and call yourself a professional software developer? This is why I feel it is important to understand and be able to justify the correctness of every line of code you write. You ideally should be 100% sure that it is correct.

In the engineering profession engineers are legally required to stamp and sign the final version of engineering blueprints, documents and reports as a professional guarantee that they are correct. The signing engineer is held personally responsible for failure: in serious cases engineers have received large fines and have had their professional status suspended or even terminated. The same legal strictures are not enforced for most software development, but if you want to call yourself a professional software developer you should feel that same sense of professional responsibility for the code you produce.

Even if the software you write is not life-critical, code is often reused, copied, or adapted. You just do not know where your code might end up. It is possible (although most probably very unlikely) that someone's life – maybe even your own – may end up depending on your code.

Would you trust your life to your code?

If you find this article helpful, please make a donation.

4 Comments on “Would You Trust Your Life To Your Code?”

  1. Michael Foukarakis says:

    I don’t even trust my PC to my code, unless absolutely necessary. The great tragedy with software engineering is that we are taught that failures aren’t critical – if your program segfaults, hey, just load it in a debugger and kludge until it works..

  2. matthias says:

    Simple answer: No. I’m sorry.

  3. Daramarak says:

    But there is more to it than the developer. You might *want* to assert that the code is 100% ok, but when your employer constantly wants you to deliver yesterday, you have to choose between satisfying your employer or your conscience, where the latter might cost you your job.

    I think it is much more about challenging the industry rather than the developer. When the industry stops tolerating errors, the developer might start delivering. Until then, the developer produces what he is able to with the resources he has, or worst case, what he can get away with.

  4. @Daramarak, you are absolutely correct that I ignored the role of the organization / management in providing the appropriate support. This article was targeted solely at developers taking responsibility for the quality of the code they produce. I have seen many cases when given sufficient time developers were still not able to produce high-quality code. Management, of course, must provide sufficient time or must carefully define the desired trade-off in quality, which gets into the debate about “good enough” software. This topic can easily be another article or three, which is one reason I did not want to touch on it in this post.

«    »