Doing One Thing, Well: The Unix Philosophy

This is always hardest in the beginning. At the start of any project, it feels wasteful to separate every bit of functionality into its own, self-contained project, including the necessity to implement a standard I/O model for it.

But as the project advances? I'm usually cursing myself for writing code that does two or three things, because suddenly it needs to be configured to do a slightly different 2 or 3 things, and before you know it I don't even know why I wrote the damn thing in the first place.

> Another interesting idea to come out of the computing world around that time was the saying “worse is better“. Although this idea wasn’t a direct relative of the Unix philosophy, it’s certainly similar. The idea references the fact that additional features or complexity doesn’t necessarily make things better, and a “worse” project — one with fewer features and less complexity — is actually better because it will tend to be more reliable and usable.

I don't think that this is an accurate description of "worse is better". I've always taken it as being a bit (or more) tongue-in-cheek. Sort of an analogy to the saying that a lie can travel half-way around the world before the truth can get its boots on, but going on the say that a lie is therefore better because its faster.