[greggman3]

hmmm, if I apply that logic in other places it doesn't seem to work.

* if you can't cook with just a knife then it your food should be redesigned to need only a knife.

* if you can't film in with a camera then you should rewrite your movie (no CG).

* if you can't send it by paper then it should be re-written (no animation, no interactive diagrams, no apps)

To put it another way, I'd much rather use Final Cut Pro or Davinci Resolve to edit a video than FFMpeg. If someone became an expert in editing snippets into movies with ffmpeg from the command line and then told me that writing movies that require lots of editing is just bad writing and that it would be better if I wrote my movies so they required as little editing as possible I'd look at them funny.

Isn't it possible building up the system is a force multiplier in the same way that all the examples above the false restrictions prevent lots of progress?

[camgunz]

It's not about force multipliers in general. It's about looking at what force multipliers incentivize/deincentivize and amplify/muffle.

With your examples, I would say something like:

OK I once only had a knife, but now I've invented an egg beater. This will allow me to do some things a lot more easily like:

- Bake cakes

- Eat soup

This will also mean I cut myself a lot less when I do decide to do something like eat soup.

So we're gonna have more cakes/soup in the world. Good? Great, egg beater stays. Bad? Woof, burying this thing in the yard. But wait I hate cutting myself. OK I'll figure out some other way to keep myself from gorging on cakes, or I guess be content with that.

So, broadly it's about thinking systemically--how the design of our tools affects how and what we build. Because it definitely has an effect. If it's easier to use a nailer than a screw gun, guess what, you're nailing more stuff. If it's easier to write a PRECONDITION clause in a function definition than a unit test, guess what you're writing a PRECONDITION clause.