Paul Graham is one of the more interesting personalities in the American startup scene today.
Recognizing some of the flaws inherent in the venture capital model as it relates to consumer internet startups, he launched YCombinator.
YCombinator bills itself as a “new kind of venture firm specializing in funding early stage startups.“
The model is quite simple – let young entrepreneurs with ideas for web startups apply for funding and, after a review process far less intensive than traditional venture capitalists apply, fund the ones that are appealing.
Entrepreneurs that receive funding from YCombinator get just about enough money to live a Top Ramen lifestyle for a few months ($5,000 per founder) as well as ‘valued-added‘ services such as mentoring and legal assistance. In exchange, YCombinator gets 2-10% of the new company (the median is reported as being 6%).
The purpose of YCombinator’s funding is to enable entrepreneurs to take their ideas from concept to some sort of reality (i.e. a working prototype) typically so that the next steps can be taken (i.e. follow-on funding from traditional angels or venture capitalists).
Frankly, as an entrepreneur myself, I’m not a fan of YCombinator’s model. Equity is the most expensive form of financing in the early stages of a company’s existence and giving up 2-10% of it for an amount under $20,000 makes no sense. In my opinion, any entrepreneur who does not have that amount of money to invest in himself and who is unable to raise it from family and friends probably should think twice about starting a new business.
Additionally, from an investor standpoint, I think the YCombinator model is weak. Not only does the amount of funding lend itself to feature-as-a-business ‘startups‘ with no real competitive barriers, it mostly appeals to young techies who may be talented and hungry but who lack the real world skills and experience that is usually conducive to success.
Again, my feeling is that any entrepreneur who can’t come up with a small amount of money on his own has already demonstrated that he’s less resourceful than he’ll need to be to run a bootstrapped businesses.
All of this aside, I sometimes read Paul Graham’s ‘essays‘ because they provide an interesting perspective that’s different from mine and a recent ‘essay‘ caught my attention. It’s entitled “The Other Half of Artists Ship” and in it, Graham talks about the cost of ‘checks.’
Graham is, of course, discussing checks as in ‘checks and balances‘ – the measures companies take to ensure that mistakes made in the past aren’t made in the future.
His primary thesis: checks are costly and harmful – usually far more costly and harmful than companies recognize. He provides multiple examples of how checks and balances can harm companies (and even entire economies).
In Graham’s opinion, companies that require their suppliers to validate their solvency, corporations that implement flawed purchase limits and associated approval processes and governments that over-restrict and over-regulate often find themselves paying more for their checks than those checks are designed to save.
He then goes on to argue that “the cost of checks may actually be increasing” because “software plays an increasingly important role in companies, and the people who write software are particularly harmed by checks.“
According to Graham, “programmers are unlike many types of workers in that the best ones actually prefer to work hard” and that this dynamic leads programmers to want to write more code. This is a naive generalization in my opinion (I’ve met my fair share of lazy programmers too).
In Graham’s estimation, the software development cycle is harmful to the best programmers.
He refers specifically to the formal release cycle – the process that governs the testing and ‘launch‘ of new code in any software development environment and argues that it’s a check that is far too costly.
Unfortunately, not having some sort of formal release cycle in which code is tested before being made public makes about as much sense as adding new parts to a commercial plane and flying it with passengers before you’ve thoroughly tested that everything is working properly.
A detailed discussion of why formal release cycles are an important part of running a legitimate technology company (especially when one actually provides software that people rely on and – gasp – pay for) is beyond the scope of the post. Hopefully it’s obvious.
What I do think is worth discussing is that in his ‘essay‘ on checks, Graham forgets to mention the most important checks of all – the ones you take to the bank and deposit.
Graham’s thesis is one-sided and places programmers at the center of the universe. To be sure, your programmers are extremely important. But technology is about solutions, not the people who implement them.
Good software (including web applications) is designed to be of value to its users in some fashion. This value is (hopefully) eventually translated into revenue.
Good software is not designed to be art in application form. Obviously, some applications look like they’re an attempt at abstract impressionist software, but the genesis for the best software is usually an answer to a simple question – wouldn’t it be useful if there was an application that could do x?
The best software is written not by self-fashioned programming Picassos but by programmers who are passionate about coming up with solutions to tough problems.
In Graham’s world, however, that’s not the case. He cites a Steve Jobs quote, “real artists ship” and states:
“For good programmers, one of the best things about working for a startup is that there are few checks on releases. In true startups, there are no external checks at all. If you have an idea for a new feature in the morning, you can write it and push it to the production servers before lunch. And when you can do that, you have more ideas.”
Graham argues that this is the closer to the way it should be at all companies.
I say – forget ‘new features.’ Forget ‘more ideas.’
I’d argue that more than half of the bloated, crappy software that once worked decently became bloated and crappy because some programmer got an ‘idea‘ for a ‘new feature.’ And then he got ‘more ideas‘ for ‘more new features.’ By the time you knew it, your accounting software was capable of navigating a satellite to the moon through an option in the Tools menu.
The bottom line is that if you have a piece of software that somebody actually uses is, getting an idea over dinner, writing the code in the morning and releasing it by lunch the next day is not a good idea. The best ideas are usually sourced from stakeholders and/or developed with their assistance (feedback, testing, etc.) – the user-centered design process. Worthwhile ideas are validated and implemented thoughtfully, not hashed out over a pizza-fueled 24-hour coding marathon.
The best features provide real value to users (not the programmers who are tasked with implementing them) and the result of providing value to users is as simple as it is appealing – earn more checks to deposit.
Given that YCombinator has probably funded more lightweight, feature-as-a-startups than anyone else, I’d venture a guess that Paul Graham knows more about writing checks than cashing them, more about creating features than developing solutions.
The bottom line is that, in a day in age where more and more of the startups you’re likely to hear about seem to be driven by hipster techies instead of profit-driven entrepreneurs out to trade solutions for cash, it’s easy to forget that the most successful software companies still are solutions-oriented, not programmer-oriented.
As such, I’d argue that Graham’s advice should be ignored. Focus on providing better solutions, not on producing more source code.