Gadgetopia

Here are two things that cut so many good ideas off at the knees. These two factors are the two biggest things that stop good ideas from getting implemented and make programmers pause when they should forge ahead.

1. The Urge to Generalize
Say you come up with an idea for a little transaction management system — a tracking app that follows a sales transaction from inception to closure. It works well for your company, but — you think — if I unleash this on the world, then it has to be able to handle other things, right?

I have to abstract the simple “Transaction Name” field away to be able to handle “Buyers” and “Sellers” in case someone wants to use it for third party brokerage, right? And what exactly constitutes a transaction? I need to have an object oriented “Attributes” sub-system to be able to handle any information they want to store, right? Etc. Etc.

Pretty quickly, you’ve decided that it’s just too much work to do all this stuff you just made up and imposed on yourself, so forget it.

I think programmers equate “The software doesn’t handle that” with “I can’t make it do that because I suck.” We never want to say no or have to admit that our software wasn’t designed to do everything. If our image editing program can’t also balance our checkbook, then we have somehow failed and it’s not worth releasing.

(In terms of content management, I’ve talked about the The Urge to Generalize here. For some reason, I discussed it in positive terms…)

2. The Fear of Expansion
So you get past the first hurdle with your little transaction management system, and you’re coding happily away. But then your mind starts to look down the road….

You think, well, I should put something in here so the user can indicate that an invoice was sent for payment. I mean, people don’t want to do double-entry, right? But then why can’t this system just generate the invoice….and track receipt of the payment…and display aggregate customer sales figures…etc.

Before you know it you (1) have mentally evolved your simple app into an accounting system, and (2) scared the crap out of yourself because there are apps like Peachtree and Quickbooks that do this better, and (3) thrown in the towel.

Why do we look at every app as always getting bigger? I appreciate ambition, but the problem with this is at the end of every development road is a bigger app that you’re going to run into and encroach at some point. Why can’t we stop three-quarters of the way down this road and just be happy with that? Do one thing and do it well. (Josh Clark has been very good at this, judging from the comments on this entry.)

These two things have killed millions of good ideas before they even got out of the starting gate. As programmers, we think too much, sometimes. Your app (1) doesn’t need to handle every possible scenario, (2) encompass every aspect of functionaity, and (3) continue evolving into a successfully bigger and bigger app.

If this little essay makes sense to you, read this one from Joel Spolsky. Same concept from a little different angle:

These are the people I call Architecture Astronauts. It’s very hard to get them to write code or design programs, because they won’t stop thinking about Architecture. They’re astronauts because they are above the oxygen level, I don’t know how they’re breathing. They tend to work for really big companies that can afford to have lots of unproductive people with really advanced degrees that don’t contribute to the bottom line.

The Functionality Astronauts are just as dangeous as the Architecture Astronauts.