What is truth, in Software?

N: Are you saying I’ll be able to fix bugs? M: No, Neo, I’m saying when you’re ready, you won’t have to.

Last time I talked about truth in general, but what does this model of truth mean in a software-eaten world?

Given the Knowledge Theory model of Truth as defined by Correspondence, Coherence, Consensus, or Pragmatic Utility which mechanisms for determining the truth of a software system is the most valuable?

Software is special. In some limited contexts it butts heads with actual reality in a very fundamental way. For example P versus NP. It doesn’t matter what you think … the complexity of some problems are irreducible.

P versus NP

But, practically speaking; beyond these kinds of fundamental limiting factors most of your time as a programmer will be spent dealing with other people’s view of what is true. That’s because most software is integration software.

In this case the truth values of the following questions are actually decided upon by consensus and not much else:

  • Is this behavior a bug?
  • Is this behavior a feature?
  • Is this software working properly?
  • Is this software valuable?

These are fundamental questions about what software is, what it is supposed to do, and why you wrote it; that are not part of the physical reality of the software itself. That’s why truth in software is in many ways harder to determine than truth in reality. In some very fundamental ways, Software isn’t real.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.