Full disclosure: I was there at the dawn of the microcomputer age. Seeing an old Atari joystick washes nostalgia over me. I remember the simple joy of typing in pages of BASIC code of a program in a magazine — and then the tedium of finding the one error that kept it from running. And I remember the creativity in getting the hardware to do just a little bit more, from graphics to storing information.
In the early days, being a programmer meant embracing scarcity.
When I was a senior in high school I talked my way into creating an independent study course in computers (by that point I had taken every computer course offered by the school…all three of them). My teachers gave me great freedom (along with the accountability — an important first life lesson) to pick the work that would constitute the IS program. Because a whole semester seemed like an eternity of time, I decided to develop my own programming language.
My goal was to create something people not familiar and not comfortable with computers could use. This was, after all, the days when the command line ruled; when the most simple tasks like copying a file required arcane strings of partial words and numbers. I called it “Syntex” based on a vague notion that it would synthesize command text (quickly dashing any hopes of a career in product naming). The language was English-like. Instead of commands like “LOAD ‘*’, 8,1” the user would type in “list files.” Instead of “POKE 53280, 0” it was “background black.” I was incredibly excited about the possibilities and in several bursts of late-night programming (another life lesson) I had the core of the program written.
Syntex was developed on a Commodore64, the machine I had at home and used in the lab at the school. Late in developing it (and mere days from when it was due) I decided that more advanced users might use the language to write their own programs that they would save and run over and over again. But that program would have to be held in memory and on the Commodore 64, there was a mere 39k of memory available to work with — Syntex consumed 38k already. To make that one feature possible I needed to find at least 7k of memory somewhere. I had to embrace the scarcity.
I started literally at line 1 of the source code, taking the program apart and optimizing where I could. There were needlessly large arrays and structures — they went first. Some of the routines for parsing text — the earliest parts of the program — were inefficient and looking at them with fresh eyes I was able to shorten them. Then, other commands in the language that either were duplicative or unlikely to be used were excised. I met the initial goal of finding memory, but equally as important the program was smaller, faster and more elegant. It imposed a way of thinking on the design that required a focus on what was essential.
Over the years, the capabilities of the computers we use have increased exponentially — not just Moore’s Law but storage, memory and tools. The result is that it is easier to create software than at any time previously. Developers rarely worry about memory use and are less concerned with performance. The proliferation of “drag-and-drop” development tools makes adding features easier. The creativity, discipline and focus that a scarcity of resources required is largely lost.
As we see the product of that everyday: How many applications do we use that are festooned with barely-used buttons? How many have features implemented in multiple ways in multiple locations (my favorite is that cut, copy and paste have menu options, buttons and keyboard shortcuts) so users can stumble on to them? How many bury their core functionality (creating a document, taking a picture) beneath layers of templates and formats? As scarcity disappeared, applications became more complex, slower and more difficult to use for their essential tasks.
But scarcity is important as a reductive tool. Constraints in developing software require us to think about what users really need, to develop workflows that are simple and easy to understand. That the features are necessary and not decoration or filling out a checklist. From a coding standpoint, it removes bloat, improves supportability, and drives better performance. It also stimulates creativity. The most popular applications and services today — from messaging to search to social media — are minimalist. Twitter is 140 characters and that forces people to write for the medium and to distill ideas into that space. iOS devices created an ecosystem for apps that typically do one thing. No one is writing an ERP system for the iPad.
As we develop software and services, no matter what business or industry, focus is essential. In an age of technological plenty, there is still great power in scarcity.
