On Disposable Software

Think of how freely you doodle on a whiteboard versus how carefully you typeset your thesis. How fluidly we hack spreadsheets versus how cautiously we plan databases. How quickly we sketch a UI on paper versus how slowly we build it as software.

The word “disposable” often has negative connotations, but disposability is an amazing property when you can achieve it. When a product or process is disposable, we gain a kind of creative liberation. We no longer have to spend energy maintaining the means and instead can focus entirely on the ends. And if the ends don’t work, we just toss everything and do it again.

Most software creation is far from disposable. In fact the engineering tradition trains us to strive for the opposite. We dedicate extraordinary time toward generalized, scalable, custom-smithed designs. Then we build and deploy them with tooling that cements them in place for years.

This approach works well for enormous tech products, but at what cost to the rest of the world? Most web sites, for example, are little more than attractive wrappers around a dataset. Yet we build them with the same industrial tooling that Facebook and Google use at scale (React, Angular, Kubernetes, etc).

It’s like Monty Python hunting mosquitos with bazookas. As a programmer, where’s my fly swatter?

Frameworks like React and Ruby on Rails are bazookas, while most websites are mosquitos. Besides comedic value, why use a bazooka to kill a mosquito?

There’s a great legacy of dreaming about computers as effortless extensions of the mind. Engelbart saw them as humanity’s way of getting better at getting better. Jobs had his bicycle for the mind analogy. Victor has a great thread of thought on humane computing.

As an engineer, I’d like my computer to be an effortless extension of my hand, too. If we could create software at a speed and cost deserving of the term disposable, just think of the creative forces we would unlock.