The major difference between a trivial project and a serious project is that on a serious project, maintenance and improvements take much, much longer than the initial development phase.

The other difference is that a trivial project can become serious, but a serious project never becomes trivial – it gets abandoned.

I’ll tell you a story about errorwatch.

Something over ten years ago, it became obvious that there were lots of programs in our system that kicked off according to what time it was – classic “cron jobs”, so-named because the cron daemon is the master program that schedules them to run. There were programs that ran every few minutes, some which ran a few times per day, or once a day, or at the beginning or end of a month.

If they ran perfectly, nobody was concerned. But if they encountered any problem, we needed to know about that. Options for notifying us included log files, console output, or email. Almost every program left a log file behind, and the problems usually came to some email address. Not always the same email address, mind you.

So I wrote a trivial program called errorwatch. It was very simple: the cron daemon called errorwatch and had errorwatch run the real program. errorwatch had options for where to write the log file, which would include a time stamp, what email address to notify in case of a failure, and a potentially different email address to notify in case of success. Then I added one more option, to make a successful run “quiet” and not send the whole log.

You can guess where this is going, right?

Over the years, errorwatch got the following useful features:

• an “extremelyquiet” mode, which does not send email at all for a success
• a timer, which declares a program to be a failure if it has not returned in a specified period of time
• an extra message to include in the email body
• a way to change the subject of the email
• a complete listing of options and example usage
• a way to turn a success into a “warning” – not a failure – if a certain string is found in the output of the program
• a way to specify that string
• an option to not run the program, not create the log file, but just tell the user what it would do if the debug option were not present
• a verbose mode which gave the user a lot of detail on what errorwatch was doing
• a way to turn a success into a failure if a certain string is found in the output of the program
• a way to turn a success into a failure if a certain string cannot be found in the output of the program

On average, errorwatch gained one new feature a year.

And at this point, a senior programmer suggested that errorwatch needed a proper testing module. It is still under 400 lines long, and about one-third of that is comments and documentation and such.

But it is no longer a trivial project.