Techcrunch has been on the inflection point of "mattering" to the wider public, which scares the life out of me!

Rule #1 -- Pick good cofounders. I picked no cofounders, based largely on the fact that that I couldn't think of anyone who would be interested in joining me who wouldn't dramatically lower the average founder quality. (Ok, that's being a bit facetious -- but I'm working in an area where domain knowledge is extremely important, so there are lots of wonderfully talented people who would be utterly useless to me as cofounders.)

Rule #2 -- Launch fast; and Rule #3 -- Let your idea evolve. I started working on tarsnap in September 2006, and I didn't open tarsnap to the public until November 2008. Over that time I ironed out some technical details behind the scenes, but the largest change in my idea was going from planning to charge $0.25/GB to actually charging $0.30/GB. Since then, I've listened to my users and occasionally added an unplanned-for feature because of a request (or more often, several requests for the same thing from different people); but most of the ways that tarsnap has deviated from my original plan have simply been in the ordering of when I implemented which features. The vision behind tarsnap, from 2.5 years ago -- an online snapshotted backup service with a tar front-end, a heavy emphasis on security, and a linear pricing model -- hasn't changed at all.

Rule #10 -- Avoid distractions. I've remained as FreeBSD Security Officer while working on tarsnap, and I don't regret it in the slightest. Yes, it has taken time away from tarsnap on occasion; however, it has also allowed me to further enhance my domain knowledge, and has brought many people to tarsnap (one person recently described tarsnap as being a backup system with "a good pedigree", which I'm presuming refers to my open source security background).

Now, for all that I've broken these rules without regrets, I still think that they're good rules -- in most cases. But I think there should be a Rule #0: Realize that there are always exceptions, and understand why these rules are usually correct instead of applying them blindly.

Probably because his comment isn't interesting, isn't relevant, and doesn't contribute to discussion. There are all kinds of true but uninteresting comments one can make, but making them shouldn't be encouraged.

Edit: I'm sorry if that sounds harsh, but actively discouraging uninteresting comments is what keeps the signal:noise ratio high here.

Enterprise Applications are built by committee. The committee's job is to put as many bullet points on paper as possible. The more bullet points they've put on paper, the more successful the committee was. The more complicated and long the documentation is, the more work the committee had to do and the more its people should be paid for being able to envision and document a system that is so complicated - without regard for whether that system had to be complicated or not.

Requirements get created for cases that no one knows exist or not. Partly this is because enterprise systems are sometimes thought to be write-once, run for a decade or so rather than systems that will see agile revisions. But partly it's also because, again, it's easier to talk about out of left field problems that will never occur than to actually tackle real problems.

Decisions are made random and arbitrary - but because those decisions are documented, they're fine. So, you want a way of storing that a bank account is closed? Well, we could just have a closed flag on the account when the customer closed it -OR- we could make the account no longer have a relationship to a person, have a zero balance in it and have it be more than 3 months since any activity happened in the account. Yep, that works. Then when a programmer says, but that's not a good way to do that, the question gets asked: why can't it be done that way?

That's the heart of the problem: why can't it be done that way? Of course it can be done that way. It just shouldn't. It's a terrible idea that only an idiotic committee would come up with because the more complicated the solution, clearly the harder the problem (and therefore the more money and adulation they should be paid). If it's simple, they're just doing their work, but if it's hard and requires an overly complicated solution, they deserve praise!

The worst part is that in all of those meetings, you constantly hear "we're building a 90% system" referring, of course, to not tackling outlying cases that may not come up. The problem is that, in the case of enterprise systems, it means tackling every outlying case imaginable while leaving the most common use cases with a terrible interface and sub-par reliability. And the worst part is that most of the outlying cases aren't imaginable so you haven't even solved that.

The problem is what gets rewarded in an enterprise environment and how non-techies see software. Something that is simple, reliable and gets the job done must be solving a really simple problem and took little work, right? In fact, I'm sure many of us have been approached and offered a few hundred dollars to create something just like (MySpace|eBay|Amazon|etc.) because they make the solution seem easy. So, the incentive is not to make something elegant, but to make something that shows exactly how difficult the problem really is - in fact, more difficult than the problem really is.

Likewise, the more features you can write down on a piece of paper, the more impressed your boss' boss will be with what you've been able to accomplish. "Elegant user-interface and code" doesn't take up enough space.

And we're left with crap.

Quality is a vector, not a scalar. What's the average of Steve Jobs and Steve Wozniak? I don't think that's a meaningful question. But the vector sum of their skills was a startup with amazing technical and artistic skill, product focus, business aspirations, charisma, and salesmanship.

And I'd like to help you become ramen profitable, so let me demonstrate what I mean by putting on my Steve Jobs hat [1] and telling you a story.

I'm in the market for something like tarsnap, so i was very excited to hear about it, for the first time, in this random HN comment 23 days ago:

http://news.ycombinator.com/item?id=458793

...because the product sounds great. I may sign up any day now. But I distinctly remember that, after reading this enthusiastic blurb, I spent several minutes trying to figure out if tarsnap had any kind of decent security model. I remember this because I literally laughed out loud when I finally managed to figure out the answer, after clicking through more than one link and reading a few blog posts -- tarsnap was designed by a cryptographer! Indeed, now (but only now) I learn that it's even better than that: You're the FreeBSD Security Officer, which presumably involves a great deal of practical expertise in reviewing and fixing insecure software.

Why isn't this information on the tarsnap homepage, next to a "buy it now" button?

---

[1] It's not nice to go all Steve Jobs on someone without being asked, so I'm deliberately toning down my Jobs impression. This is like a 2 on the Steve Jobs bluntness scale.

Go away, TechCrunch.

If women between the ages of 21 and 25 are interested in (and pursued by) men between the ages of 21 and 35+, while men between 21 and 25 are limited to women who are roughly the same age, then men will face a very difficult dating "market" in their early 20s, and women will experience a favorable one. As men and women age, the inevitable symmetry switches the situation - women between 35 and 40 are now competing for men who are pursuing women between the ages of, say, 25 and 40.

This is something to keep in mind when you hear that the dating world is unfair to women over 35. It's "unfair" to men too, just earlier in life.

Even so there were several things that seemed new to me. Let me check.

I never quite realized till now that a version 1.0 was (or could be) nothing more than a pretext.

The rectangle metaphor and the point about one side being easier to change is new; I only thought of that a couple weeks ago.

The greater difficulty of lying to yourself when expanding userwise is something I don't think I've written about.

I don't think I've mentioned that founders' own standards for customer service are artificially low, or that customer service is mostly a way of studying users.

I don't think I realized before that being cheap was interchangeable with iterating, or mentioned that a culture of cheapness keeps companies young.

I don't think I've written about how paying distractions are so much worse than other kinds, or that it's specifically because they work like interrupts.

I didn't realize till recently that the right metaphor for a deal was a background process.

And I definitely didn't realize till I'd actually written out the list which would be the most important one, or that it was involved in half the others.

Not that bad for an essay only 2.5 pages long.