“Abe said something interesting. He said that because everyone's so poor these days, the '90s will be a decade with no architectural legacy or style... He said that code is the architecture of the '90s.”
- Doug Coupland, writing in Microserfs
”When it comes to software, nobody expects the code to last, and the time you invested in making it work perfectly and defect-free doesn't often have a lot of correlation with the value it has to its user.”
- Esther Schindler, in The 100-Year Software Application
I was feeling miffed a few months ago because a product I was managing at a startup got cancelled just as it was ready to ship. The company made a big strategy change and ten months' hard work from my team went down the drain. I went from leading a high-profile project that was going to make a big difference to feeling like the red-headed stepchild.
Whenever something like this happens, it gets me thinking about how quickly most of the things I’ve worked on have become obsolete. Everything from one-off tools I worked on as an intern in college, to more successful pursuits like apps or businesses that I've sold. It's all gone down the drain eventually.
THEN LEAF SUBSIDES TO LEAF, SO EDEN SANK TO GRIEF
Rationally, I see how silly it is to feel so emotional about something so routine in our industry. And it's easy to see how many much-smarter people worked on far bigger projects than my team's that went nowhere for even dumber and more tragic reasons.
There's a wonderful hallway towards the end of the Computer History Museum in Mountain View filled with old buttons once given out at trade shows.
Almost all the products the buttons advertise are delightfully obsolete. I remember a lot of them from the computer magazines I read as a kid. HyperCard. eWorld. Newton. Aldus PageMaker. OpenDoc. Atari. IBM PCjr. Netscape Navigator. BeOS. Not to mention every manner of compiler and database tool. If you're curious, you can find them in the museum's catalog.
Some of these technologies had a great run, others were stillborn. Some of them were ended because they deserved it, or because they became evolutionary dead ends. But some only met their bitter end due to time and chance --- larger macroeconomic events, running out of funding, bad marketing, unscrupulous competitors, who knows. Some of these failed products found spiritual successors in later efforts, while others truly did drop off the face of the earth.
But reminding myself of the storied history of my industry (or that old passage from Ecclesiastes) doesn't ever make me feel better or any more in control. It's still hard to reconcile the passion and obsession that creating new things requires with their inevitable destruction or obsolescence. If you take this line of thought too long, it's easy to slide into nihilism. When I catch myself there, it makes me feel like Woody Allen's character in Annie Hall contemplating the expansion of the universe.
HOW SOFTWARE GETS MADE
I think we set ourselves up for disappointment with the language we use around software. We think of ourselves as builders, engineers, architects, as if we expect each line of code to be as lasting as the beams supporting the Golden Gate Bridge. Never mind that the Golden Gate Bridge is constantly being repainted and having bolts replaced.
When software projects aren’t spoken of like civil engineering, it’s made far more academic than it needs to be, as we try to wring some sort of mathematical purity out of the most pedestrian tasks. There are those whose daily work brings them up against the limits of knowledge — people who invent new compilers, theorem provers, or machine learning algorithms. But work for 99% of engineers, however highly trained, consists of gluing together different APIs and juggling ever-changing piddling implementation details. Yet some, stuck with building some internal tool or CRUD app, find the only way to weather this drudgery is to elevate the task, at least in their own minds, into something more abstract, higher-order, and academic.
Either way, we're led to fetishize code, sometimes in the face of more important things. Often we suffer under the illusion that the valuable thing produced in shipping a product is the code, when it might actually be an understanding of the problem domain, progress on design conundrums, or even customer feedback.
The reason many engineers and designers develop this perspective is that their jobs lull them into over-specializing. Some jobs can take well-rounded people and make them less capable. In many organizations, people who straddle the line between technical and non-technical quickly find themselves having to take a side. The result is that after too long in the wrong company, you can find yourself being molded into what's useful for the organization and not necessarily for you (or for the world).
WHY AND HOW TO CARE
But as long as there is work to be done in software projects, someone will have to do it. So what's the right attitude?
Some I’ve worked with can’t ship something they’re not proud of or excited about. And others react to everything from a minor request to a show-stopping bug with the detachment of an emergency room triage nurse at the end of their shift. Sure, if you’re starting a company, the buck stops with you and you've got a lot of things to think and worry about. But if you’re just a working chump, what good is all this naval-gazing? Shouldn’t it be enough to get paid a bunch and get to go home at the end of the day?
For whatever reason, I've never been able take such a pragmatic tack. I'll always be that neurotic Woody Allen character, no matter how long I live on the west coast, whether I am independent or working for others. Detaching has never felt like an option. Many of us in this industry are wired to care too much about the thing they're making, whether it deserves it or not. The attachment and obsession that can create such heartbreak when projects fizzle is the very same that grants them any chance of transcendent success.
Some, of course, do choose to exit the industry entirely. I've had co-workers who fantasized about quitting their design or engineering jobs and becoming, say, carpenters, building bespoke cabinets and tables (and a couple that have actually done it.)
But there's got to be a way to stay in the game, not get splinters, and still not feel like you're wasting time.
PICKING THE RIGHT STAR TO HITCH YOUR WAGON TO
One possible answer, then, might be to only work on really important, earth-shattering things. There are plenty of talks by famous people extolling this perspective.
Bret Victor has a famous talk called Inventing on Principle, in which he argues that engineers and inventors ought to base their lifes' work around some crisply-defined "principle." I have to confess that, despite my admiration for Victor, I've never been terribly inspired by that talk. I know what kinds of ideas make me excited, but I couldn't, even at gunpoint, distill those into "principles."
A professor I had once encouraged us to read through the Richard Hamming talk on "You and Your Research", where he asks the question "What is the most important problem in your field and why aren't you solving it?" But I've always found that message intimidatingly high-minded as well.
When you listen to these sort of people, you feel like you ought to live like some sort of Randian hero. But I don't think projects need to be that important or dignified to deserve time -- they just need to be defined broadly and liberally enough, such that some chance act of economics or politics can't spell their sudden death.
It seems like whether an individual product or company fails or succeeds, it ripples out for a couple of decades. You don't have to look far to see that some of the most admired and successful people in the software industry have spent their entire lives chasing the same few ideas (and in some cases literally building the same product ad infinitum). It's tempting to view shipping an individual product as a once-in-a-lifetime shot, but the best ideas have a way of coming back.
Consider Dennis Crowley. Before Foursquare, he started Dodgeball (which relied on text messages), and before that, his work at NYU explored bridging the physical and digital worlds.Or take Ray Ozzie. This profile in WIRED traces his career all the way back to his work at the University of Illinois on a system called Plato, which begat Lotus Notes, which begat Groove, the real-time collaboration app that became part of Microsoft Office.
When I was building music software, I occasionally ran into Michael Good, the inventor of MusicXML, an open standard for digital sheet music. I was fascinated to learn that his work with music standards began in the late 1970's when he helped create the first version of cSound at MIT. He went on to work on all sorts of things in his career, but finally started a company to address once and for all the intractable data interchange problem that has caused endless frustration to anybody using computers for music. His company, Recordare, last year got acquired by a recently reorganized MakeMusic, the developers of Finale. While music software was only a brief flirtation for me, it was a lifelong obsession for him.
These people did not fight any holy crusade for their principles and, despite their accomplishments, may not be remembered by history (except perhaps to be immortalized by their old buttons and bumper stickers in a hallway in Mountain View).
But they all managed to encounter a couple good ideas that were intriguing enough to follow through the years, across countless platforms, codebases, products, and institutions. They found motifs that could not only bear continued repetition but deserved it.
If there's any way to last in this racket, this has got to be it. Otherwise, I might as well start looking at table saws.