Fictional computers such as the HAL 9000 from 2001: A Space Odyssey were envisioned as chauffeurs. You tell the computer what to do and then go along passively for the ride. Bricklin says it looks like people would rather have a Ferrari than a chauffeur. We want our computers to be powerful tools, but we want to be actively involved in using them.
I’ve been thinking about how this applies to software development tools. “Wizards” that generate code are chauffeurs. So are software frameworks. You can go along passively for the ride, inserting your code where the wizard or the framework tells you to. You don’t have to know the route. You can concentrate on “higher level” goals.
It can be a relief to let someone else be responsible for the driving. But after a while you can get the feeling the chauffeur isn’t taking you where you want to go. In fact, you’re being kidnapped. That’s what happened with the HAL 9000 and that’s often what happens with wizards and frameworks.
A good software library is more like a Ferrari. It allows you to do what you want, but you remain in charge. Unfortunately, libraries have a tendency to require wizards and morph into frameworks. When the entropy of a library increases, writing a wizard is easier than improving the library. When it becomes difficult for the wizards to paper over the complexity — make sure you run this wizard before you run that wizard, etc. — the library may become a framework.
So what’s the solution? To write everything yourself from scratch? No, that’s more like walking than driving a Ferrari. Mike Taylor’s article Tangled Up in Tools gives some ideas of how to write libraries that are more like Ferraris than chauffeurs. As he says, “the problem isn’t libraries, it’s bad libraries.” He says a good library is well documented and minimizes the “radius of comprehension,” the amount of context you need to understand to use each feature. That’s a good start.