A beautiful collection of the evolution of user interfaces, including some of the most iconic computers like ENIAC and the inaugural Apple I. It's almost scary how much of the post 2000 innovation in user interfaces seem to originate from, or at least have been commoditized, by Apple.
May 18, 2012 | Permalink →
I previously voiced my strong belief that designing a good entry point for an open source project is an essential requirement for any proper open source project. The guys at GitHub has done very well in providing a platform for "the average Joe" to make such an entry point, but a few days ago, they moved the bar up an order of magnitude with their work on the new Git home page.
While the home page in general is stunningly beautiful in a somewhat minimalistic way, it's the emphasis on documentation that really sets this apart from anything else out there. Getting started with Git is easy these days — so many tutorials, screen casts and books cover the subject. But, finding information about a corner of what is truly an amazingly powerful tool often leads you down a black hole of nonsensical Google search results before you find the simple answer. The work on the new site clearly shows great understanding of this problem in more than one way.
The documentation section of the site is generally just brilliantly structured and clearly built for users, and the search bar in the upper right corner provides super snappy access to reference documentation for single commands:
While search isn't by any means a revolution, what is truly a stroke of brilliance is the GitHub inspired versioning drop down available when reading about a specific command:
This is extremely useful when mocking around on systems with different git versions, but to be honest, the scenario where you're working on such an outdated system seems relatively unlikely these days, especially with DVCS tools. Imagine however this applied to the documentation for your favorite libraries, frameworks etc. A properly versioned documentation section would truly enhance the usefulness of so many documentation sites where you otherwise have to read very carefully to make sure that you're reading the documentation for just the right version, something that'll easily bite you in the ass when working with unstable APIs.
So, there you have it. The GitHub guys have outdone themselves once again and set the bar for the rest of the open source projects out there so much higher than it previously was. Better get to work!
May 9, 2012 | Permalink →
Tom Blomfield, one of the founders of GoCardless, wrote an interesting piece on testing. His primary argument is that you should not write testing code until you've figured out where you're going with your product in very early stage startups:
The particular situation I have in mind is the ultra early-stage startup struggling to find traction. The number one priority in this situation is not to write beautiful code or solve hard technical problems in innovative ways; it’s to work out what people people want. You do this by iterating quickly & launching early [...]
While there definitely is some merit to this statement, I'm not sure I agree with it in its entirety. The biggest problem is that he seems to suggest, that startups in their early stages have no clue where they're headed; something I really haven't encountered at a scale where you could argue against doing good work. When people decide to do a startup, they generally tend to have a really strong opinion on what they want -- otherwise, how could they ever successfully build it?
While the above is more a discussion of the ridicule that is the term "entrepreneur" these days, the following statement from later in the article is just downright wrong in my opinion:
You’ll accumulate buckets of technical debt, but it’s generally ok. If you don’t find traction or “product-market-fit”, you declare bankruptcy on that technical debt and just move on to the next iteration.
Once you’ve found traction, you’ll likely need to re-write your codebase, but that’s ok as well. At this point, you’ll have a much clearer idea of what the product actually does, so writing specs should be much simpler.
First of all, technical debt is not just something you shake off. If you get that illusive "traction" you can be damn sure you'll be heads down trying to just keep whatever you're building afloat while you're growing. I know of even well funded startups with a considerable staff that still drag around 4-5 year old technical debt, so, really, technical debt doesn't just magically disappear when your "product-market-fit" comes along one day and knocks on the door. Even those companies who decide to put their heads down and staff up to rid that debt often wind up spending a few years doing so completely. Technical debt is not to be taken lightly.
Second of all, I think all of this is besides the point. When you're a very early stage startup, your greatest assets are your first customers. Treat them well, and you'll have the best kind of marketing on your hand that you can imagine. But, treating people well doesn't only mean sending them a personal e-mail every once in a while, although a lot of the business kids writing about startups will allude to this. In the web world, by far the most important thing, even when you're an early stage startup, is to deliver a solid piece of software. If you're iterating a lot, chances are that things are going to break, if you don't test them, and if things constantly break, you'll wind up losing those ever so important first customers. Oh, and what about scenarios like when Dropbox left user accounts open for hours because of a bug? That's not only going to lose you customers but also a heck of a lot more than that, most notably your credibility, whatever it may be worth at this stage.
In my opinion, there's no argument for writing cowboy code at any point in your startup's life. Marketing people just starting out don't intentionally halfarse their way through their job, so why should you?
May 4, 2012 | Permalink →
I have seen many stupid comments, blog posts and talks come from the people employed in pure venture cases, ie. people burning venture capital with no intent of building a sustainable business, but I have to say that Richard White of uservoice's post "Revenue could be fatal: 3 reasons your startup should consider waiting" tops them all:
... but there's also a fundamental misunderstanding of why revenue isn't important, and may in fact be harmful, for early-stage companies like Instagram.
All of White's arguments rely on the same premise; startups have no other purpose in life than to get a lot of users and then get swooped off the table by a lucky lottery draw. This is made abundantly clear by his implicit definition of startups generating substantial revenue, "the walking dead," as the worst case outcome of a startup arguing that "entrepreneurs can't walk away from them to focus on ideas with more upside and VCs can't write them off." Seriously!? Building a successful company that makes money is worse than failing and dropping investors' hard earned money on the floor so that you can move on to your next billion dollar idea!?
Let's be clear here: the purpose of doing business is to make money. It always has been, and it always will be. We can't just go around trading fictive goods and values forever (remember the last time we got stuck in that rut? Boom!) so revenue is every bit as relevant now as it was 100 years ago, and it will remain the same for the next 100 years, even if the currency changes. Sure, there are a lucky few who draw that winning lottery ticket and get acquired by the "big guys," and I applaud them for having risked it all, but for every lucky guy, there's a hundred fuckups (try looking up a list of Instagram competitors) which is simply just someone's money down the drain.
I am at a loss trying to understand how anyone can even begin to argue that this is a sane way to run a business. I'm guessing the illusive "up side" is what drives these people's thoughts in their hunt for their first batch of big exit capital -- the Lottery Mindset as Marco Arment so well describes it in his podcast -- but I just don't see any way in which this can be justified as a grounds for doing business.
If you're still not convinced by the merits of making money, or perhaps White's post has scared you into thinking that you'll never get that Facebook exit, let me round off with a few ways in which you and your business can benefit from making money:
May 1, 2012 | Permalink →
If you don't already read The Daily WTF religiously, you're missing out. Yesterday's WTF was however way beyond anything that I have ever seen before, and it's had Steffen and I chuckling for a good hour now. I'll leave this snippet as a teaser (ignore the obvious spelling mistake and enjoy the assertions made in this code — by the way, this is version 15.1)
'Establish p_mode to define correct perimeter
If p_mode = "" Then
p_mode.Replace("", "No perimeter was passed through")
Else
p_mode = p_mode
End If
If p_mode = "No perimeter was passed through" Then
p_mode = ""
God, I wish there was a man page for this method!
April 17, 2012 | Permalink →