|
In DHH's video on Big Think (http://bigthink.com/davidheinemeierhansson), he started talking at one point about whether there was a baseline past which you can't make things easier (see the quote below). The premise was that Ruby and Rails have made web development easier and more accessible to less technical people. He argued that there is a limit to how low you could lower the bar because, at a certain point, your application is all about the thousands of little decisions that your code describes. "There is a natural, physical limit where at the end programming is just choices. How should the program work? What should happen when you click this button? Those choices are ultimately the key to programming - and you can't get out of that. Which is also why it's a bit of a pipe dream to think that 'oh, there's going to be these magical new environments where somebody that knows nothing about programming will be able to just drag and drop a few things into a box and then voila! you'll have the most amazing program in the world. No. It's really not going to happen like that because in order to have the most amazing program in the world, you have to care about a thousand decisions and recording those thousand decisions takes a programming language. So, there is a lower limit to how simple it can get." The reason why a technical co-founder is so necessary is because every application is going to have thousands of little decisions that you are describing in your code. A technical co-founder doesn't need to know everything about computer science. They need to be able to describe those decisions. Often times, if you're hiring a programmer to implement your idea, you don't actually describe things accurately. You come up with things to say like, "show the article to people who are interested in it." What does that statement mean? Do you email the article to interested people? Does it show up on the homepage for those people? A special page? How do you identify "interested people"? It keeps going on. Even "simple" things are often complex - especially if you're implementing a niche application. You can create mockups, you can list "requirements", you can have the programmer ping you when they have questions, but ultimately programmers aren't translators. Programmers, in order to be successful, must be able to make those decisions or you'll die a death of a thousand cuts as they ping you over every little decision. The problem is that people have an idea in their head that they think just needs to get "translated" into computer-speak. However, in reality, they've yet to describe most of what's in their head - if the minute details are there at all. Even if none of that co-founder's code make it past the first few months, they're able to describe the choices in an unambiguous way that mockups, emails, requirement specs, etc. simply don't. Basically, not having a technical founder means that you don't have any founder that can describe the application in the detail that's required to create something really great. It doesn't mean it's impossible and that's not to say that input from non-technical co-founders isn't important or that they can't have as meaningful an impact as technical co-founders. It means that if you're two non-technical co-founders looking to start something good, you probably need to bring on a third co-founder who is technical because you need someone you feel comfortable with making those little decisions and working with as a peer rather than in a hierarchical way. Because they're going to have to work on all those little decisions with you that mockups and specs just never address. Code is a way of describing all those little ways in which your application works, not translating an idea into computer-speak. |