Tag Archives: sifter

Focusing on the wrong things

“Great post from Garrett Dimon”:http://garrettdimon.com/post/6724266888/my-biggest-mistake, on his biggest mistake building the bug-tracker Sifter:

“I got bogged down watching our bottom-line even though we’ve always been comfortably profitable. I worried about preventing fraud even though the only instance we ever encountered only cost us $200. I constantly worried that Sifter could go down at any moment even though we’ve had 99.96% uptime since launch. […] All of these little things were distracting me from the work that really mattered.”

For a small company, focusing on the wrong things will make or break a product. I’m guilty of the same thing. I sat on “Tweetmarks”:http://tweetmarks.net/ for 6 months without launching it because I was worried about how to pay for hosting and how to get developers involved.

Sometimes there’s no obvious solution until you ship. Eventually it becomes easier to know when to be patient — to solve a problem right the first time — and when it’s needless worrying over something that may or may not even happen. And as 37signals says: “decisions are temporary”:http://gettingreal.37signals.com/ch06_Done.php anyway.

Wil Shipley on bugs

From a “Wil Shipley post”:http://wilshipley.com/blog/2008/07/pimp-my-code-part-15-greatest-bug-of.html a few months ago:

“Software is written by humans. Humans get tired. Humans become discouraged. They aren’t perfect beings. As developers, we want to pretend this isn’t so, that our software springs from our head whole and immaculate like the goddess Athena. Customers don’t want to hear us admit that we fail.

“The measure of a man cannot be whether he ever makes mistakes, because he will make mistakes. It’s what he does in response to his mistakes. The same is true of companies.”

I’ve been thinking about mistakes and bugs as I beta test “Sifter”:http://www.sifterapp.com/. Since it’s not ready for launch yet I won’t comment on it specifically, except to say that despite many bug systems becoming very mature (in some cases, too mature) every developer still has a different set of needs. There will always be a new bug system promising to fix all your problems, and for many of us we have to keep reminding ourselves not to code our own. Been there done that.