Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!ncar!ico!rcd From: rcd@ico.isc.com (Dick Dunn) Newsgroups: comp.misc Subject: Re: A tirade about inefficient software & systems Summary: help us! Message-ID: <1990Nov1.002513.8984@ico.isc.com> Date: 1 Nov 90 00:25:13 GMT References: <9886@milton.u.washington.edu> Organization: Interactive Systems Corporation, Boulder, CO Lines: 241 kraig@biostr.biostr.washington.edu (Kraig Eno) writes: > Excuse me, I'm fed up. If you are one of the world's many purveyors of > fat software systems, please take these comments to heart; otherwise, > ignore my ranting. A sympathetic reply from the (not always fat) purveyor side: First, why would you have the other folks ignore your ranting? You might note that, although there's plenty of fat software being made, it's being sold. It does not languish on the shelves. Address yourself not only to those who make it, but to those who buy it as well, and who vote with their dollars for the bloat. > ...William Demmer, says "The rate of technological change is > accelerating beyond what we expect will be the world's ability to absorb > it. That puts the burden back on the suppliers to help figure out how to > use that capability." Examine that second sentence. That's right, the > user is so overwhelmed with computing power...[etc] Also note the discrepancy between "absorb" in the first sentence and "use" in the second. It's as if there's some danger in having resources we're not using! (Do they get stale?:-) > ...Why, I ask you? Because the seller wants MONEY. And if the > seller can't think of a legitimate use for the resources, they will merely > bog their CPUs down doing useless things, because it sells the product. Not even that complicated: If the seller can't think of a use (legitimate or otherwise) for the resources, there will be no reason for the new product. It's no different than the way a company puts the same old laundry soap (cereal, whatever) in a wider, taller, shallower box and shouts "New! Improved!" It's the American way, son. > ...Software companies continually produce bigger, slower packages, > and the entire industry is locked into this struggle of software "taking > advantage" of faster hardware, and hardware vendors trying to keep pace > with resource-hogging software... I think it is wrong to say that the hardware vendors are trying to keep pace. They're way ahead of us. I know of one recent egregious exception, where a massive hardware improvement (in the "second try" at a product line) has been nearly completely destroyed by software--but that was stupidity above and beyond the call of duty on the part of the software folks, and it's really not that common. Mostly the sparkies give us improvements faster than we can waste them. No, instead what happens is that software folks, after some past decades of being "against the wall" with demands increasing much faster than hard- ware capability, have gone through a decade or so of hardware advancing faster than we can figure out what to do with it. Face it, we just do not know how to manage software growing at memory-capacity rates (a factor of four every few years) or CPU speeds (a factor of two per year)! It's like pushing hard against a door, when someone suddenly opens it and you fall through...the result is not a graceful entry to the next room. But, of course, this hasn't stopped people from trying to "absorb" all that excess capacity. So what happens to it? It must go somewhere, right? FEATURES!!! Let's add features. Let's goop up the system with stuff we've needed...and then stuff we've wanted, and stuff that somebody once said he wanted, and stuff that somebody might want, and even stuff that nobody wants but that might sell a system. Let's add features like there's no tomorrow. The hardware will support it. We've got the memory, CPU cycles, and disk. Unfortunately, we don't have the software technology to manage the complexity begotten of this feature-madness. It's not even clear if we should want to be able to manage the monsters we're creating, because they're going to be incomprehensible no matter what, to *every*one--the designer, the implementor, the maintainers (poor souls, and they're most of the software world), and most importantly, the end user. There's just Too Much Crud. But wait...you were railing against software bloat, and I say it's coming from features...why do we keep adding features? Why keep making our jobs harder? BECAUSE IT SELLS!!! Yes, say what you will about the nasty software vendors, they're creating what they can sell. Start with a system X that's got n bullet-list features in it. Now create a system Y that's got n+1 features but is 10% slower and larger, and create a system Z that's got n-1 features but is 10% faster and smaller. Take 'em to market; Y will out-sell Z by 5 to 1! I *hate* that (because I'd rather use--let alone maintain--system Z). But I can't ignore it. Vendors make bigger, slower systems because that's what happens when you keep adding features. People buy features. In the realm of software, very few people buy performance. (The only way to sell performance is to find a huge performance win and sell it as a feature.:-) > The software mafia is even trying to convince us that DOS machines should > have windows. Come on, the DOS world has been adding mostly chrome for five years. The things that sell are flash--color, cute graphics, and such. The window game is just another big piece of chrome. Or look at it this way: The window systems are "packaging." They are to software systems what the bold logo and fluorescent colors are to a box of laundry detergent. > Can someone convince me that all the world NEEDS windows, bitmapped > graphics, image processing, DTP, virtual memory, and PostScript?... Let's not throw out the baby with the bathwater. Consider some of them: - bitmapped graphics? A standard glass tty is using bitmaps of characters; all raster devices do that. Just taking some bits out of RAM instead of a character-generator ROM is no big deal. It's when you pile a megabyte of ill-conceived code on it that you got problems. - virtual memory? That may be the longest piece of rope ever given to software people. So what if some of them tie nooses with it? VM can make the job a lot easier for lots of programmers--we don't have to keep figuring out nits of memory handling. Trouble starts when people treat VM as real, and use it as if there were always real memory under- neath. VM isn't the devil; it's just subject to abuse on a galactic scale. (I could digress here that part of the problem comes from the feature madness driving us to employ ever-more-mediocre programmers, such that the few folks who really *can* think get stuck doing main- tenance 'cause they're the only ones who can understand the mess.) - PostScript? I can't think of anything that's ever come along to make the task of dealing with a printer simpler, more regular, more trans- parent. I need think of one interface. I don't have to deal with all those @&^%!! escape sequences that I can't read. I don't have to stumble through ninety-leven unnecessary limitations. I don't have to worry about the printer's resolution, or which way it thinks is up, or how it counts. I just say "put this stuff there" and it works. For once, I can change printers without rewriting the back end of every printing program that does more than trivial text. Sure, it's expen- sive...but at least this one buys us all something. The ones I didn't mention, I agree you can toss. For the ones I did mention, the two-bit summary is that they're tools which happen to be easily misused. > ...can someone tell me why every operating system upgrade in > the history of computing is BOTH bigger AND slower?... You can guess my answer: more features. > What is the solution? I put forward a few simple requests. > > DON'T make every application do everything under the sun. Do the > essential operation, do it well, and make it efficient! Doesn't sell. Hey, I agree with you completely, but it g* d* absof*lutely *doesn't* sell! Look at UNIX as it was a decade ago. UNIX was made up of a small, elegant kernel, plus a large collection of small applications, each of which did a few things very well. You put together tools from this neat toolkit, and they just worked. Now look at UNIX today, and look at what people are putting on top of it. There's lot's of "stuff" to sort through, but when you get to the bottom of it, what you find is that the big sellers are...applications that do every- thing under the sun! Why? Can't get anyone to think how to use what's there. They want it all fitted out for them; if they want four, they're not willing to put two and two together. In the harshest way of stating it, they're buying the software bloat so they don't have to think instead. Over in comp.unix.sysv386, within a two-week period we had people post programs to solve two separate problems, each of which could have been solved with one- or two-line scripts. And these folks are supposed to be technoids! It's certainly not a lack of industriousness, but there's sure an overwhelming intellectual laziness. ("think for 30 seconds" loses out to "code/test for half an hour"???) At the level of the most inept user, it's vastly worse. He wants to be guided through every possibility; he wants choices maximally constrained so he can only choose what makes sense and even then doesn't have to choose among too many things. This is hard! And it's hard to make it convenient! It's one thing to build a toolbox full of the right selection of quality tools; it's much harder to make tools which stand up and say things like "perhaps I can help? I'm a saw; I will cut things into pieces along straight lines. Perhaps what you need is one of these, except cut to a different shape?" So we end up adding goo. Some of the goo is there to make it look "user friendly." Some of it is to try to organize information on the screen so that someone who doesn't know what he's doing can act as if he does. A lot of goo is devoted to trying to present too much infor- mation--all the help that shouldn't be necessary--in a tiny area of screen, in a way that might be useful to someone who isn't paying attention. > Look at the resources demanded by the bare application, then look at what > it requires with all the bells and whistles added. Then ask yourself if > the gadgets are worth the mind-boggling amount of CPU time and RAM that > are spent on them. If you think you need them to sell your product, then > spend less on marketing and don't be so greedy. Sorry, wrong. Leave out the bells and whistles, and you'll be an obit entry in next month's business section. And the fewer bells and whistles you have, the *more* marketing you need! My challenge to you, speaking as software-producer to software-user, is to tell us how to teach everyone that feature-madness is doing us all in. Figure out how to change things so that chrome-plated bloat doesn't sell (or even so that a svelte system *will* sell). Tell us how to sell some nice, simple, organic software without MSG/BHA/BHT/artificial-color/ artificial-flavor/emulsifiers/thickeners/stabilizers, in a plain brown wrapper. > And finally, one for the non-programmer. Quit bellyaching! I know one > company which insists on printing 1000 envelopes through a PostScript > printer for mass mailings. And they complain because it doesn't work > well. Of course it doesn't work well! You are putting characters on > envelopes. You don't need PostScript, you don't need a Mac, and you don't > need a network!... I saw someone counter this one with an argument about making nice-looking envelopes. There was a good point hiding underneath his retort, namely that (alas) style wins over substance. But still, what you do even to make it look ultra-spiffy, is to get some transparent label stock, use the fancy envelopes, and write the little program or script to generate the labels. You get about a 30-fold improvement in speed 'cause even a PostScript printer is limited by engine speed for labels, and there's about 30 labels on a page. I guarantee it can chunk 'em out as fast as you can stick 'em on envelopes...and the script to generate the PostScript will be about the 20-line C program to spit out labels anyway. I've got several of these little 20-30 line scripts to churn out mailing lists, custom fancy letterhead envelopes, whatever. PostScript ain't the culprit. But if you have it around for other reasons, you can use it right instead of being ultra-dumb about it. _ _ _ _ _ For my parting shot...I found some stuff recently that made me feel better, in a bittersweet sort of way. I bought copies of the "UNIX Research Sys- tem - 10th Edition" books. Those are the reference manuals for the system they're using in the research group at Bell Labs. One can find out that the kernel on that OS has only grown a factor of two or so in the past decade--not the factor of ten or more of other kernels. The system is still described by a couple of convenient-sized books, not a shelf'o' dead-trees. It retains the "toolkit" feeling. Yet it's a modern system. So what's the bitter half of that? It's unlikely it will see the light of day. Why not? It's a research tool for one group; OK, fine. But it's also unlikely that a system *like* it would ever become a product. Why not? Because it doesn't have the... ************** <<**FEATURES!!**>> ************** -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...but Meatball doesn't work that way!