Schrade.Blog

Things sure have been quiet around here...

As some of you may already know, I've left the relative safety of my job at Collaborative Drug Discovery to have another go at starting a company.

I'm currently working with a friend to once again create something out of nothing and bring yet another crazy idea into the world. Therefore, if you see me and I look like I just got finished working for 18 hours straight, please buy me a beer and put me to bed.

As for the new company, I'm not ready to talk about what we're doing yet, but I'm sure that I'll be writing about it here as it comes together.

I use Omnifocus everyday to track what I'm doing, and I love it, but there are tons of UI problems with it that drive me absolutely crazy. There's a good article about some of the failings of the interface design here (with a video showing some of them), but there's one interface decision that's been absolutely driving me nuts lately.

Look at this picture:

See anything wrong with it?

If you said, "There's no way to set the due date for a project to Tuesday without clicking the little arrow at the top left to go to next month" then you're right.

What a horrible failure of UI design. I end up up dealing with this at the end of every month, and everytime it's a pain in the ass. Compare it to the iCal day chooser:

See that? Much better. They just grey out the days in the upcoming month. (They even go above and beyond the call of duty and show two upcoming weeks.) This is what the Omnifocus date chooser should be.

Hopefully there will be an Omnifocus update soon that addresses most of the problems with the interface. I expect more at the price point ($89) that they've positioned it at.

You can't just ask customers what they want and then try to give that to them. By the time you get it built, they'll want something new. - Steve Jobs

I was at a networking event out here in the Valley a few weeks ago where a bunch of companies went up on stage and presented their companies to the audience. I'm fairly certain that at least one of them might have been interesting, but to tell you the truth, I don't really know because I didn't really pay attention to any of them.

I already knew about the ones that mattered and a quick glance at the program showed me that the others weren't worth listening to because they were me too clones of other start-ups.

After the presentations were over, a friend asked me what I though of them, to which I replied, "Don't know, didn't pay attention" and he responded, "yeah, but are you actively a hater like me yet?"

I think that I got his point, and that is that there are times lately where I just want to slap people when they tell me what their company is doing.

I know that innovating is one of the hardest things in the world to do, but lately, I've been disappointed in 99% of what I see. As far as I can tell, there seem to be two main reasons for this:

1. The first reason is because of what I call the "me too" start-up. For example, when I first moved to SF, Flickr was the big thing out here, so for a few months everyone seemed to have a crap photo sharing site. Then this changed to Youtube/crap video sites, Facebook Platform/crap widget sites, and on and on. Some degree of competition is a good thing, but it's all a little much. If you have a substantial improvement to an existing product then, by all means, go for it. However, if you're just doing a feature for feature copy of a competitor's website then, please, invest those resources in doing something else. Or at least don't try to pitch it to me as something new and exciting.

2. The second reason, and the one that bothers me more, is the "aim high, fall fast" start-up. This is the start-up that has lofty goals, and falls into the trap of selling them out to meet some sort of smaller and less interesting short term target. This is all too common (hell, I did it at my last start-up), and I think that a big part of it comes from the fact that it's so cheap to start a company now that sometime it's easy to forget just how hard you really have to work to make something great. These are the companies that VCs need to fund at their "aim high" stage to keep them from plummeting. Sure, they might have an idea that's way off in left field, but companies like that are usually the ones that grow into something huge and interesting.

So, I guess that I'm asking everyone out there for one thing, and that is to think bigger than we are right now. Think outside the box, don't water it down in the early stages or once a little revenue starts to trickle in the door.

When I run into you at a networking event, make me say "damn, that's a crazy idea, but it just might work" and when I run into you 6 months later don't make me shake my head at you because you've turned it into a clone of another idea.

Perhaps if we all start using our heads, the innovation will start flowing freely once again.

Yesterday, I finally got around to upgrading HAML in our Rails app to the newest stable version and the first thing that happened was that 20 completely unrelated specs broke.

Why, you may ask?

A monkey got into our code, that's why.

You see, Ruby allows you to redefine any method of any class on the fly (monkey patching) and it turns out that the old version of HAML had the following code in it:

  unless String.methods.include? 'old_comp'
  class String # :nodoc
    alias_method :old_comp, :<=>

    def <=>(other)
      if other.is_a? NilClass
        -1
      else
        old_comp(other)
      end
    end
  end

  class NilClass # :nodoc:
    include Comparable

    def <=>(other)
      other.nil? ? 0 : 1
    end
  end
end

This, in turn, snuck into our codebase in all sorts of little unexpected places. In one instance a test was comparing sorted Arrays of nils and returning true. Not good.

Luckily, in all of our cases this ended up being more of an irritant than anything else, but I can easily imagine any number of ways in which relying on the assumed behavior of these methods could have broken our app in any number of subtle and terrible ways.

So I'm only going to say this once:

Don't modify core Ruby functionality in your plugins or Rubygems.

You will break your users' codebase.

If you do modify core functionality you deserve to be slapped around by those around you.

If you weren't at Startup School this weekend or haven't watched DHH's speech yet, you should go check it out. It was entertaining and a good counter-point to much of the ridiculous talk that you hear out here in the Valley.

As I was watching it though, I had the same thought that I always seem to have when I hear someone from 37 Signals talk, and it came to me right when I saw the slide that said:

