Regarding your article “Awaiting the Day When Everyone Writes Software”:
Your ignorance of the reality of software development would be excusable if not for the fact that your CV suggests that you should know better. Your defamatory description of programmers smears an entire industry of individuals with a single, pejorative stereotype.
MIT should be ashamed to have someone affiliated with them who is prejudiced against so many of its own graduates. Perhaps you could help the state of software by visiting the computer science department and telling the professors and students that they don’t interact with people, and that software is so ugly because they are drowning in ignorance, complexity, and error. I’m sure they’ll welcome your fresh and insightful help.
Programming is hard, only in small part because of “esoteric programming languages.” More importantly, what programmers actually do includes a substantial amount of coaxing details out of the folks who actually want the software created, trying to devise a conceptual model that would actually work. Only then do we shuffle off into our lonely monastery with pizza and sodas under our arm (or whatever stereotype it is that you have of us) and hunch over keyboards, hoping that we got the esoteric bits right.
Wikipedia’s page on you says that you write “a regular column, entitled “Slipstream”, about new idea[s] in technology for The New York Times on Sunday.” But the idea that we can just talk to a computer in a natural language or domain specific language, instead of this darn esoteric gibberish, is not at all a new idea. It was covered twenty years ago in No Silver Bullet:
The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions. This essence is abstract in that such a conceptual construct is the same under many different representations. It is nonetheless highly precise and richly detailed.
I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared with the conceptual errors in most systems.
If this is true, building software will always be hard. There is inherently no silver bullet.
In other words, it’s the detailed thinking about what the software will do that is the hard part. Adding 2+2 and putting the result onto the screen is easy.
However, you say:
Programmers don’t know what a computer user wants because they spend their days interacting with machines.
I suppose if you redefine “programmer” so that it doesn’t reflect what programmers actually do, you would be correct. (“All programmers communicate only with machines. People are not machines. Therefore, programmers do not communicate with people.”)
But we do work with people, and that’s where the gap exists between a fuzzy idea and a design that a programmer can “hunch over” and type in. Our job is largely to work with people to fill in the many, many gaps between a general idea and a detailed design that can, say, put an International Space Station in orbit so that Mr. Simonyi can visit it.
In fact, since Mr. Simonyi’s days of “punching machine code”, the esoterica of programming has gotten easier and easier, and yet software development remains difficult. Even after the widespread acceptance of COBOL, SQL, and other languages designed to allow Sr. VP Everyman to interact directly with computers in something very similar to plain English (without those darn monks slowing things down and messing it all up with bugs), Sr. VP Everyman decided to hire some folks to hammer out the details and hunch over the computers, interacting with the machines. Those people are called Programmers.
Finally, software is not unique in being the “bottleneck” between wishful thinking and our practical problems. Wouldn’t it be wonderful if we had a wacky gadfly zillionaire / civilian astronaut in training, telling us he had invented “Intentional Engineering”? You just type in a wish for, say, nanobots that will convert heaps of garbage into beautiful energy efficient palaces for the homeless, and it does all the work of those darn grumpy engineers who always want time to design and test things. In the next version, we’ll make the nanobots also accept radioactive waste. Problem solved! You could call your next article “Awaiting the Day When Everyone Designs Nanobots.”