Yes, But What Have You Done?

However, I think the programming world has now oscillated to far in the other direction. There seems to be a widespread perception that having a 5 minute discussion, hacking some shit out, and releasing it is the best way to do things.

The "fuck planning, just ship it" dogma is just as perilous as the "don't ship it until it's ready, even if that means it will take years" dogma.

Instead, try to ask yourself the following questions before you hit the "deploy" button:

- Will I be embarrassed by the quality of this software?

- In user tests, has it shown itself to be useful enough?

- In user tests, has it shown itself to be confusing?

- Will future features be undermined by releasing this version? (For example, will the UI have to change dramatically to add certain must-have features I have yet to implement?)

As is the case in most things, the best advice can be summed up in one word: think.

"I believe there's a healthy balance all programmers need to establish, somewhere between...

1. Locking yourself away in a private office and having an intimate dialog with a compiler about your program.

2. Getting out in public and having an open dialog with other human beings about your program."

...but I'm not really sure I see the point of the rest of it. Jeff points out that most programmers are introverts (which I have my doubts about, but that's a different matter) and that #1 is no problem. So then why is he spending most of his time talking about upping the amount of time we spend on #1?

Personally, I'm of the opinion that we as programmers do too much. It's fashionable to complain about people who talk and think more than they do, but we forget that it's also important to take time to reflect on what we've done so we can learn to do it better. Whether that be in the form of group discussion or introspection is another matter, but the moral of the story is not to do too much.

1. someone else has already done it. 2. you end up doing it poorly. 3. you end up wasting time on something nobody cares about. 4. you could have been doing something else.

In comparison to shooting at random, when designing you still don't know if you're going to hit the target but you've at least made it clear what and where you think the target is.

Further, design and planning is a courtesy to the users. If you're churning out prototypes and basically shooting at random then you have effectively demoted your potential users into mere filters to help you see what will hit the wall and what will not.

I don't mean to defend waterfall design or any of that ancient crap. You can't design software like that but you must design it somehow.

Prototyping—seeing yourself what works and thinking about what would Joe or Jane want to use the software for—is a great way to design. But prototypes aren't real products. They're not even eggs of real products: prototypes are really meant to be thrown away.

It is not imperative to spend years with design committees just as you don't have to "do it fucking now" either. Release something small but make sure it's something you've truly designed. If you just throw anything that merely compiles or runs onto the market then "I'll fucking leave now" (and won't come back).

"3. Getting out in public and having an open dialog with other human beings about something that does NOT involve programming."

To avoid burnt out that is.

Take heed of this, Hacker News. Nothing annoys a real entrepreneur more than a wantrepreneur pundit.