The Developer’s Dilemma

People always like to quip that “real artists ship,” as a quick one-liner I guess that’s pretty good, but as with everything else… only sorta true. Anybody familiar with creativity has to admit that an end result of any quality usually requires a great deal of quantity in the background. Photographers will take hundreds of pictures in the process of producing tens of photos. Films emerge from hours worth of additional footage thrown in the waste bin. Graphic Designers build copious numbers of mockups to produce a final design.

We developers are in the idea business too and, although I feel wholly unqualified to say this, the good developers are the ones with lots of ideas. In my experience as a mediocre programmer I spend a lot of my time hounded by ideas of my own creation.

I found this great passage in an article by Richard P. Gabriel:

John’s world is a world of ideas, a world in which ideas don’t belong to anyone, and when an idea is wrong, just the idea – not the person – is wrong. A world in which ideas are like young birds, and we catch them and proudly show them to our friends. The bird’s beauty and the hunter’s are distinct.

[…]

Some people won’t show you the birds they’ve caught until they are sure, certain, positive that they – the birds, or themselves – are gorgeous, or rare, or remarkable. When your mind can separate yourself from your bird, you will share it sooner, and the beauty of the bird will be sooner enjoyed. And what is a bird but for being enjoyed?

Every creative would love to claim a monopoly on divine inspiration, but since we can never quite manage that we settle for just hiding away all those half-finished, not quite thought-through, potentially embarrassing ideas of ours – and it’s a really nasty habit.

For developers, we have trouble kicking things out of out our ~/Projects folder and sharing them with others because they’re “just not done yet.” Doneness is a dangerous idea – especially for perfectionists. It is always so tempting to keep polishing this or that project until you can really say it is done. Or worse, putting something pretty good to the side and promising to come back to it later to finish it off.

I’ve without a doubt fallen into that trap, granted I’ll make an argument for school getting in the way, but the truth is I’ve been sitting on a whole lot of “not done yet” projects for no great reason at all. Now that I’m nearly out of school, with new-found time on my hands, I’m resolving to drag them out of the closet, give them the once-over and throw them out for others to have – done or not.

3 Responses to “The Developer’s Dilemma”

  1. I think one of the reasons why people are afraid to demonstrate works in progress is because then all one gets is feedback about what is broken, and this detracts from making progress on the core valuable features and design aspects of the software. When you can ship a completed project, you won’t get user reports about misaligned text or some graphical glitch, because you’ve fixed all of those, they were obvious anyway. The valuable feedback is about some real core design issue, or usability problem.

    That said, I wonder if the modern uses of “beta” in reference to software end up confusing people too. Sometimes a beta is pretty much ready to ship, just searching for bugs, whereas other people will release a beta that is hardly more than an idea. Just letting people know what you’re up to is half the battle. I think many times this is solved by putting up a public SVN repo, people can see what you’re doing, and also see its a work in progress.

    -Joey

  2. I think that for most developers, it’s not a matter of continuously polishing projects, but being over-ambitious at the planning stage. It’s too easy to think “this doesn’t have enough features to be competitive” and end up 6 months later with a complex codebase filled with stub methods and half finished features.

  3. Matt Ronge says:

    One thing about shipping early and often is it forces you to work on what is most important for the app. It’s like iterations, and it keeps you focused, and provides early feedback in case you’re headed in the wrong direction, or someone has an idea you’ve never thought of.

    Or atleast that’s the idea :) I too have fallen into the trap of wanting everything to be perfect before releasing, here’s to releasing and getting some of those projects out into the wild.

Leave a Reply