Scale down

I'd like to build on something I mentioned briefly in yesterday's post about efficiency: inefficiency doesn't hurt you as much in smaller systems as larger ones. While that is true, there's also a kind of reverse effect: we tend not to notice small inefficiencies in large systems. So, for example, the code to set up the environment before everything else runs might be way too complicated, but who cares? It's one tiny part of the code and you only have to write it once anyway. We need to worry about the big complexity that affects us every day.

While that is true, and it is absolutely more important to tackle large systematic inefficiencies, even small inefficiencies have a way of becoming quite substantial. The cost they impose can just keep growing but you only have to pay it once per system and it's still proportionally much smaller than everything else, so it never gets dealt with. This might not be a big deal when you build one big system, but it really hurts when you're building lots of small ones.

And that's a significant problem, because most software is too big. It does way more than it should and ends up overcomplicated. But it's very difficult to build small software if the way you do it is inefficient at a small scale. If you have to load up with a whole bunch of complex abstractions every time you start a new project, it doesn't make sense to bother unless the project is going to be big enough to justify it. This inefficiency-in-the-small changes your software the same way that inefficiency-in-the-large does: it rules out certain kinds of problems you can solve.

When we wonder why more people don't write code, I don't think the answer has that much to do with inability to handle syntax or state. I think it's that most people have small problems; they don't want to invent a web browser, they want to organise their bookshelf, or figure out which plants need watering. All our software development systems are too big for that. They come to us for home woodworking advice and we hand them industrial milling equipment. To solve their problems, we need tools that scale down.

For what it's worth, even with all the modern software in the world I still reach for my trusty set of minimal Unix tools when I have a small problem. They're 40 years old and still the best-scaling tools I know.