1

You often see statements like "all non-trivial software has bugs" or "all non-trivial abstractions are leaky". But what makes a program "trivial" instead of non-trivial? Where is the cut-off line at which we can say that a program isn't trivial and "excuse" bugs?

Even something only a few lines long could have bugs. Say you have a simple command line C program that asks "What is your name?", reads a response using scanf or gets, stores it in a buffer and prints back "Hello " + name. That program could easily have a buffer overflow if the input is larger than a buffer, so it could have a bug even though it's only a few lines.

But if you ensured that you always allocated eblnough memory or bounds checked, etc, you don't have the bug. So is the program "trivial" or not? It can be buggy or not, but it's small and simple. Can we give any meaning to the idea of a "trivial program" or is it merely an excuse for sloppyness?

ojf
  • 19

2 Answers2

5

"Trivial" typically refers to an implementation that demonstrates the relevant functionality and no more, though there is no hard-and-fast rule.

In the examples you list, the word is used to couch against purpose-built counterexamples. For example, "all nontrivial abstractions are leaky" means something like, "all abstractions are leaky except for ones you devise specifically to disprove this statement." If the purpose of your abstraction is to illustrate an abstraction, then the author would probably consider it trivial.

Another interpretation is to imply that there exists a certain threshold of complexity below which the axiom doesn't apply. In that sense, "all nontrivial abstractions are leaky" means that all non-leaky abstractions are defined as trivial by this axiom. This is the "no true Scotsman..." argument reapplied.

tylerl
  • 4,850
  • 22
  • 32
1

It's a rather open-ended question.

Trivial could be software in which the amount of time required to fix the problem would cost more than any kind of workaround for it. Another example would be a small utility that has one of the bugs you mention, but since it is easily replaceable by another utility that does the same thing, it gets ignored.

I work on 911 systems so I work with a lot of non-trivial software. However, we have some management utilities which were written 10-15 years ago that we consider trivial since there is no real business advantage to updating them. Even the occasional bugs that come up are often ignored since we can go direct to the database and fix the problem. We're a pretty small shop though, so YMMV.