12

So what really makes a program trivial?

'Unless its trivial software' is used so often in programming discussions. I find it very vague in the sense that I can't really figure if 'something is essential because its non-trivial software' or 'its non-trivial software because something has become very essential'.

For example, a lot of times on the question of unit testing, I hear 'unless its trivial you will need to unit test'.

Improve this question
3
  • 9
    Judging by some of the programmers I've worked with, I'd say that for them the distinction came down to "your code is trivial; my code is not".
    – PSU
    Commented Feb 24, 2011 at 16:18
  • Could you provide a programming discussion in which you see this quote used? It seems there are different interpretations in the answers.
    – Steven Jeuris
    Commented Feb 24, 2011 at 16:33
  • Check the updated question.
    – NVM
    Commented Feb 24, 2011 at 16:38

10 Answers 10

Reset to default
12

I'm going to go out on a limb here and say:

A trivial program is one that does not directly impact the business.

A manufacturing firm would consider its accounting software trivial, but the software that controls the robotic arm that moves boiling steel is critical. They can deal with bugs and low support turnaround in the former, but not it the latter. If there's an issue, they need it fixed now.

Improve this answer
4
  • Although, another answer has more points, I like this answer best. I asked the question because I am not entirely sure if the work I am doing is trivial or not and this is a sure shot way of figuring if its considered trivial by the 'business' or not. For ex. trivial software can get away without unit testing and it doesnt really depend on lines of code or complexity. All that matter is whether its critical for the business or not.
    – NVM
    Commented Feb 24, 2011 at 16:27
  • +1, Good point. The Corporate Overlords sometimes have very different ideas about what counts as "trivial". I've added a few to my answer to reflect this.
    – FrustratedWithFormsDesigner
    Commented Feb 24, 2011 at 16:42
  • +1 - I think this answer best describes the context of the term as it is applied in the question. The other "higher point answer" is accurate, but only in a general context. I'm sure this one will surpass it in up votes as that is considered.
    – Joel Etherton
    Commented Feb 24, 2011 at 17:37
  • 2
    When software developers say trivial they usually refer to the complexity of the software, not the business impact. A script which copies some files from A to B would be trivial, but might still directly impact business if it doesn't work.
    – JacquesB
    Commented Feb 13, 2016 at 10:53
16

I believe the most common intention of that statement would be for a program to have the following characteristics:

  • It's small.
  • Short lifetime.
  • No need for further extension.
  • Only one developer.
Improve this answer
9
  • 2
    +1, all of these are crucial. Unfortunately, in a world with ever-changing requirements you'll be bound to sometimes have to expand "trivial" software beyond its natural lifetime.
    – l0b0
    Commented Feb 24, 2011 at 16:08
  • 1
    Small in terms of LOC, small in terms of compiled binary size, small in terms of time taken to develop it? Also, I'd argue that short lifetime does not imply trivial and trivial does not imply short lifetime. I've seen cases where software with a liftime of only 6 months was in development for at least twice as long and was a crucial bridge system. I've seen data conversion systems that were used exactly once, but were in development for over a year and were far from trivial. And trivial progams like Minesweeper seem to have very long lifespans.
    – FrustratedWithFormsDesigner
    Commented Feb 24, 2011 at 16:13
  • @FrustratedWithFormsDesigner: small as in, a 100x100px window ofcourse. ;p I mean, small as in lines of code that have to be written, which is proportional to time taken to develop it. Lifespan isn't essential, you are right, but often a characteristic when discussing a more advanced approach vs a simple approach.
    – Steven Jeuris
    Commented Feb 24, 2011 at 16:17
  • I would disagree that low LOC always implies trivial. Sometimes the most complicated part of a program, the hardest part to get right, the trickiest algorithms, fits into < 20 Lines Of Code. And a program that is mostly hundreds of lines of auto-generated getters/setters - is that then non-trivial even though it does not even need a developer to create it?
    – FrustratedWithFormsDesigner
    Commented Feb 24, 2011 at 16:20
  • 1
    @FrustratedWithFormsDesigner: I believe you have a different interpretation of the question than I do. My answer relates to the fact of deciding on a trivial solution vs. a complex one. Your answer relates to 'difficult' vs 'easy' problems to solve. Perhaps the OP's question should be clarified a bit.
    – Steven Jeuris
    Commented Feb 24, 2011 at 16:26
15

By throwing it away completely, binaries and sources. If somebody notices, it was not trivial.

Improve this answer
1
  • 7
    +1 That made me laugh and it also makes sense.
    – NVM
    Commented Feb 24, 2011 at 17:19
9

Trivial is...

  • something that already exists, so why re-invent the wheel?
  • something that can easily be built by either scripting a few other programs together or writing a little code that makes heavy use of existing libraries that do what needs to be done.
  • something that an average CS undergrad student could do as small to medium homework assignment.
  • something that has detailed requriements that could easily fit on a cocktail napkin.
  • something you could code while distracted/drunk/in spare time of 4 or 5 minute chunks.
  • something that could be created with a simple code-generating tool.

In a corporate environment, I'd add these:

  • something that the Business Users don't mind waiting for a while for a fix.
  • something used internally that has no official support from IT.
  • something that is prioritized among the lowest priorities by the Business, when doing resource planning and scheduling.
Improve this answer
4

I would define a trivial program as one that could reasonably be coded:

  • In one sitting.
  • As a single file/module (assuming you're not programming in Java or some language that forces super fine-grained splitting of modules).
  • By any decent "jack of all trades" programmer, rather than a specialist.
Improve this answer
3

Here are my examples of "trivial" programs:

  1. A "dummy" project that I setup and began coding just so I can try out a piece of technology or sample code. No intention to be deployed or even shown to anyone.
  2. Demo code written for technical presentations.
  3. A "one-off". I mean a quick application that I had to build to use once, because it is an odd situation of data that had to be moved in a certain way, or something that will then be immediately replaced by something more permanent.
Improve this answer
3

Trival software doesn't exist, it is when you hear requirements and thing that will be trival when in reality it is always non-trival

Here is a quote I saw on the Usenet a decade ago, it is even more relevant now.

Complexity of a Software Solution is inversely proportionate to the complexity of the explanation of what it should do. - Unknown

Improve this answer
-1

A program that is just a bunch of just getter/setter methods. No programming logic. Maybe something with a few loops.

That's my definition of trivial.

Improve this answer
-1

Our working definition is "something nothing else depends on."

Unfortunately there have been a few trivial prototypes that became non trivial production products.

Improve this answer
-3

I've also heard it used in the context of the program's impact on the overall project planning. If a certain specification doesn't change the timeline of delivering the product, it falls under the label of trivial.

I knew one programmer who tended to use "trivial" as a synonym for "Not even worth discussing".

Improve this answer

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