Salon | Letters to the editor

_______________ THE DUMBING-DOWN OF PROGRAMMING, PART ONE AND PART TWO BY ELLEN ULLMAN (05/12/98-05/13/98)

I enjoyed reading Ellen Ullman's article very much (not least because it was so well written). And I thought you might like to know that the piece could strike a chord even with a humble end user.
I am not a programmer; in fact, I don't know a single word of any programming language. But the first system I used was a UNIX system, and in the area of typesetting I learned to do a fair number of things. I was working on the upper surface of what, to me, was a huge iceberg. Nonetheless, the commands were visible; I could combine them, pipe them, write scripts with them. If I got an unexpected result, someone could explain why in terms that made sense: This command makes the program do x, and once it does x, it is at a point in the document past where you want it to do y, so your y command doesn't work, or works on the page after the one you wanted it to work on. I had a feeling that although there were unexpected interactions, and some bugs, the system was internally consistent, and designed by people who wanted to be able to use it.
Later I also learned to use about 1 percent of the features in an enormous database program that ran on UNIX. Again, I had to learn syntax. So what? Then I could ask the program things like: "Find all records where the country is USA, the city is not New York, and the class is 'personal'; extract the name, home phone number and business phone number; put the info in a list sorted by code (a letter code based on surnames)."
When I first bought a PC and had to use Windows and WordPerfect, I was appalled. Everything was mysterious, little seemed logical, many things simply could not be done. It is years and years later now, and I am still without a database program. I tried FoxPro once and ran screaming from the room! (I'm looking into Sybase's SQL Anywhere, now that they've released a version for Windows 3.x; I have so far resisted moving to Win95, where most of my small store of hard-won knowledge about administrative chores and workarounds under 3.x would be rendered useless.)
All of this, as Ellen Ullman's article points out, illustrates what one might call an attitude problem on the part of software companies that like to boast of "user-friendly" products. Once in a Japanese restaurant here in Toronto I overheard some computer sales guys complaining about dumb end users (i.e. secretaries) who couldn't understand how to use the "user-friendly" programs these guys had sold the firms. I thought, "If only your programs trusted the users to understand, say, that a computer is not a typewriter, then the users would learn to use the computer, and would be glad of it. But instead you have to condescend, and build interfaces that hide what the machine can do." Of course this is still what is going on, especially at Microsoft. They condescend to both users and programmers. I'm rooting for the Justice Dept.!
-- Roger Greenwald
I just wanted to thank you for writing such an inspiring article. I call it "inspiring" because working for a Microsoft-only shop, it is very difficult for me to justify why I develop on UNIX/Linux systems. You put all my emotions into words. For example, I tried to tell other developers here that relying totally on NT for all network administration makes you "once removed" from understanding your network. This is equivalent to what you said about Wizards "dumbing" programmers.
I am going to ask some of my bosses to read your article so they can understand why I get so frustrated when things are just handed to me without any thought. I explain that doing the nitty-gritty work builds problem-solving skills you can use for any problem. Using these problem-solving skills, you can come up with your own ways of making your work more productive. If you want to use wizards, write them yourself. Share them with others, but INCLUDE THE SOURCE CODE! This lets others understand the Wizards and they can find ways to improve them. This is the reason I love using Linux.
-- David DeCesare
While I agree that engineers are, in general, responsible for knowing how to delve into the internals of their systems, I think the article missed its mark in that it did not target the real, underlying problem leading to many current software engineering problems.
The truth is that software engineers are only now really beginning to follow engineering, as opposed to hacking, practices.
I have often had conversations with associates and co-workers about the topic of "computer science" vs. "software engineering." My contention is that only just now are we beginning to see programming move into a real engineering role, as opposed to a "black art." Ms. Ullman's article seems to implicitly back that up.
I often think my background (undergrad degree in aerospace engineering) serves me quite well now that I write code. Aeros learn early on that they cannot possibly know every detail of every part in a plane. Many airliners have millions or even tens of millions of individual parts ... sounds kind of like a big application's or operating system's lines of code, yes? Aeros and many other systems-oriented engineers have to learn a lot about statistics and structural analysis so that they deal in probabilities of failure and know how and when to isolate potentially failure-prone components for further analysis. Software test engineers and quality assurance professionals are using a lot of these same techniques now, but this is a relatively recent development and regular old programmers with titles like "software engineer" are often still catching on to this, or worse, calling it names and ignoring it to the detriment of the quality of their software products.
The distinction that the article missed: It is not so important that the software engineer write every line of code (wizards are OK for some purposes, like enforcing a common template/style), but it is terribly important that the engineer be able to identify the failing parts of the code and then dig into them.
One of the most difficult things about real engineering, as opposed to hacking, is realizing that you cannot possibly know everything that is in, or is going on with, your application. This realization demands an entirely different and more mature approach to building things, whether they are planes or bridges or software. It seems that the general body of computer science practitioners are finally beginning to realize this. It's about time!
I often say that software engineering is about 25 years or so behind many other engineering fields, just reaching the systems understanding that was in place elsewhere long ago. Let's hope we as a community can keep moving down this path and jumping over the systems hurdles that lie ahead, else I fear we'll be wallowing in the complexity of our products and inadequate practices before we know it.
-- Bill Day
Your description of your "return" to UNIX is extremely interesting. The thing that marks your story as unusual is how it transforms the process of using a computer into a unique, personal activity. These days, with software sold over the counter, computers produced by the millions, etc., you get a feeling of enormity, of anonymity. It is as if buying and using a computer should be considered an "experience," with the corporate provider manufacturing and packaging the experience for your consumption.
As I read your adventures in re-creating your computer from scratch my impression was one of individuality. One person, putting one machine together, one feature at a time, according to her preferences. No corporate manufactured experience involved. The story gave me a new perspective at looking at the machine I use every day. Thanks.
-- Daniel Loebl
Your description of how a computer's software is built layer upon layer is how our genetic code is built. If basic things got changed and not layered the whole thing couldn't work.
Programmers add from the top rather than by doing archaeology. UNIX programmers were no different.
-- Charles Fiterman
This is about the deals that Microsoft has been signing with universities around the country in the name of philanthropy.
After enjoying the power and versatility of UNIX in college, I am now forced to use this piece of junk called Windows NT in my current job. With UNIX, I was able to dig deeper into the operating system, play with it and learn a lot about the OS. I now enjoy Linux in my home computer.
This is impossible with Windows. With MS products, the students will only learn to point and click with the mouse -- nothing else. If this is the case, very soon we will have to deal with dumb/stupid graduates who only know how to point and click. Thus, using MS products in colleges presents a grave danger to the cause of education.
Microsoft has reduced corporate computing to a heap of trash; this should not happen in colleges.
-- Prabhu Manyem
Cupertino, Calif.
SALON | May 18, 1998

_______________ THE DUMBING-DOWN OF PROGRAMMING, PART ONE AND PART TWO BY ELLEN ULLMAN (05/12/98-05/13/98)
	I enjoyed reading Ellen Ullman's article very much (not least because it was so well written). And I thought you might like to know that the piece could strike a chord even with a humble end user. I am not a programmer; in fact, I don't know a single word of any programming language. But the first system I used was a UNIX system, and in the area of typesetting I learned to do a fair number of things. I was working on the upper surface of what, to me, was a huge iceberg. Nonetheless, the commands were visible; I could combine them, pipe them, write scripts with them. If I got an unexpected result, someone could explain why in terms that made sense: This command makes the program do x, and once it does x, it is at a point in the document past where you want it to do y, so your y command doesn't work, or works on the page after the one you wanted it to work on. I had a feeling that although there were unexpected interactions, and some bugs, the system was internally consistent, and designed by people who wanted to be able to use it. Later I also learned to use about 1 percent of the features in an enormous database program that ran on UNIX. Again, I had to learn syntax. So what? Then I could ask the program things like: "Find all records where the country is USA, the city is not New York, and the class is 'personal'; extract the name, home phone number and business phone number; put the info in a list sorted by code (a letter code based on surnames)." When I first bought a PC and had to use Windows and WordPerfect, I was appalled. Everything was mysterious, little seemed logical, many things simply could not be done. It is years and years later now, and I am still without a database program. I tried FoxPro once and ran screaming from the room! (I'm looking into Sybase's SQL Anywhere, now that they've released a version for Windows 3.x; I have so far resisted moving to Win95, where most of my small store of hard-won knowledge about administrative chores and workarounds under 3.x would be rendered useless.) All of this, as Ellen Ullman's article points out, illustrates what one might call an attitude problem on the part of software companies that like to boast of "user-friendly" products. Once in a Japanese restaurant here in Toronto I overheard some computer sales guys complaining about dumb end users (i.e. secretaries) who couldn't understand how to use the "user-friendly" programs these guys had sold the firms. I thought, "If only your programs trusted the users to understand, say, that a computer is not a typewriter, then the users would learn to use the computer, and would be glad of it. But instead you have to condescend, and build interfaces that hide what the machine can do." Of course this is still what is going on, especially at Microsoft. They condescend to both users and programmers. I'm rooting for the Justice Dept.! -- Roger Greenwald I just wanted to thank you for writing such an inspiring article. I call it "inspiring" because working for a Microsoft-only shop, it is very difficult for me to justify why I develop on UNIX/Linux systems. You put all my emotions into words. For example, I tried to tell other developers here that relying totally on NT for all network administration makes you "once removed" from understanding your network. This is equivalent to what you said about Wizards "dumbing" programmers. I am going to ask some of my bosses to read your article so they can understand why I get so frustrated when things are just handed to me without any thought. I explain that doing the nitty-gritty work builds problem-solving skills you can use for any problem. Using these problem-solving skills, you can come up with your own ways of making your work more productive. If you want to use wizards, write them yourself. Share them with others, but INCLUDE THE SOURCE CODE! This lets others understand the Wizards and they can find ways to improve them. This is the reason I love using Linux. -- David DeCesare While I agree that engineers are, in general, responsible for knowing how to delve into the internals of their systems, I think the article missed its mark in that it did not target the real, underlying problem leading to many current software engineering problems. The truth is that software engineers are only now really beginning to follow engineering, as opposed to hacking, practices. I have often had conversations with associates and co-workers about the topic of "computer science" vs. "software engineering." My contention is that only just now are we beginning to see programming move into a real engineering role, as opposed to a "black art." Ms. Ullman's article seems to implicitly back that up. I often think my background (undergrad degree in aerospace engineering) serves me quite well now that I write code. Aeros learn early on that they cannot possibly know every detail of every part in a plane. Many airliners have millions or even tens of millions of individual parts ... sounds kind of like a big application's or operating system's lines of code, yes? Aeros and many other systems-oriented engineers have to learn a lot about statistics and structural analysis so that they deal in probabilities of failure and know how and when to isolate potentially failure-prone components for further analysis. Software test engineers and quality assurance professionals are using a lot of these same techniques now, but this is a relatively recent development and regular old programmers with titles like "software engineer" are often still catching on to this, or worse, calling it names and ignoring it to the detriment of the quality of their software products. The distinction that the article missed: It is not so important that the software engineer write every line of code (wizards are OK for some purposes, like enforcing a common template/style), but it is terribly important that the engineer be able to identify the failing parts of the code and then dig into them. One of the most difficult things about real engineering, as opposed to hacking, is realizing that you cannot possibly know everything that is in, or is going on with, your application. This realization demands an entirely different and more mature approach to building things, whether they are planes or bridges or software. It seems that the general body of computer science practitioners are finally beginning to realize this. It's about time! I often say that software engineering is about 25 years or so behind many other engineering fields, just reaching the systems understanding that was in place elsewhere long ago. Let's hope we as a community can keep moving down this path and jumping over the systems hurdles that lie ahead, else I fear we'll be wallowing in the complexity of our products and inadequate practices before we know it. -- Bill Day Your description of your "return" to UNIX is extremely interesting. The thing that marks your story as unusual is how it transforms the process of using a computer into a unique, personal activity. These days, with software sold over the counter, computers produced by the millions, etc., you get a feeling of enormity, of anonymity. It is as if buying and using a computer should be considered an "experience," with the corporate provider manufacturing and packaging the experience for your consumption. As I read your adventures in re-creating your computer from scratch my impression was one of individuality. One person, putting one machine together, one feature at a time, according to her preferences. No corporate manufactured experience involved. The story gave me a new perspective at looking at the machine I use every day. Thanks. -- Daniel Loebl Your description of how a computer's software is built layer upon layer is how our genetic code is built. If basic things got changed and not layered the whole thing couldn't work. Programmers add from the top rather than by doing archaeology. UNIX programmers were no different. -- Charles Fiterman This is about the deals that Microsoft has been signing with universities around the country in the name of philanthropy. After enjoying the power and versatility of UNIX in college, I am now forced to use this piece of junk called Windows NT in my current job. With UNIX, I was able to dig deeper into the operating system, play with it and learn a lot about the OS. I now enjoy Linux in my home computer. This is impossible with Windows. With MS products, the students will only learn to point and click with the mouse -- nothing else. If this is the case, very soon we will have to deal with dumb/stupid graduates who only know how to point and click. Thus, using MS products in colleges presents a grave danger to the cause of education. Microsoft has reduced corporate computing to a heap of trash; this should not happen in colleges. -- Prabhu Manyem Cupertino, Calif. SALON \| May 18, 1998