Treating a startup idea as a question changes what you're looking for. If an idea is a blueprint, it has to be right. But if it's a question, it can be wrong, so long as it's wrong in a way that leads to more ideas.Humility. Simplicity. Learn something along the way. This is just the message that Ward shared. Later, he speaks of how to "do" simplicity...
Simplicity takes effort -- genius, even. ... It seems that, for the average engineer, more options just means more rope to hang yourself.In this regard, Ward offers more hope to the rest of us. Generating a truly great something may require genius; maybe not. But in any case, ordinary people can act in a way that biases their own choices toward simplicity and humility, and in doing so learn a lot and create good programs (or whatever). That's what things like CRC cards, patterns, and XP are all about. I know a lot of people think that XP requires Superhero programmers to succeed, but I know lots of ordinary folks who benefit from the agile mindset. Take small steps, make simple choices where possible, and get better as you go. I am not sure whether of how pessimistic Graham really is here about achieving simplicity, but his writing often leaves us thinking he is. But I prefer to read his stuff as "Yeah, I can do that. How can I do that?" and take good lessons from what he writes. Then, in "What I Did This Summer", Graham relates his first experience with the Summer Founders Program, bankrolling a bunch of bright, high-energy, ambitious your developers. Some of the lessons his proteges learned this summer are examples of what Ward told us. For example, on learning by doing:
Another group was worried when they realized they had to rewrite their software from scratch. I told them it would be a bad sign if they didn't. The main function of your initial version is to be rewritten.This is an old saw, one I'm surprised that the SFP needed to learn. Then again, we often know something intellectually but, until we experience it, it's not our own yet. But I really liked the paragraphs that came next:
That's why we advise groups to ignore issues like scalability, internationalization, and heavy-duty security at first. I can imagine an advocate of "best practices" saying these ought to be considered from the start. And he'd be right, except that they interfere with the primary function of software in a startup: to be a vehicle for experimenting with its own design. Having to retrofit internationalization or scalability is a pain, certainly. The only bigger pain is not needing to, because your initial version was too big and rigid to evolve into something users wanted.Ward spoke with great feeling about being willing to settle for the incomplete, about ignoring some things you probably shouldn't ignore, about disobeying conventional wisdom -- all in the service of keeping things simple and being able to see patterns and ideas that are obscured by the rules. We are conditioned to think of these behaviors as irresponsible, but they may in fact point us in the most likely direction of success. ---- I also found one really neat idea to think about from reading these papers that is independent of Ward's Cunningham. Graham was talking about doodling and what the intellectual equivalent is, because doodling is such a productive way for visual artists to let their minds wonder. Technical innovators need to let their minds wander so that they can stumble upon newly synthesized ideas, where a common frame of reference is applied to some inappropriate data. This can be the source of analogies that help us to see newly. Out of this discussion, his programmer's mind created a programming analogy:I suspect this is another reason startups beat big companies. Startups can be irresponsible and release version 1s that are light enough to evolve. In big companies, all the pressure is in the direction of over-engineering.
That's what a metaphor is: a function applied to an argument of the wrong type.What a neat idea, both as a general characterization of metaphor and also as a potential source of ideas for programming languages. What might a program gain from the ability to reason about a function applied to invalid arguments? On its face, that's an almost meaningless question, but that's part of Graham's -- and Ward's -- point. What may come from such a thought? I want to think more. I don't know that I have any more time than Graham to spend on this particular daydream... -----