1

This question already has an answer here:

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?

marked as duplicate by Thomas Owens Jun 14 '14 at 12:21

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • hello world is trivial – ratchet freak Jun 13 '14 at 20:36
  • 7
    Any bugfree software is trivial ;-) – Doc Brown Jun 13 '14 at 20:37
  • 1
    Where is the difference between a stream and a river? – Philipp Jun 13 '14 at 20:39
  • I think you are confusing 'trivial' with 'impossible to write incorrectly', whereas its actually closer to 'easily written correctly by a competent practitioner'. It's an entirely subjective judgment, but as with all subjective judgments it's possible to find examples that 95% of people will agree on. – Charles E. Grant Jun 13 '14 at 20:55
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.

0

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.