I meant the opposite of all-encompassing software. What I mean is largely summed up by the linked Wikipedia article, but I'll give a go at explaining it in my own words.
Given a problem, a solution can be found that explicitly composes simple routines in simple ways, or a solution that may do the same thing implicitly, but only exposes an in and an out. The first solution can be said to be following the Unix philosophy; the second follows the monolithic design [0] paradigm. The first solution is superior, in that it is "simple, short, clear, modular, and extensible code that can be easily maintained and repurposed by developers other than its creators" (quote from Wikipedia).
Generally, creating something new in the Unix style goes like this: I have `X`, I want to arrive at `Y`. The process can be summed up as a sequence of these transformations: `f1`, `f2`, `f3`. So the solution can be said to look like this: `Y = X | f1 | f2 | f3`. `f1` and `f3` are already available, possibly created by someone else while solving an entirely different problem, but the same subproblem). That means implementing `f2`. To implement this missing subroutine, the process is the same.
So the benefit of this philosophy is that it leads to pooling of problem solving resources (i.e. people), by allowing multiple problem solvers to arrive at their unique solutions by solving common subproblems (writting common subroutines).
[0] https://en.wikipedia.org/wiki/Monolithic_application