"Why do we trust things? And how do we bolster trust in software?"
Gertjan Filarski's face

Last Tuesday I was vaccinated with the Janssen vaccine. A single shot protects against COVID-19 in about 67% of the cases. On Wednesday the Dutch healthcare authorities stopped using Janssen. In very rare instances it may cause complications. Since the Netherlands has enough supplies, the health services now prefer to administer those.

And while I was sitting in a bar - for the first time in almost one and a half years - celebrating my vaccination, I had to think about trust.

"Dive"

Why do I trust?

Trust is usually defined as an interpersonal relationship: one person is willing to rely on the future actions of another with usually limited control. I find this definition too narrow. I not only trust people - I also have a trust in objects, or even more generic: in systems. Of course objects and systems are designed and built by people. But I am too far removed and don't know them. I still trust the results though.

Take my car for example: I drive a Hyundai Tucson, but I don't know any Koreans. I rely on it blindly and everyday I push it to a (slightly illegal) 130 to 140 kilometers per hour. I trust it with my life and even the lives of my wife and children. Why?

Same for that Janssen-vaccine. Even though it was developed by a pharmaceutical company in my hometown, I don't know anyone in that industry. So why do I trust it? So much so that I now sit celebrating at a bar in the springtime sun? I could not even wait to get it!

The usual answer people tend to give, is that you can place trust in systems when they have assessment processes and checks & balances. I think that is cheating. I don't take the time to check those, although it's not as if nothing is at stake. I simply trust that those systems and processes are in place and do what they are supposed to do.

Transparency

So what then? In the end I keep coming to the conclusion that trust and faith are almost the same thing - but not quite. I believe that there are enough good people involved to reduce the chance of a terrible catastrophe. I lack the knowledge, time and resources to go and check every assessment, safety control and hiring process. And frankly it is a recipe for a very stressed and unhappy life to go doing that all the time.

The difference between trust and faith is that if I wanted to, I could go and check. Maybe Hyundai would not give me access to their factories (and I wouldn't blame them) but I could learn enough car mechanics to assess the work my garage does. And I could gather the information to figure out how the bureaucracy that checks garages works. I don't, and decide to spend my time differently, but if I wanted to, I could.

So in order for me to trust a system I need to know that it is transparent. That knowledgeable people can review it - a strong and independent investigative press for example.

Trust in Software

Which brings me to software development. A subject that I do claim some knowledge about. What makes me trust the results of a software application? The answer should be the same: transparency. But how many systems and spreadsheets have I build that are truly transparent?

Unlike a car or vaccine, software and spreadsheets used in historical research or heritage collections are rarely a matter of life and death. But getting it wrong may seriously impact careers or future funding. So why do users trust the results? Especially spreadsheets, which are often nothing but rows and rows of nontransparent cells with formulas.

Few software engineers make an effort to create transparent software solutions. Some builds are "open source" and that certainly helps. But an open source version of Excel won't magically turn user created spreadsheets more transparent. In my opinion we, as software developers, need to seriously reconsider how we develop software. Let's start making tools that help users to create more transparent content. We can't limit ourselves by only thinking about our immediate users - we must also consider their sources, their team, and their audience.

Take a spreadsheet again for example: the user is the person who creates the calculations or data sheets, a team member may alter it again later, the data sources are often constantly changing (updated sources, new research platforms, etc.), and the audience may be fellow scholars or an assessment board. As software developers we need to provide tools that do more than just showing the computed results of a mass of coded formulas. We need to provide tools that include integrated audit trails. A log of who changed and added what, where and when. An environment where people can view the original data and not only the current version stored in the sheet. Not to mention a platform that provides insight in the steps that led to calculated numbers. How can users rely on extensive sets of VLOOKUP and INDEX formulas combined with three or four (or five...) nested IF... THEN conditionals? Without reviewing the individual cells you cannot trust that the answer is correct.

None of this technology is new. These features are part and parcel to the platforms that software engineers themselves use to build applications. To improve trust we should start adding these very same features to the daily tools that researchers and data scientists use to create their own content.