Please Don’t Get Off My Lawn: Abundance, Scarcity and Problem Solving

This isn’t a “get off my lawn you kids!” story. If anything, it’s the opposite.

During my early days in the computer industry we lived in a severely resource constrained world.

The old days: scarcity

I learned to program in 1978 on a TRS-80 - a computer with a 1.77MHz 8 bit CPU and 4KB of RAM. Just imagine trying to do anything in 4KB of RAM today. Imagine trying to get anything done with less than 2 million instructions per second. And for persistent storage… it wasn’t just that it was small and slow, it was a cassette tape and you were lucky if you could even read back your program at all.

In the mid-80’s at MIT we were excited to be connecting a 143 pound, $10,000 470MB (unformatted) Fujitsu Eagle hard drive to a 32 bit 3.125MHzVAX 11/750 with maybe 1 or 2MB of RAM. I think it took three people to secure the drive in its rack.

Today: abundance

Now I carry around an iPhone with 128GB of fast persistent storage, 2GB of RAM and a dual core 1.85GHz CPU. In my pocket. It weighs less than 7 ounces. And it’s almost always connected to the Internet, without wires, usually with speeds approaching 1Gbps.

That means my phone has 500,000 times the RAM of the TRS-80. Its clock rate is 1045 times greater than the TRS-80’s, which doesn’t even take into account how much more work per clock cycle it can do or that it has two processor cores. And let’s just say its persistent storage is almost infinitely bigger, better, faster and more reliable than a cassette tape.

My phone could run circles around a 1980’s supercomputer let alone a TRS-80. And my desktop computer is even bigger and faster, with a quad core 4GHz CPU, 32GB of RAM and 1TB of fast persistent storage.

It’s easy (very easy) to mock the fact that the gold standard program “Hello world” might require megabytes on today’s systems, or that today’s programmer’s “just don’t know how to write tight code”.

Priorities

Back in the 80’s we had to prioritize small code - we just didn’t have the RAM, storage or CPU power for large code. We didn’t have the tools to manage large code - revision control, automated testing, dependency management.

Back in the 80’s, our time was less valuable than RAM and CPU cycles. Therefore we spent a lot of our time working within the limitations of the devices we were programming. Our priority was optimizing had to be tight small code, not developer time.

Problem solving in abundance

I’m writing this in 2016. Now we’re living in a future that most developers in the 80’s would not have imagined.

Today we store our programs in repositories that keep a complete copy of every version of every file, on each computer that uses that code. Today we avoid conflicts with the copies of programming languages like Perl, Ruby, Python and NodeJS, that are built into our operating systems by keeping personal copies of their entire toolchains, including libraries - and frequently multiple versions because specific applications that we use are pinned to specific versions of the languages they’re written in.

Persistent storage is so cheap that when NodeJS’ npm utility installs a dependency, it also installs all of the dependency’s dependencies. So if you have 23 dependencies that all depend on left-pad, you’re going to have 23 copies of left-pad installed. To an 80’s programmer this sounds awful - crazy wasteful, but it saves npm from Microsoft Windows-style DLL Hell.

We have so much storage, memory, CPU power and bandwidth at our disposal that with Vagrant we copy entire installations of operating systems to our computers and run them simultaneously with the computer’s native OS.

And blockchain - the new sexy in the tech world - is a cryptographically secure distributed journaled database (which means you have a very high level of confidence that its transactions are accurate and complete, that you can see its history, and that there are many copies). Back in the resource scarcity days you’d assume that “distributed” meant pieces of it were scattered all over the place. Distributed today means that everyone has a copy of the whole thing, which is kept in sync. Because storage and bandwidth are so cheap and plentiful, why wouldn’t you?

 

Please don’t get off my lawn

I promised that this wasn’t a “get off my lawn you kids!” article, and it’s not.

Instead of complaining about how things have changed, I want to emphasize how important it is to choose the right priorities for the problem you’re trying to solve and to adjust your mindset over time so that you’re open to new ways of solving problems.

When computers were highly resource constrained, it made a lot of sense to prioritize resource use over programmer time. These constraints shaped our thinking, and decades later the instinct of many developers from those days is still to solve problems as if computers were small, slow and had poor connectivity.

Today, with fewer constraints we can focus on other priorities: easing the tech knowledge needed to work with systems, protecting developer time, improving software correctness and reliability.

Of course, there are still plenty of opportunities for computer work in a resource scarce environment: try programming an tiny micro-controller sometime. And of course we still have resource constraints… consider how easy it is to write a web page that overwhelms your browser.

Having priorities appropriate to the context in which we’re solving problems opens up entirely new solution spaces for us.

Developers stuck in the 80s would not have thought up solutions like blockchain, Vagrant or git (and in fact may read this line and want to argue that these are not even valid solutions to problems).

So please don’t get off my lawn.

Stick around, keep thinking and coming up with new ideas that only people with different sets of priorities can come up with.

If you have abundant resources, think of solutions that people with a scarcity mindset would never imagine.

If you have scarce resources, solve problems in elegant, tight ways that people with an abundance mindset wouldn’t come up with.

Bring diverse viewpoints and open minds to the table so that we can solve bigger problems better. And don’t mind the lawn.