In Response to "Stop Looking For A Technical Co-founder"
Alexey Komissarouk, apparently a very savvy CS senior at UPenn, has written Stop Looking For A Technical Co-founder. He's criticizing the phenomenon that I've found epidemic in NYC: some business-type, I'll call him Mr. MBA, usually with no money or software-development expertise, has some idea and goes around looking for a "technical co-founder," i.e., someone who will implement the idea.
It's easy for programmers like us to make fun of Ms. MBA. One of the reasons is that many such people are naïve and useless. A bad MBA (the common breed) will wander from Meetup to Meetup searching for a technical co-founder and, in the best case, will find no takers. I've worked in a number of startups, and a good businessperson has something to contribute to software startups—he or she will deal with budgeting and advertising and talking to investors, things we don't want to do and aren't good at. In the best cases, I've seen sharp businesspeople teamed with hackers into unstoppably awesome archons.
Komissarouk thinks that Ms. MBA should learn to code, or hire an external team, or simplify her software requirements by assembling most of it from existing services.
I don't think any of these recommendations is sufficient to save the naïve aspiring software tycoon from calamity.
Learn to code. Sure, everyone should learn to code for the same reasons they should learn statistics and how a bill becomes a law. But it won't save Mr. MBA. Unless he has a natural, undiscovered talent for coding, he will not be able to compete with the professionals. And unfortunately for him, he will be competing with them: if his idea is any good, then there are hundred other people who have had the same idea at the same time. Many of those people are excellent software developers, or they know investors with money, or both. Consider the invention of the lightbulb, the telephone, and Facebook: these ideas arose in environments lousy with similar ideas; it's just that Edison, Bell, and Zuckerberg were the smartest and luckiest among the people who had those ideas. For Mr. MBA, learning to code is better than not learning, but it won't be enough to beat all the great coders who have already started working on the same idea.
Hire an external team. Assuming Ms. MBA has a lot of money somehow, she can just build a team to write the software. This is the best of the recommendations, because it dissuades Ms. MBA from her most common delusion: that her idea is worth about half the eventual company's value, and so a good coder should join her and write all the code in exchange for equity. Komissarouk is right that someone with an idea who can't implement it must be willing to pay someone else, in cash, now, to build it. The problem is, paying a team to build her idea puts Ms. MBA at a disadvantage competing with those who can code, who are working on that idea too: she has to spend more, and she can't lead her team as well.
Reuse existing services. Yes, one should definitely use existing services where possible. But it's not just business-types who can reuse services. Coders can play this game, too, as they sprint toward their launch. And they'll do it more intelligently than Mr. MBA can do it.
What's my recommendation? People shouldn't try to found businesses in realms in which they lack expertise. If Mr. and Ms. MBA can't code, chances are they won't succeed in the software industry. Maybe they have deep knowledge about a problem in baseball or microlending that could be solved by software—in such a case the MBA's expertise could be enough competitive advantage to succeed.
Or maybe Mr. and Ms. MBA don't need to go into the software business at all. Maybe they know about farming, or solar power, or sewage—the world needs innovation in all those areas so much more than it needs another clone of Foursquare or Farmville. Please, business majors—if you're not a very good software developer, turn your back on the software gold-rush. Learn about some tangible good that cries out for improvement, and go invent a better one.