The Unix Philosophy

I'm a software engineer by trade.  One thing I've learned is that college is not enough to make you a good software engineer (or programmer, for that matter).  You have to make a lot of mistakes yourself to get good at it.

One viewpoint which leads to a lot of such mistakes, and one which must be discarded in order to be a good programmer, is the idea that "more features is better."  The result of such a misnomer is bloated software which tries to do everything and doesn't do anything very well.  Not only that, but the resulting software has limited configurability and uses more resources than necessary.

The "Unix Philosophy" is a perspective on software development which is aimed at addressing this problem.  It consists of a list of rules of thumb that programmers and software engineers should apply to their work.  There is a bit of disagreement about some of the wording, but the spirit of the Unix Philosophy is well agreed upon.

From Wikipedia, Mike Gancarz's version of the unix philosophy:

1. Small is beautiful.
2. Make each program do one thing well.
3. Build a prototype as soon as possible.
4. Choose portability over efficiency.
5. Store data in flat text files.
6. Use software leverage to your advantage.
7. Use shell scripts to increase leverage and portability.
8. Avoid captive user interfaces.
9. Make every program a filter.

Let's take these one at a time, shall we?

1. Small is Beautiful

A large program has many potential points of failure.  If there's a bug, it's easy to find because there's not as much program to look through as if it's a big program.  Also, if it's small enough, it's easy to keep the entire inner workings of it in your head at once.  It's easier to grasp.  And it takes less work for somebody unfamiliar with the program to become familiar (or even an expert) with the software.

But how small is small?  Let's take an example of a class of software applications generally considered to be required to be "large" -- web browsers.  Sloccount (a tool for counting how many lines of source code a program consists of) reports that Firefox 8.0 (a fairly recent release) consists of 3,291,364 lines of code.  Surf is a minimalistic browser which follows the Unix Philosophy.  Sloccount indicates that the recent 0.4.1 release of Surf consists of 753 lines of code.  That's an incredible difference.

2. Make Each Program do One Thing Well

In other words, each program should have exactly one feature.  No more.  No less.  A program which does two things is unnecessarily complex.  If you need two features, use two programs.  Simple.

3. Build a Prototype as Soon as Possible

Often, this is phrased as "release early and release often."  If you release a prototype, you can get feedback early, which allows you to fix problems early on.

4. Choose Portability Over Efficiency

Portability gives you more options.  It allows you (and others) to test on faster hardware and slower hardware which allows you to ferret out issues nicely.  Also, it will pay off later when the niche technology you decided not to use becomes abandonware.

5. Store Data in Flat Text Files

Flat text files give a lot of power to the users as opposed to binary formats.  Binary formats, even if the code for parsing them is open source, just take a lot more work to work with.  Flat text formats can be edited in text editors.  It can't get much easier than that.

This one in particular is the subject of some controversy.  Many object that databases are often times the right tool for the job of storing data, even if they do have some drawbacks such as making it more difficult to port the data to other means of storage.

6. Use Software Leverage to Your Advantage

Code has some interesting properties.  One is that a useful function or library may be written once and used in multiple places.  Many mistakes may be made in the process of writing software which makes it difficult to reuse useful bits of software, however.  "Using Software Leverage" means making your software easy to reuse so that you don't have to rewrite it later.

7. Use Shell Scripts to Increase Leverage Portability

Shell scripts are wonderful things.  They're written to run in the shell, which means they are written in the same language as the commands you type directly on the shell.  A single line in a shell script can actually do a surprisingly powerful operation.  Also, shell scripts can be made very portable very easily.

8. Avoid Captive User Interfaces

A "captive user interface" is one which requires (or virtually requires) a human to operate.  Just about any interface which requires a mouse is a captive interface.  These are not always a bad thing, but are almost always a bad thing.  They restrict the ways in which the program may be used.

9. Make Every Program a Filter

A "filter" is a program which takes input and produces output without any other effects.  A good example of a filter is the Unix command "sort" which takes a bunch of text (one word per line) sorts the lines lexographically, and prints out the sorted version.  It does nothing but sort the input and print out the sorted version.

This is just an overview of the Unix Philosophy.  There is much more to be said.  There are in fact books on the topic.

But don't worry.  You'll be hearing a lot more about the Unix Philosophy and applications which employ it.

Happy hacking.