Slashdot Mirror
Why Programming Still Stinks
Andrew Leonard writes "Scott Rosenberg has a column on Salon today about a conference held in honor of the twentieth anniversary of the publishing of 'Programmers at Work.' Among the panelists saying interesting things about the state of programing today are Andy Hertzfeld, Charles Simonyi, Jaron Lanier, and Jef Raskin."
Hitler hatte recht! Heil Hitler!
These veterans shared a starting-point assumption that the rest of the world is only slowly beginning to understand: While computer hardware seems to advance according to the exponential upward curve known as Moore's Law (doubling in speed -- or halving in cost -- every year or two), software, when it advances at all, seems to move at a more leisurely linear pace.
As Lanier said, "Software inefficiency can always outpace Moore's Law. Moore's Law isn't a match for our bad coding."
The impact of this differential is not simply a matter of which industry gets to collect more profits. It sets a maddening limit on how much good we can expect information technology to achieve. If computers are, as it has often been put, "amplifiers for our brains," then software's limitations cap the volume way too low. Or, in Simonyi's words, "Software as we know it is the bottleneck on the digital horn of plenty."
Most successful programmers are at heart can-do engineers who are optimistic that every problem has a solution. So it was only natural that, even in this relatively small gathering of software pioneers, there were multiple, and conflicting, ideas about how we should proceed in order to break that bottleneck.
Simonyi believes the answer is to unshackle the design of software from the details of implementation in code. "There are two meanings to software design," he explained on Tuesday. "One is, designing the artifact we're trying to implement. The other is the sheer software engineering to make that artifact come into being. I believe these are two separate roles -- the subject matter expert and the software engineer."
Giving the former group tools to shape software will transform the landscape, according to Simonyi. Otherwise, you're stuck in the unsatisfactory present, where the people who know the most about what the software is supposed to accomplish can't directly shape the software itself: All they can do is "make a humble request to the programmer." Simonyi left Microsoft in 2002 to start a new company, Intentional Software, aimed at turning this vision into something concrete.
Jef Raskin jumped in. "And what do they put on top of it? Another Windows!"
"What are they thinking?" Lanier continued. "Why is the idealism just about how the code is shared -- what about idealism about the code itself?"
At this point, Andy Hertzfeld, who has devoted himself in recent years to open-source projects like Eazel and Chandler, spoke up for the maligned legions of Linux-heads. "It's because they want people to use the stuff!"
His comment underscored something that's frequently misunderstood about the open-source approach, which is often wrongly stereotyped as loopily communal and out-of-touch with business reality. There's an essential pragmatism to the notion that programmers work best when they can share, and learn from, one another's work. After all, every other field of human endeavor works that way.
Bricklin sent waves of laughter through the auditorium by reading a passage from Lammers' interview with Bill Gates in which the young Microsoft founder explained that his work on different versions of Microsoft's BASIC compiler was shaped by looking at how other programmers had gone about the same task. Gates went on to say that young programmers don't need computer science degrees: "The best way to prepare is to write programs, and to study great programs that other people have written. In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating systems."
Bricklin finished reading Gates' words and announced, with an impish smile, "This is where Gates and [Richard]
In some quarters today, it's still a controversial proposition to argue that computer programming is an art as well as a science. But 20 years ago, when Microsoft Press editor Susan Lammers assembled a collection of interviews with software pioneers into a book titled "Programmers at Work," the idea was downright outlandish. Programming had long been viewed as the domain of corporate engineers and university computer scientists. But in the first flush of the personal computer era, the role of software innovator began to evolve into something more like the grand American tradition of the basement inventor -- with a dollop of the huckster on top and, underneath, a deep foundation of idealism. It made sense that the people writing the most important code for the new desktop machines were ragged individualists with eccentric streaks. At a panel on Tuesday (sponsored by the SDWest conference and Dr. Dobb's Journal) that celebrated Lammers' book, seven of the 19 original subjects of "Programmers at Work" lined up on stage to talk about what's changed in software over the past two decades -- and demonstrate that they have lost none of their cantankerous edge. In "Programmers at Work," Lammers told the crowd, "I looked at the programmer as an individual on a quest to create something new that would change the world." Certainly, the panel's group lived up to that billing: it included Andy Hertzfeld, who wrote much of the original Macintosh operating system and is now chronicling that saga at Folklore.org; Jef Raskin, who created the original concept for the Macintosh; Charles Simonyi, a Xerox PARC veteran and two-decade Microsoft code guru responsible for much of today's Office suite; Dan Bricklin, co-creator of VisiCalc, the pioneering spreadsheet program; virtual-reality pioneer Jaron Lanier; gaming pioneer Scott Kim; and Robert Carr, father of Ashton-Tate's Framework. But for all their considerable achievements, this was not a group content to snooze on a heap of laurels. In fact, though the hour-and-a-half discussion was full of contention, one thing all the participants agreed on was that software today is in dire need of help. It's still too hard: not only for users struggling to make sense of poorly designed interfaces, but for programmers swimming upstream against a current of constraints that numb creativity and drown innovation. These veterans shared a starting-point assumption that the rest of the world is only slowly beginning to understand: While computer hardware seems to advance according to the exponential upward curve known as Moore's Law (doubling in speed -- or halving in cost -- every year or two), software, when it advances at all, seems to move at a more leisurely linear pace. As Lanier said, "Software inefficiency can always outpace Moore's Law. Moore's Law isn't a match for our bad coding." The impact of this differential is not simply a matter of which industry gets to collect more profits. It sets a maddening limit on how much good we can expect information technology to achieve. If computers are, as it has often been put, "amplifiers for our brains," then software's limitations cap the volume way too low. Or, in Simonyi's words, "Software as we know it is the bottleneck on the digital horn of plenty." Most successful programmers are at heart can-do engineers who are optimistic that every problem has a solution. So it was only natural that, even in this relatively small gathering of software pioneers, there were multiple, and conflicting, ideas about how we should proceed in order to break that bottleneck. Simonyi believes the answer is to unshackle the design of software from the details of implementation in code. "There are two meanings to software design," he explained on Tuesday. "One is, designing the artifact we're trying to implement. The other is the sheer software engineering to make that artifact come into being. I believe these are two separate roles -- the subject matter expert and the software engineer." Giving the former group tools to
Amen Brother.
I can't afford a sig!
I have been working in industry for a bit over 7 yrs and have made a few observations that I believe makes software suck:
-People try to rely on process to fix 'common sense'. By common sense I mean being careful, meticulous, and using one's brain for each situation one comes across. Granted, I work in a large corporation and this may not apply to some of the smaller companies, but I have noticed that when we find a bug, or have some sort of other development issue, management tacks on more process to fix it. It's of course normal for people to make mistakes but sometimes you just have people that continually use poor judgement - get rid of those people and get others who can do the job right!
-Today's engineers have a large tendancy to overarchitect, doing MUCH more than is required; overthinking what possible changes may occur in the future and designing code around that idea (this idea isn't bad in and of itself, but I have found people get carried away in this area) - What happened to the KISS principal?
-I may sound horribly outdated, but I have serious questions as to whether OOP has bought us anything as an industry. Sure, when used properly, I believe it can have some benefits. BUT I think it gives the programmer so many powerful tools, that incompetant programmers (of which are there many) turn those tools into powerful weapons. Most of the projects I have dealt with have been C based (~90%) - the rest, some sort of OOP (the remaining 10%). Even though the quantity of procedural code greatly outnumbered the OOP, the two most confusing, sh*ttiest pieces of garbage were OOP - I don't this this is a cooincidence. I have found that people can learn the techniques and tools of OOP, but often they fail to understand the philosophy and why it was developed in the first place. Abuse of OOP creates mass amounts of crap code that needs to be maintained.