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 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!
Top comments (2)
It's interesting to see where the Unix philosophy is still holding up, one example is the design ethos behind Powershell, nicely blogged by it's creator Jeffery Snover back in 2006: devblogs.microsoft.com/powershell/... (note: it was called Monad then!)
Very nice. I’ll give it a read for sure!