Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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'.

Edit: Assuming that there can be commercial trivial software, can people please post some links to software that they think would be considered trivial/

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

share|improve this question
8  
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 Feb 24 '11 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 Feb 24 '11 at 16:33
    
Check the updated question. –  NVM Feb 24 '11 at 16:38
add comment

9 Answers

up vote 10 down vote accepted

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.

share|improve this answer
    
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 Feb 24 '11 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 Feb 24 '11 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 Feb 24 '11 at 17:37
add comment

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.
share|improve this answer
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 Feb 24 '11 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 Feb 24 '11 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 Feb 24 '11 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 Feb 24 '11 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 Feb 24 '11 at 16:26
show 2 more comments

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

share|improve this answer
4  
+1 That made me laugh and it also makes sense. –  NVM Feb 24 '11 at 17:19
add comment

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.
share|improve this answer
add comment

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.
share|improve this answer
add comment

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

share|improve this answer
add comment

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.
share|improve this answer
add comment

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.

share|improve this answer
add comment

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

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

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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