I am skimming through Eric Raymond’s book, The Art of Unix Programming. Discussions on the intersections of technology and philosophy always interest me, and one of the chapters that caught my eye was “Philosophy Matters”. Surprisingly, many of the lessons apply to life, in general.
In a nutshell, the Unix philosophy can be boiled down to: Write programs that do one thing and do it well. The chapter lists following rules that embody the Unix culture.
Rule of Modularity
Write simple parts connected by clean interfaces. Build a program in modules. Make each module do one thing well.
Rule of Clarity
Maintenance and debugging dominates development time. Write programs for the humans who will read and maintain the source code in the future, including yourself.
Rule of Simplicity
Controlling and managing complexity is the essence of programming. Design for simplicity, add complexity only where you must. Actively resist bloat and complexity.
Rule of Transparency
Design for visibility to make maintenance and debugging easier. AS debugging often takes most of a developer’s time, work done early to ease debugging can be a very good investment. A program is transparent when you can look at it and immediately understand what it is doing and how.
Rule of Robustness
The program should perform well under unexpected conditions which stress the designer’s assumptions, as well as normal conditions. Most of the software is fragile and buggy because it’s too complicated.
Rule of Least Surprise
Always do the least surprising thing. The easiest programs to use are those that demand the least new learning from the user. Avoid unwarranted novelty and excessive cleverness in interface design.
Rule of Silence
When a program has nothing to say, it should say nothing. It should shut up. Well designed programs treat the user’s attention and concentration as a precious and limited resource, only to be claimed when necessary. I think this rule applies to life in general. Silence is golden.
Rule of Optimization
Prototype before polishing. Get it working before you optimize it. 90% of the functionality delivered now is better than 100% of it delivered never. Prototyping first helps keep you from investing far too much time for marginal gains.
It seems that the Unix philosophy is quite different from the Rails doctrine. For example, Unix tells you to do one thing, and do it well, Rails values integrated systems. The good thing about not having a religious allegiance to any particular philosophy is the freedom to choose the best from all schools of thoughts, and that’s what I will do.