Dan Grover

← Back to Blog

July 16, 2013

Code and Creative Destruction

“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 know how silly it is to feel so emotional about something so common. There are tons of bigger projects that didn't go anywhere for even dumber 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.

opendoc stickerAlmost all the products the buttons advertise are delightfully obsolete. I remember a lot of them from my childhood. 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.

hypercard buttonSome of these technologies had a great run, others were stillborn. Some of them ended they were bad and actually deserved to die, or because they became evolutionary dead ends. But some of them only met their bitter end due to time and chance — big macroeconomic events, running out of funding, bad marketing, unscrupulous competitors, who knows. Some of these failed products found spiritual successors in later products, while others really 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 treated like civil engineering, it's when 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. It's one thing if your job actually is building compilers or theorem provers, but most jobs in the field consist of gluing together different APIs and dealing with meaningless, changing technicalities that only eventually add up to something substantive. But some carry about writing some unimportant internal framework or CRUD app as it's the first and last time such a thing will ever need to be coded.

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?

woody allen

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. Caring less isn't a solution, or really an option. A lot of us in the industry are the type that care too much about the thing they're working on, whether it deserves it or not. And the attachment and obsession that can create such heartbreak when projects don't go well is the same that enables them to succeed.

Some, of course, exit the industry entirely. I've had co-workers who fantasized about quitting their web development jobs and becoming carpenters, building bespoke cabinets and tables. 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 in the field 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". Hamming 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 more broadly and liberally, in such a way that some random act of economics or politics can't just waltz in and kill them one day.

It's easy to forget that we live in an amazing time. The reason for all these problems in our industry — the wasted effort, the imprecision of our language around it, the fragility and limitations of our technologies — is because our field is so new that even those at its center don't fully understand it yet. The computer revolution is still ongoing and we're only at the beginning of the "information age." Even today, huge swaths of the economy have not been transformed much by it. It's all still up in the air.

Every new software product is not only a guess at what might be successful but also a subtle statement on how people ought to interact with their information and each other. The good part is that we have an enviable power to shape the world. The bad part is that sometimes we have to toss out some perfectly good work, either because we missed the mark, or just 'cause.

But 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, will 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.

WHAT DO YOU THINK?

Have you got a different take on how to survive the fickle nature of the software industry? Reach out by email or Twitter and tell me what it is!

© 2013 Dan Grover. All rights reserved.