1. Great Application
2. Price
3. Profit!

If only it were that easy. The thing that these guys always leave out seems to be step 1.5:

Market the hell out of your product, and get a bunch of people to use it.

That step is really, really hard.

I bet that if you asked DHH if he thought that 37 Signals would be just as successful if he hadn't invented Rails, and without the flood of free publicity that that got them, and he answered truthfully, the answer would be "no".

There are probably all sorts of great applications out there that would help me out on a daily basis, but I have little to no time to try out most of them. I've tried out Basecamp though, simply because while learning Rails you hear again and again about how Rails was extracted from it.

Would I (or you) know anything about 37 Signals if it wasn't for Rails? Probably not.

Those guys do a great job of marketing themselves and getting things out in front of people, but just because you're having fun marketing your stuff, doesn't mean that marketing isn't work that you have to do.

If you think that you don't have to market your app, no matter how great it is, you're living in a world similar to the one that DHH had on one his final slides where he said:

500 * $40 = $125,000

That's right, an imaginary world.

The hard drive on Macbook Pro died again the yesterday, so I had it in to my friendly neighborhood Apple Store to replace it once again.

Luckily, I was fully backed up through Time Machine this time, and when I got my machine back last night (note to self: always go to the flagship Apple store for repairs, they get your machine back to you much faster than other Apple stores) and started it up, one of the new options during setup was "Restore from Time Machine Backup". I chose that option, plugged in my disk, and when I woke up this morning my machine was back in exactly the same state that it was the day before.

That's not all though, it appears as one of the unexpected side effects of doing this is to clear out all of the temporary and log files that have built up over the last year or so. I went from 18 gigs of free space to over 30 gigs of free space just by going through the restore process.

So now I'm thinking that I might do just do a full reinstall of OS X and restore from Time Machine a couple of times a year to repeat this process. So far I haven't seen any downsides. Everything that I use in a normal day seems to be working perfectly (and actually, some things are going faster, I'm assuming because whatever trail of temp files they create over time has been cleaned up). If your machine is running slow or is low on space, doing a reinstall and a restore might be worth a try.

I'm announcing today that I've decided to run for US Congress!

No, not really, but someone else named Kurt Schrader is.

This, however, is a blog about Ruby and internet startups.

Welcome.

Please read this book before continuing.

And if you live in Oregon, vote for that guy. He's got a name you can trust.

I converted my Subversion repository at work to a git repository recently, and today I had my first real "aha" moment.

I was working on a feature this morning when I realized that some code I checked in about an hour before had broken the build. In the old Subversion world, I would have needed to keep track of what I was changing to fix the bug, and then make sure to just check that in to ensure that none of my half-finished new feature got into the trunk.

Not anymore. Today I just did a:

git-stash

and it stashed away all of my changes in a temporary branch. Then I fixed the build, checked in my fix out main Subversion repo (using git-svn), and did a:

git-stash apply

to unroll my earlier changes back on top of the now fixed code. It's not the world's biggest saving of time, but it's one less thing that I needed to think about during development, and using git I'm seeing more and more little things that are starting to add up to a big change in the way I'm doing development.

Today's 10.5.2 update to Mac OS X seems to have solved my issue of losing wireless connectivity every half-hour and having to reboot to get it back. I was about ready to throw my laptop out of the window with this one. How was I supposed to get work done when the internet was constantly going away?

I wasn't sure how much more I could have taken before I just installed Linux on this box to get back to work.

So thank you Apple for saving my laptop. And thank you for not making me go through the pain of dealing with a dual-boot Linux box once again.

Both of my last two companies have been involved in the aggregation of large data sets.

At the company I co-founded, Ten Ton Labs, we collected and normalized music reviews from across the web to support our music search engine, Squishr.

Our original plan, however, was to collect all reviews, of anything and everything, and then build an application that analyzed and tracked various metrics from the data to find out how consumers felt about certain products. We scaled the idea back to focus on music to allow us to continue building the underlying review platform and to have an easier application to implement on top of it to prove it out.

At my current company, Collaborative Drug Discovery we collect huge amounts of data about experiments in the field of chemistry (there are about thirty million known chemical compounds) and allow people to search through the data in various ways, as well as add their own data. Our users can use our toolset to keep their data private, but search across the aggregated dataset.

Both of these companies have a lot in common. When I was at Ten Ton Labs, our music search engine held a huge amount of short-term value for us. It was the cool thing that we could show to investors to get them excited about the company, and it gave us attainable short-term goals to go after. CDD is very similar, we currently put most of our effort into our cheminformatics application that runs on top of our data, because it's what we sell to people and show to our investors.

Long term though, I don't think that our music search engine or the CDD cheminformatics app is really where most of our value lies.

It lies in the cloud.

A huge amount of value is created by building tools to make it easy to get data into the cloud, and to make it easy for people to process the data and get it back out in a manner that they're used to. Once you have those tools, especially if you're allowing people to build applications and communities on top of your data, you're creating real value.

You've created an app that people will come back to everyday to see what's new.

And you've created an ecosystem around your data that won't allow it to die. People will build tools to interact with it in ways that you never even thought of, and again, more value will be created because of it.

I think that building a platform for data like this, not just a one-off application, is where the opportunity for huge value creation eventually lies.