This text is a good example a tendency I’ve noticed, among plenty programmers, towards elaborated analogies that mislead the reader instead of leading them.

Here’s what happens:

• each new feature introduces both additional functionality and unavoidable complexity
• functionality is desirable, but it has diminishing returns; the functionality of new features is desirable, but less than the one of the old features
• complexity is undesirable, and grows exponentially; the complexity of new features compounds with the one of old features

If you plot those three things together, here’s what you get:

The axis Y is the desirability of the features and undesirability of the complexity.

This graph shows new features are highly desirable at the start, when the software is new; each will add lots of functionality, and almost no complexity. But as the software grows older, complexity catches up, and makes each new feature less interesting. And, at a certain point (the “enuff!” line), new features will make the software worse.

In the light of the above, look again at the rule 1 and rule 2 of the Unix philosophy:

1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features”.
2. Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.

The misleading analogy with koalas would imply the Unix philosophy is against new features. Nope - it’s telling you to add them to new programs, and telling you how those programs should interact with each other. It’s telling you to compartmentalise things so the complexity does not compound; effectively transforming that red curve in my graph into a straight line.