The "do one thing, and do it well" is really misleading, the Unix philosophy cannot be distilled down to a single phrase - this phrase only makes sense if you a

The "do one thing, and do it well" is really misleading, the Unix philosophy cannot be distilled down to a single phrase - this phrase only makes sense if you already understand the ideas (also naming it "philosophy" is kinda misleading too because it doesn't expect everything to follow it, only use it as an ideal for program design that you should strive to follow, but not bind yourself over it and ignore it when it makes sense - a good example for this would be something that does a lot of things that in turn allow programs to follow the Unix philosophy better - like an OS kernel). The main idea behind the "do one thing" is really composability: by doing one thing, your program can be used to provide the functionality for other programs to form applications. Patch uses ed because it needs to edit text and ed provides the text editing functionality, but ed can also be used interactively or from a shell script or by some other program. This is because ed doesn't care how it is called nor where the commands come from. This isn't enabled by its simplicity, but by its design to be composable: it would be a trivial difference in terms of complexity (and indeed there were similar programs in other systems that did exactly that) to ask the user for a filename upon launching it. But that would only make it useful as an interactive program (which is also why the Unix philosophy warns against captive user interfaces). Ironically, Microsoft's COM and OLE followed that idea better than anything on the graphical side of Unix ever did (except X11 itself, but few programs ever took advantage of it - the best case would be applications meant to be "swallowed" inside docks - docklets - and panels, but those are very task specific). However there is also something to be said about being simple and COM is anything but simple.