UNIX at Made

Everyone in the Made office seems to prefer Unix based systems. Why is that? Sure everyone likes Apple products, they are considered stable, relatively speaking, but I don’t think that everybody appreciates where most of that stability comes from.

Under the hood, OSX runs on BSD UNIX. This family of operating systems was first designed in the 1980s, and was authored by Dennis Richie and Ken Thompson.

Unix has its own philosophy, and when applied correctly, can lead to some beautiful software.

What is the UNIX Philosophy ?

• Write programs that do one thing and do it well.
• Write programs to work together.
• Write programs to handle text streams, because that is a universal interface.

Read more about the UNIX philosophy.

Extremely contrived example of doing one thing

Consider the following functions:

generate_report
send_email

vs

generate_report_and_send_email

Which is better? The first of course.

Instead of generate_report_and_send_email as one function, we prefer smaller reusable components. Big methods tend to violate the SRP principle, and are hard to maintain. When used correctly, we will also achieve another important design goal known as “Composite simpler than the Sum of it’s Parts”, as you abstract out concepts in the system.

As a rule of thumb, if your function name contains an “and”, it is probably doing too much. If your function name contains an “or”, it is doing too much.

UNIX at Made

When we design complex systems, we have had good results with following the Unix philosophy, which is also in line with a lot of the Agile methodologies that we follow and practice:

• No more than 100 lines per class
• No more than 10 lines for executable function bodies.
• No more than 4 arguments for a function (Yes big hashes are cheating).
• No more than 80 characters per line

We use software that makes sure this is true, or it will fail the build. We’re programming a lot of Ruby at the moment, making Tailor and Cane our current tools of choice.

Small functions and abstraction

When you write small functions, you end up naming more of the system. This has many benefits and, as a nice free side effect, your code becomes dynamic documentation. Instead of complicated cryptic instructions (implementation details), you can read the name of the abstraction (function name) and get a better idea of what the author had in mind when they first wrote the code.

We have found this style to be very effective, and I encourage everyone to learn more about the Unix philosophy and try to apply it to your code.

About the Author