A Few Rules of the Unix Philosophy
Tags: unix, design, programming, devops
Published: 2020-04-21 20:55:28

After reading and meditating on the 17 Rules of the Unix philosophy, I have a deeper appreciation for what the pioneers of Unix accomplished. Though these are gleaned from ideas and practices as old as the early 70s, the fact that they ring undeniably true today, reinforces their importance.

The most important themes in the list seem to be clarity, simplicity, and flexibility of design. In the world of devops, it seems like there's a new hot tool released every other day. I feel we should strive to adhere to these rules so we don't get lost in the weeds and bloat our infrastructure. Tools obviously are important, but balance is needed. So I thought it would be fun to go through a few of my favorite rules and explain their benefits as simply and succinctly as possible. Lets do this!

**1. Rule of Modularity: Write simple parts connected by clean interfaces**
Building programs out of simple parts, that are easily connected makes maintenance/updating easier and safer.

**2. Rule of Clarity: Clarity is better than cleverness**
Similar to rule 1, clear and understandable code is better than fancy code. Make it easy for another human to understand and read.

**3. Rule of Composition: Design programs to be connected with other programs**
Lest you build a monolithic program that does everything, programs should be made to be independent, but easily connecting with other programs. Think Voltron!

**4. Rule of Separation: Separate policy from mechanism; separate interfaces from engines**
Simply put, when these are combined it's very difficult to change one, without destabilizing the other.

**5. Rule of Simplicity: Design for simplicity; add complexity only where you must**
Avoid making complex programs just for bragging rights. Again this follows the same thinking as rule one. Build infrastructure with small, simple moving parts that work well together. 

**9. Rule of Representation: Fold knowledge into data, so program logic can be stupid and robust**
It's much easier to change data than program logic. If something must be complicated, it should be the data. 

**14. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can** 
Automation in it's earliest form. Following this rule will save a programmers time(which is expensive), and help to avoid errors, as computers tend to be more accurate than humans. 

**17. Rule of Extensibility: Design for the future, because it will be here sooner than you think**
This rule is the life blood of nearly every rule on the list. Make your code simple and easy to manage, so either you, or the person maintaining your program has an easier time. Organize your work so future developers will be able to implement new functions to the architecture without having to scrap and rebuild it. 


These are just a few of the ones that were very eye opening for me. I urge you to [give the excerpt a read](https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s06.html) though. It obviously goes in to much greater detail. 
I feel that we should strive to inject these principals into the culture of devops as much as we can.  Hopefully you agree!