(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Saturday, March 29, 2008
The only workable system for generating interesting, cool, and relevant software
Note the desired outcome: Interesting, cool, and relevant software. Do not become mired in empty debate over the phrase “smart programmers.” Instead, ponder the other three preconditions: a large problem space, actual users and most especially unconstrained by old designs.
Alan Kay is purported to have said, “A fresh perspective is worth 80 IQ points.” You cannot have a fresh perspective when you are encumbered by backwards compatibility.
The only workable system for generating interesting, cool, and relevant software is well-known. Find a bunch of really smart programmers and point them at a large problem space for which there are actual users, and for which new solutions are unconstrained by old designs.
—Mencius Moldbug, What’s Wrong with CS Research
Note the desired outcome: Interesting, cool, and relevant software. Do not become mired in empty debate over the phrase “smart programmers.” Instead, ponder the other three preconditions: a large problem space, actual users and most especially unconstrained by old designs.
Alan Kay is purported to have said, “A fresh perspective is worth 80 IQ points.” You cannot have a fresh perspective when you are encumbered by backwards compatibility.
Comments on “The only workable system for generating interesting, cool, and relevant software”:
<< Home
What scares me about Mencius Moldbug's comment is the thought that there may not have been any interesting, cool or relevant software written for decades now. Do we have to go all the way back to the birth of spread-sheets to meet those constraints?
Paul.
http://theprogrammersparadox.blogspot.com
Paul.
http://theprogrammersparadox.blogspot.com
Paul:
Perhaps we shouldn't think of this as a boolean, but rather as a smooth continuum from uninteresting, uncool, and irrelevant to interesting, cool, and relevant.
In that case, I think that the most interesting, coolest, and most relevant software has been written for the largest problem spaces, with the actual users most in mind, and with the least interest in backwards compatibility and conformance to how it has always been done.
JM2C, of course.
Perhaps we shouldn't think of this as a boolean, but rather as a smooth continuum from uninteresting, uncool, and irrelevant to interesting, cool, and relevant.
In that case, I think that the most interesting, coolest, and most relevant software has been written for the largest problem spaces, with the actual users most in mind, and with the least interest in backwards compatibility and conformance to how it has always been done.
JM2C, of course.
Re: continuous relevancy function: yes.
Let music = software.
While one stream of music like rock has evolved, forked, and fused in the last 30 years, is mainstream rock still interesting? Or more relevantly: "can mainstream rock still be reinterpreted, and tweaked to sound like something novel?"
I know that music != software, but it's not that far away.
About the problem spaces: I agree – riding the cowboy fringes of problem spaces when writing software is definitely the most fun, especially for "regular people" programmers like myself.
Let music = software.
While one stream of music like rock has evolved, forked, and fused in the last 30 years, is mainstream rock still interesting? Or more relevantly: "can mainstream rock still be reinterpreted, and tweaked to sound like something novel?"
I know that music != software, but it's not that far away.
About the problem spaces: I agree – riding the cowboy fringes of problem spaces when writing software is definitely the most fun, especially for "regular people" programmers like myself.
I would like to parse Mencius Moldbug’s quote further:
1) Take away the need for relevant, and you do not require users: There are many interesting and cool software projects that currently have a statistically irrelevant number of users. The trick is in foretelling which of these projects can become relevant, generating demand, and making a market for the product. But mostly, these projects are for the hopeless romantic. A programmer that loves “interesting” and “cool” to the exclusion of money and fame. Money and fame may follow, but it does not motivate.
2) Take away “cool” and you have classified the majority of software. My limited experience with relevant software has shown me that “cool” is only 5%, with the remaining 95% very un-cool. The “really smart programmers” are the ones who move to better projects once the cool 5% is completed. Just so I am clear, 5% represents a working prototype. The 95% is polish, usability and integration. The “un-cool” projects are where the money is, programming is long and arduous, with the occasional moment of “interesting”. Your compensation is good food, good wine, and time with friends and family
3) Take away the interesting*, and you have a project’s value based on artistic merit and proper market timing. I believe iPod and iPhone are excellent examples of products that are cool and relevant, but overall uninteresting. Of course there are the invisible subprojects in Apple’s products which contain interesting problems, but these, on their own, are not relevant outside the project, and certainly not cool. Programmers working on cool and relevant projects get satisfaction from working with a team to make something special, the coding and work are secondary concerns.
In conclusion, I doubt there are any interesting AND cool AND relevant software left to be made. All solutions will be constrained by old designs, namely the internet. The days of a single programmer being building a relevant piece of software is over; software is a team task.
But, there are still plenty of projects that match 2 out of 3. If you know yourself, you can choose the right project(s) and find happiness.
* I will define interesting as having a technically complex aspect.
1) Take away the need for relevant, and you do not require users: There are many interesting and cool software projects that currently have a statistically irrelevant number of users. The trick is in foretelling which of these projects can become relevant, generating demand, and making a market for the product. But mostly, these projects are for the hopeless romantic. A programmer that loves “interesting” and “cool” to the exclusion of money and fame. Money and fame may follow, but it does not motivate.
2) Take away “cool” and you have classified the majority of software. My limited experience with relevant software has shown me that “cool” is only 5%, with the remaining 95% very un-cool. The “really smart programmers” are the ones who move to better projects once the cool 5% is completed. Just so I am clear, 5% represents a working prototype. The 95% is polish, usability and integration. The “un-cool” projects are where the money is, programming is long and arduous, with the occasional moment of “interesting”. Your compensation is good food, good wine, and time with friends and family
3) Take away the interesting*, and you have a project’s value based on artistic merit and proper market timing. I believe iPod and iPhone are excellent examples of products that are cool and relevant, but overall uninteresting. Of course there are the invisible subprojects in Apple’s products which contain interesting problems, but these, on their own, are not relevant outside the project, and certainly not cool. Programmers working on cool and relevant projects get satisfaction from working with a team to make something special, the coding and work are secondary concerns.
In conclusion, I doubt there are any interesting AND cool AND relevant software left to be made. All solutions will be constrained by old designs, namely the internet. The days of a single programmer being building a relevant piece of software is over; software is a team task.
But, there are still plenty of projects that match 2 out of 3. If you know yourself, you can choose the right project(s) and find happiness.
* I will define interesting as having a technically complex aspect.
Kyle:
While there are many people who will find happiness working on software with zero, one, or two of those characteristics, it is not obvious to me at all that nobody will make money working on software that is interesting, cool AND relevant. Nor is it obvious to me that single programmers will not have a major role in creating such software.
Finally, iPod and iPhone are extremely interesting design challenges. I do not hold the view that they are simply "artistic" successes that were lucky to be in the right place at the right time.
iPod and iPhone are, IMO, triumphs of Good Design. Design is extremely difficult and extremely interesting. And it seems, it can also be cool and relevant.
While there are many people who will find happiness working on software with zero, one, or two of those characteristics, it is not obvious to me at all that nobody will make money working on software that is interesting, cool AND relevant. Nor is it obvious to me that single programmers will not have a major role in creating such software.
Finally, iPod and iPhone are extremely interesting design challenges. I do not hold the view that they are simply "artistic" successes that were lucky to be in the right place at the right time.
iPod and iPhone are, IMO, triumphs of Good Design. Design is extremely difficult and extremely interesting. And it seems, it can also be cool and relevant.
“…it is not obvious to me at all that nobody will make money working on software that is interesting, cool AND relevant.”
There may be interesting and cool projects that could be made relevant with some business skill. I tried to allude to this in #1 with “...The trick is in foretelling which of these projects can become relevant,…”. It is only my *opinion* that these projects no longer exist because too much interoperability is required of any new product. By the time a cool and interesting project is relevant, the cool and interesting portion is dwarfed by uncool and uninteresting effort.
“Nor is it obvious to me that single programmers will not have a major role in creating such software.”
I guess this depends on your definition of “major role”. Maybe you mean the project founder that makes a prototype. The prototype is interesting and cool, but not useable enough to be relevant. Being the founder, he may look like he plays a major role, but not because of his coding prowess, but rather his project management skills over the developers who build the remaining 95% to make the project relevant. By any objective measure, the single programmer will have contributed little to the overall project; either in hours, or in LOC, or in functionality. The single developer only appears to play a major role because he is the founder and leader. Consider Linus, he plays a “major role” in Linux kernel. But that role is dwarfed by the total effort put into the kernel, effort that was necessary to make it relevant.
“iPod and iPhone are, IMO, triumphs of Good Design. Design is extremely difficult and extremely interesting. And it seems, it can also be cool and relevant.”
This too depends on definition. I thought we were talking about programming, not UI design and ergonomics. I have no doubt ther iPod and iPhone had interesting challenges, but they were not in the domain of programming. I may be wrong here, but what do you suppose the interesting (read complex) programming aspects of the iPod or iPhone were?
There may be interesting and cool projects that could be made relevant with some business skill. I tried to allude to this in #1 with “...The trick is in foretelling which of these projects can become relevant,…”. It is only my *opinion* that these projects no longer exist because too much interoperability is required of any new product. By the time a cool and interesting project is relevant, the cool and interesting portion is dwarfed by uncool and uninteresting effort.
“Nor is it obvious to me that single programmers will not have a major role in creating such software.”
I guess this depends on your definition of “major role”. Maybe you mean the project founder that makes a prototype. The prototype is interesting and cool, but not useable enough to be relevant. Being the founder, he may look like he plays a major role, but not because of his coding prowess, but rather his project management skills over the developers who build the remaining 95% to make the project relevant. By any objective measure, the single programmer will have contributed little to the overall project; either in hours, or in LOC, or in functionality. The single developer only appears to play a major role because he is the founder and leader. Consider Linus, he plays a “major role” in Linux kernel. But that role is dwarfed by the total effort put into the kernel, effort that was necessary to make it relevant.
“iPod and iPhone are, IMO, triumphs of Good Design. Design is extremely difficult and extremely interesting. And it seems, it can also be cool and relevant.”
This too depends on definition. I thought we were talking about programming, not UI design and ergonomics. I have no doubt ther iPod and iPhone had interesting challenges, but they were not in the domain of programming. I may be wrong here, but what do you suppose the interesting (read complex) programming aspects of the iPod or iPhone were?
I thought we were talking about programming, not UI design and ergonomics.
UI design isn't programming? To put it another way, what were Bricklin and Frankston doing when they created VisiCalc? or Winer when he created the first outliner?
To me, the job of a programmer is to create programs. Some organizations chop that job up into specialties and give some of the tasks non-programming names like "web developer" or "UI designer" or "Database Analyst."
Fair enough, but when I talk about programming, I mean some or all of what goes into whatever ends up powering the application. I suppose I could buy that icons and artwork aren't programming, but UI design is far more than illustration.
UI design isn't programming? To put it another way, what were Bricklin and Frankston doing when they created VisiCalc? or Winer when he created the first outliner?
To me, the job of a programmer is to create programs. Some organizations chop that job up into specialties and give some of the tasks non-programming names like "web developer" or "UI designer" or "Database Analyst."
Fair enough, but when I talk about programming, I mean some or all of what goes into whatever ends up powering the application. I suppose I could buy that icons and artwork aren't programming, but UI design is far more than illustration.
<< Home
