Never mistake activity for achievement. ~ John Wooden
The software project that haunts me the most was a single-sign on implementation that I did for O’Reilly.
This project was handed to me, partially done, with the following instructions:
These three bugs need to be fixed. Do you think you can do them so that we can launch in two weeks?
The three bugs didn’t seem too hard, so I said yes. I think it takes some experience to recognize that there’s a huge red flag in that question.
I was answering, that, yes, I could complete those three things in short order. How would I know, having never looked at the project, whether those three things were sufficient for launch?
In the course of the next two weeks, three more unfinished things popped up and the launch date was pushed back two more weeks. Then more missing features and bugs were found. And again.
After three months of this I was racked with guilt over the missed launch dates. Although, nobody had ever asked me the explicit question, “How much work needs to be done before we can launch?”
I went home that weekend determined to figure out how to get the project on track. I was basically a junior programmer then and had no idea how to run a project. So I bought a book on project management, Rapid Development by Steve McConnell, and cracked it open.
The book opens with 36 Classic Mistakes Enumerated. I checked off 17 mistakes for the project and was hooked on the book for the rest of the weekend.
When I went to work on Monday, I hid out in an empty office on a different floor and spec’d the project for myself. According to my rough spec, the project had at least 180 function points and I had completed 90 over the last three months, leaving 90 more to do. Would we be launching in two weeks? Definitely not.
For a long time, this was the project I was most proud of. I used my spec to pull the project out of the weeds and onto a realistic schedule. The project got on track, a realistic launch date removed my late-project guilt, and the launch was a technical success.
My bosses loved my initiative. It also gave me a lot more work options: I got more respect at that job, I got opportunities to make bigger decisions, and that led to opportunities to work for some pretty cool startups.
Then one day I asked myself, “Why were we building a single sign-on system?”
Mixing some metaphors about nature and total ignorance, I had gotten out of the weeds only to see trees.
Years later when I could see the forest, I realized that my proud moment hadn’t accomplished anything (minor convenience for a small population of users, inconvenience/confusion for a big population of users).
The goal of the project was actually to allow for a second phase around business intelligence or some such thing. That never happened and I’m told now that the system is being phased out.
Being the richest man in the cemetery doesn’t matter to me. Going to bed at night saying we’ve done something wonderful, that’s what matters to me. ~ Steve Jobs
Ever since that realization, I’ve been working to figure out for myself how to maximize the impact of the work I do.
There’s a good discussion of what constitutes startup success over on Gabriel Weinberg’s blog (and the discussion is basically what prompted me to write). It goes over various scenarios for startups and tries to judge if they would be considered successful. Obviously a long running company that made millions of dollars for the founders and investors is a success. What about one that made a lot of users happy but didn’t make the investors any money? What about one that made everyone money in an acquisition but then was immediately shut down?
I just don’t think I could ever call my work successful unless people used it. I don’t want to be merely well paid. I don’t want to write great code that doesn’t get used.
There’s a logical argument to be made that taking part in a system that produces one Google and nine failures is a way to maximize your impact. But I couldn’t handle that unless I was working on Google. I don’t want to look back on 30 years of work and realize that only three of those years mattered. That means I care about consistency of impact as much as I do about the magnitude of impact.