Perfectionism

If I was as much of a perfectionist as some here would have me be, I would never get out the door in the morning, I’d be so busy scrubbing the floors of my apartment until they sparkle and shaving every ten minutes and removing lint from my clothing with masking tape, and by the time I finished that I’d have to shave again and take out the trash because there was masking tape in the trash and re-scrub the floor because when I took the trash out I might have tracked in dust. And then I’d have to shave again.

I could go insane with the web page behind the discussion board. First I could make it 110% xhtml 1.1 + CSS. Heck, why not xhtml 2.0 just to be extra addictive-personality-disordered. Then I could neatly format all the html code so it’s perfectly indented. But the html is generated by a script, and the script has to be indented correctly so that it’s perfect too, and a correctly indented ASP script does not, by defintion, produce correctly indented HTML. So I could write a filter that takes the output of the ASP script and reindents it so that if anybody does a View Source they would see neatly indented HTML and think I have great attention to detail. Then I would start to obsess about all the wasted bandwidth caused by meaningless whitespace in the HTML file, and I’d go back and forth in circles between compressed HTML and nicely laid out HTML, pausing only to shave.

I could spend the rest of my life perfecting the HTML behind every page on all of our sites, or I could do something that might actually benefit someone.

Perfectionism is a very dangerous quality in business and in life, because by being perfectionist about one thing you are, by definition, neglecting another. The three days I spent insuring that all icons in CityDesk 3.0 are displayed with perfect alpha-blended effects came at the price of having a web site where the descender of the “g” is not a hyperlink. And both are at the price of working on my next book, or writing another article for Joel on Software, or making CityDesk publish really big sites faster.

If you’re noticing a recurring theme, it’s that I never like to talk about whether or not to do X. The question should never be “X, yes or no?” As long as you have limited time and resources, you always have to look at the cost and the benefit of X. Questions should be “Is X worth the time” or “Will X or Y have a greater return on investment?”

Great Minds Think Alike
or, you can take the boy out of Microsoft but you can’t take Microsoft out of the boy

Raymond Chen: “In other words, in an error-code model, it is obvious when somebody failed to handle an error: They didn’t check the error code. But in an exception-throwing model, it is not obvious from looking at the code whether somebody handled the error, since the error is not explicit.” (c.f. Joel on Exceptions)

Larry Osterman: “I’m not saying that metrics are bad. They’re not. But basing people’s annual performance reviews on those metrics is a recipe for disaster.” (c.f. Joel on Measurement, Joel on Incentive Pay, Why FogBugz isn’t a crutch for HR, etc.)

By the way, have you noticed how everyone at Microsoft is a blogger now? Dave Winer has managed to successfully and almost single-handedly pull off the most incredible Fire and Motion coup in the history of the software industry. His endless evangelism of blogging now has every Microsoft employee spending more time working on their blogs than working on software development or even picking out polo shirts. Brilliant! And that fifth column thing with Scoble — there are no words! Bravo!

The Best Thing on Television, Ever

We just finished watching Season 1 of the BBC television series The Office on DVD during our lunchbreaks at Fog Creek. WOW! Incredibly funny, incredibly touching, and supernaturally realistic. But now I’m paranoid when nobody in the office laughs at my jokes. I’m an entertainer, first, really, then a boss. Also I’ll have to cut down on the army stories.

Hint to Americans: turn on the English subtitles and you’ll catch twice as many jokes.

Dogfood

The term “eating your own dogfood,” in the software industry, means using the code you’re developing for your own daily needs: basically, being a user as well as a developer, so the user empathy that is the hallmark of good software comes automatically.

This site is produced in CityDesk, and about half of my time is spent writing code for CityDesk, so it’s been my policy to edit Joel on Software using the current, debugging version of CityDesk running inside the debugger. The neat part is that if I’m writing a long essay for the site and the application crashes, I have a chance to debug it right there and then and in fact if I haven’t saved in a while I must debug it right there and then, otherwise I won’t be able to save my work.

Anyway, for the last couple of weeks, the development version of CityDesk has been using a new, smaller database schema (it’s mostly the same as the old schema but with some redundancies removed to make it better normalized) and the truth is I was a little bit scared to upgrade the Joel on Software database so I could publish. But dogfood we must eat, so here you go.

Interviews

Eric Lippert writes: “Dev candidates: if you’ve done any reading at all, you know that most of your interviews will involve writing some code on a whiteboard. A word of advice: writing code on whiteboards is HARD. Practice!” Good advice. I’m wondering if we should stop giving advice on interviewing… my guerrilla guide is so well read that my old trick of looking for people who write their }’s immediately after their {‘s doesn’t work any more. Everyone who interviews at Fog Creek always carefully does that now, and then they sort of look at me to make sure I noticed that they wrote their } immediately after their {. Tip: That’s not what I’m looking for any more.

Memetics and Email Viruses

Gary Cornell and I had an interesting conversation about how email viruses are getting cleverer and better written. It reminded me of Richard Dawkins and Oliver Goodenough (Nature, September 1, 1994) who realized that chain letters were a great example of the evolution of memes. Evolution requires:

1. A genetic code, such as DNA
2. Replication
3. Mutation
4. Natural Selection

In a chain letter, you have

1. The text of the letter itself
2. The letter requires you to copy it and send it to other people
3. When the letter is copied by hand, everyone makes slight mistakes and slight changes, either intentionally, because they think they are better, or unintentionally, by mistake.
4. The letters that work best at convincing people to copy them get copied the most and thus those memes survive the longest.

The same thing happens with email viruses. The ones with the best fake letters, e.g., the ones that persuade the most people to open the attachment, will survive and reproduce. The ones that aren’t very convincing die out. The next stage, which may have already happened, would be for the virus to modify a couple of words at random in the text of the message before sending it out. Instead of blasting a million people the same message, blast groups of 100 people the same message with a different random change. Eventually random mutation will improve the ability of these messages to survive and reproduce by fooling people into opening the attachment.

Software Marketing

I’ve said it before, and I’ll say it again … nobody knows more about marketing in the shrinkwrapped software industry than Rick Chapman, and the new fourth edition of his book is the only place you can go to find a complete encylopedia of just about everything there is to know about marketing software. There’s really nothing else that compares and if you’re trying to market software you really have to read this book.

Over the years and the editions Rick has added an awful lot of material, and a lot of it is starting to show its age. In particular a lot of the discussion of channel marketing may not be relevant: thanks to the Internet, plenty of software companies today are doing fine using 100% direct-to-customer without any traditional channel whatsoever. Don’t let that stop you from buying the book; it has plenty of useful data on Internet and direct sales, too. Before you try to sell software, you have to at least sit down and read this book cover to cover, if only to gain the humility to realize how much is involved in marketing.