Slashdot Mirror
Why Software Still Sucks
atlantageek writes "The man who brought you (or somebody else) virtual reality speaks to upside about the sorry state of Software." "The Guy" is Jaron Lanier, and the article covers a fair amount of stuff. This isn't a super smart technical article, but its got a lot of interesting comments on subjects ranging from software, Linux, open source, Unix,
DeCSS, and more.
Ever seen OS/2? OS/2 is butt-ugly. It's config.sys makes DOS/Windows look elegant by comparison. But you would never guess this from the UI, which puts all other UIs to shame. How did they do it? They put a powerful layer in between: SOM.
The same sort of thing can be done with Unix, it's just that no one has. Oh wait, someone has: Apple has done it with Aqua. A very different approach than OS/2, but still, the UI is completely divorced from the inner workings. I haven't used Aqua yet, but I know that when I try it, my reaction is not going to be, "This is Unix. I know this."
The open source movement hasn't done anything like this yet, because they are too busy trying to compete with Windows. As long they keep looking to the worst UIs for inspiration (e.g. MS Windows Explorer) and try to infiltrate the corporate world by blending in (e.g. Miguel's mailer that looks just like MS Outlook), that's just how it's going to be. But it doesn't have to be like that. The GNOME/KDE guys have set their sights very low.
Could have? That sounds like present-day OpenBSD and Linux, respectively.
As for my explanation as to why software sucks, I think it's pretty simple: the economy has judged that software that sucks but is cheap, is preferable to software that doesn't suck but is expensive. Quality takes time, and time is money. I write software-that-sucks for a living, and whenever I give a customer a choice between something that sucks for 8 hours or something that sucks less for 16 hours, they almost always take the cheaper choice.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Yes, but when I drive my car, do I *TALK* to it? No, I use appropriate controlling devices for the situation: a steering wheel and pedals. Yet my bicycle handles and pedals are very different. As are airplane controls. The point is, there is no one *perfect* interface. CLI is just wrong for some things. As is a particular type of GUI, etc.
It's 10 PM. Do you know if you're un-American?
... is because he is partially correct.
:)
:-(
Most software does suck. (You'll have to forgive me if I tar all software with one brush.) Windows has it's problems, Linux has its problems. Anyone who can't critically analyse the deficiencies in their favorite software is either living in a dream world, a zealot, or blind. (No flames intended.)
The root of the problem is: bloat.
Every time we get faster hardware, we build bigger programs. We're doing so much more with the hardware nowadays -- who was doing speech recognition 20 years ago? Heck, we can partially do it in real-time now ! The latest 3D games are certainly a good example of this. Lots of nice eye-candy. *cough* Alice *cough*
The software we are building, is MANY MANY times more complicated then a 740. And the fact that we don't have off-the-shelf standarized components certainly doesn't help.
Which leads me to my next point:
The software has SO many code paths, there is NO way we can verify and spend enough time on quality assurance. And there will ALWAYS be bugs in the code we write. That sucks just as much as the bugs do.
Lastly, how many programs spend and designate time to develop a good user interface. That's also part of the problem - too many programmers (open source/closed source, doesn't matter) couldn't put together a good gui layout if their life depended on it. How many have taken a UI design course? How many are asking management to allocate time in the schedule for "polish." (As a game developer I'm just as guilty. Beta = fix all the important bugs, and ignore the small ones since we don't have time to correct it. Maybe we'll do a patch, if not. Next game to start developing.)
And I think the greatest tradegy of all, is that people have come to expect computers as being unreliable.
Why can't we apply and have a "process for engineering high quality software" ? Is code that nebulous? Is it because we keep over-complicating the systems?
People aren't perfect, which means code isn't either. But it wouldn't hurt if more people took the time to say "how can I write this code, so it's easier to maintain, and something to be proud of, instead of something that is hacked together, works, and would be an embarrasment to show to your peers."
What are other people's views?
First of all, "All operating systems" doesn't mean Unix and Win*.
I've considered this point quite a bit over the years. There is no way of a GUI getting entirely away from the command line as long as the base OS is still based on the command line. None!
The other side of the coin is that the command line falls naturally into place with a heirarchal file system. As long as we have the one, we'll have the other.
The Macintosh (of all things!) did it right in many ways. The command line is an extra tool--not the base level of the operating system. The Mac GUI _is_ the OS, to a greater degree than any other system out there.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
It appears he hates Unix, not software as such. But he makes the same error as most other who do, he equates newbie unfriendly with user unfriendly. Which are not the same at all.
I think we just need to realize that 100 amateur programmers writing and reviewing code, ad-hoc, is not necessarily better than 10 professional software engineers working closely together, using some semi-formal procedure for specification, requirements, collaberation, and coding.
A lot of the most successful open source projects, were originally created by professional programmers (Unix flavors, including BSD; Apache; Mozilla; GNU utilities in general), and still retain some form of regimentation. Linux would not be were it is if Linus et al. let every single developer add their patches in, or modify code, whenever they wanted. Unfortunately this is exactly what happens in many new open source projects under the banner of "freedom"...which ends up producing remarkably mediocre code.
It's 10 PM. Do you know if you're un-American?
what i got out of this was that Lanier thinks we are stuck in some tech-limbo, one where neither the software nor the laws governing the use of software are very useful. well, that and UNIX is old and ugly. Big deal, people still use it, and that doesn't automatically mean that it sucks.
And his comments about "humanity" not knowing how to make software, or even what software is, were just plain over-dramatic, hippified philosobabble. After all, why is he discussing it then? Is he not a part of humanity? Or, is he better than us mere mortals?
Plenty of people know what software is and how to make it. The focus is to make it more intuitive, faster, and less prone to Bad Design.
sig not found
As the author of the article points out, hardware is getting more complex and better. But hardware is designed. It's designed, tested, built upon, etc.
And while we're all taught that we shoudl use proper design for software, few of us take it whole heartedly. Sure, we might do a few object models, flow charts, etc. But how many of us use propositional logic and predicate calculus to prove our software will work as it is intended? And still further, how many of us have unbiased testing of our software?
I think the larger the corporation, the more of these practices might be enforced. But it is still up to the programmer to truly adhere and take these to heart. I don't think we quite have the discrete tools that hardware designers have. Nor do we have the worry that once the circuit is printed, you can't easily "fix" it.
When you get home at night, and you MOTAS/roomies ask how your day was, do you
When you have to describe a particular method of doing something, do you
A. Draw lots of pictures?
B. Use numbered steps with words?
I remember a book by an AT&T fellow about data compression and information theory. Two teams had to put together a mechanical device, one team member had the instructions, one had the parts, and they were separated. One team only had an oral link, the other team had video, too. There was no difference in the amount of time needed to build the device, the added video link added nothing.
HDF does Lanier plan to interact with his computers, pretty pictures? Waht ajoke.
In my experience, there are only human impediments to successfully creating healthy software. Technologies are sufficiently developed in most languages that most software can be written fairly efficiently using a wealth of frameworks and libraries. So why does software suck?
Combine time-pressures, market pressures, upper-management pressures, and a lack of training and professional standards, and you have a whole class of employee (the project manager) who has only incentives to lie and hedge, and no incentive to be honest about schedule, feature set, state-of-the-project, internal project problems, etc.
Assume a project of 15 people, with a 3 million dollar budget, and a project manager leading four teams. That's pretty complex stuff to manage. Now what if it's business critical, and he's getting letters from board-members and C*O staff imparting the import of the project unto him from on high. Can you say pressure cooker?
Now consider that three developers are fighting, and every teaser this manager has sent up the chain about problems has resulted in a standard "we expect you to solve this on time and on budget" no-help answer.
Now imagine that some contractor or 3rd party vendor that the architect and project manager had made noises about to upper management lied about their capabilities.
Now imagine that his buddy frank was fired three months ago after a fiasco project in their other business line.
Now imagine that he's not vested, but will be vested by the last month of the project.
Now imagine why this person would ever ever ever say there's a slight problem with the project until it's almost over. Or worse, he'll "two week" the project for months over time, over budget, and they'll release buggy, crappy, untested code to the customer in a beta which amounts to an alpha, expecting the customer to catch and report all the bugs.
It's no life at all, and certainly no way to get quality software, but it's a scenario I have seen repeatedly over the last few years.
i - This sig provided by
The software that runs your pacemaker is not even considered for a moment to be the same sort of entity as the software that you use to write music. ... If your interpretation of software is that it's like a bridge [and] people need to know what they're driving on, then yes, a little peer review could help. If you think of software as literature, if you're somebody like Ted Nelson, say, then what you really want is groups of people who are emboldened to try wild things.
I have a lot of respect for Lanier, and I particularly thought One Half a Manifesto was a useful and badly needed bit of skepticism against what he terms "cybernetic totalism". But I think he's off on this point.
To be sure, different parts of software have different needs. If you're designed space shuttle guidance software, go ahead and engineer for five nines (99.999% uptime). A script that pages you when you get an e-mail from your girlfriend is probably a lot less mission-critical.
But there are certain questions that are useful to the software engineering process, regardless of what code you're writing. To think of a few, off the top of my head:
Every successful software project needs to ask these questions, preferably sooner than later. Fragmenting software engineering would have a very poor effect on the development of these base strategies, so hopefully it'll never happen.
Do domain names matter?
When I was 12, I found a box containing a bunch of old issues of Hustler in a lot behing the local 7-11.
I began to feel sensations I'd never felt before.
Being a scientifically minded young fellow, I immediately ran home and examined one of the low angle money shots through my microscope.
That's when I made the horiffying discovery that women are composed of red, yellow and blue dots.
I've been trying to live with the implications of that discovery for years now, and I haven't been able to care much about code quality.
--Shoeboy
So how does a company grab the biggest slice of the marketplace pie? They do so by getting to market first. How do they get to market first? By cutting every possible corner imaginable to meet a ridiculous deadline and releasing a product of poor quality.
All other reward systems stem from this one. Imagine the case where a company has two programmers. The first hacks a bunch of code together and makes the ridiculously short deadline. The second programmer misses the deadline but produces a much more stable product. Now once the first programmers code starts to fail, the first programmer has to "save" the company by providing short-term quick fixes to the code, reducing the quality of the code further. Management views this individual as a key individual; key because they can't operate without him. The second individual is hardly noticed, except for delivering late, which is considered aberrant behavior.
So imagine the case where both of these programmers are leaving the company. Which individual do you think the company is going to bend over backwards to keep?
Economics, being the ultimate reward system for business, dictates that software development will never be able to do what hardware engineers have been doing for years, create micro-components. In hardware, you can create an AND gate and package many of these gates into a chip. This chip can be mass-produced and sold at a reasonable price. Every time a circuit is produced with this part, the manufacture make a little money for each part purchased.
In software, we can't make a simple component and standardize on it. If we created a component, e.g. a component that compares two dates to see if something has expired, and tried to sell it, what would people pay for it? Maybe a dollar. Most people would look at this component as so simple, they'd rather develop their own. But even if they did buy it, they can make millions of copies of this component with no additional cost. It would be the analogy of instead of buying an AND gate for 50 cents, you bought the AND gate factory for 50 cents. The hardware industry would have gone out of business years ago under such a system.
Software suffers from the economics constraints more than language problems, management issues, bad programmers, etc. Anyone can buy book after book on proper techniques for managing a team of developers using a myriad of development processes. The reason we see management pay only lip service to process is because the reward system for businesses doesn't reward quality or standards.
This is the real problem to solve (if there is a solution). Would companies pay royalties for components that were used in their products? Highly unlikely. Will people stop paying for new software because it is too buggy? Maybe, but it is usually better to use buggy software than no software at all.
After almost 20 years, I have given up on the software industry. As soon as I can get out, I will. The better you get in software design and development, the harder it is to operate in this environment. I don't blame companies for operating the way they do. They are rewarded for doing so.
So if you want to change behavior then change the reward system. Good luck.
Now, now, now, don't take that as a flame. But what's the average age of a Slashdot reader? 20? What's the average age of a gung-ho Open Source development team? 21? Realistically, you don't have much software engineering experience at that age. Heck, how many Open Source projects have regression test suites? Two?
I'm not talking about old standbys like Perl and Apache and so on, but most of the other projects that get started by young coders and garner press simply for being "open source" without code quality ever being an issue. I don't want to name names, but examples are plentiful. Having a relatively simple project with 5 megabytes of *compressed* source code should scare anyone off.
Lanier said,
"Basically, if you heard your brain surgeon also had a tattoo parlor, you'd probably demur. Right now we think of them as the same thing. We think it's perfectly all right for people to go back and forth. I don't think it is."
This is a fascinating suggestion and I think, aside from the flamebait in the article for Linux lovers, this may be the most important idea expressed in the interview.
That idea is that the people writing software should not only be generalists but software specialists(though I'm sure generalists are needed in software engineering just as in medicine). In this statement he both elevates software engineering to the level of medicine (which it certainly deserves given its importance in so many settings), but also calls for a more systematic approach to the social role held by coders.
Granted, while physicians are not perfect, their professional development model might not be a bad one to follow in the field of software development. Study fundamentals and then actual applications. Work under the tutelage of those more experienced. Increase professional independence. Share new ideas with peers and undergo peer review.
I think that a shift of this nature would definitely help propel software development leaps and bounds. And though it may be a good idea, what can be done to push things this way?
food for thought anyway...
I have always thought of creating a program like making a samurai sword. I know it sounds weird, but here's why. A sword is supposed to be an elegant and simple tool or weapon that really has many uses. Software, likewise should be the same way. You wouldn't want a sword that was mostly handle would you? what would be the point of that? In the same respect you wouldn't want a web browser that was all buttons and had a small windows for looking at a web page. And you wouldn't want a heavy sword, that's dull and breaks all the time would you? (think netscape 6). This is how I would break down some of the software that I use, using the sword analogy.
1. Windows - Large sword, somewhat dull, extra protrusions that make it only fit in their custom sheath. Dullness makes it harder to cut yourself, so it is more for those who don't want to develop enough skill to use a sharper sword, don't think they need one, or are scared or cutting themselves.
2. Linux - balanced different, awkward at first, but better once you get used to it. Really sharp, really durable, doesn't break, cuts through most problems easily. Not for the uninitiated. Blades everywhere, flexible but complex. Not just one knife, but lots of specialty knives designed for cutting through anything, each one for something different.
3. Winamp - a sharp, solid dagger, lightwieght, customizable with different blades, different designs for the handle.
4. IE - seemingly small handle, large blade, elegant but very fragile.
5. AIM - cuts through most of what it needs to, but is getting kind of heavy (bloated) not as bad as ICQ I think.
6. Gimp - Solid, sharp small handle, long blade, even comes with tools for sharpening. (think script-fu)
This Wiki Feeds You TV and Anime - vidwiki.org
For starters, let's say that I've a lot of respect for what Mr. Lanier achieved in the early 90s with VR, and understand that whole pop-semiotics/Mondo 2000/Boing Boing/Modern Primitive/Cyber-everything vibe he's coming from.
But allow me to reiterate that HARDWARE has a DEFINED FUNCTION. Bits go in, other bits go out. Key gets turned, engine starts. I buy a car and a plane and a boat - I don't expect to buy one vehicle that can fly, swim and roll on dry land. His problems with modern software stem from his paradoxical and contrary wishes for software engineering.
Lanier seems to have a scattergun theory as to why software sucks. It's either "the engineering isn't there" (definition A) , and/or "what it does for the customer doesn't empower him" (definition B).
To the first part I say software is considered by its mercurial nature not only something that CAN'T be engineered, but MUSTN'T be engineered. Cause if you make plans and stick to them, then marketing can't decide at the 11th hour to retool everything to include holographic agents and a Star Trek like voice input (after a night of cocaine and "brainstorming"). To whichever jackass points me to "if programmers built buildings a woodpecker could destroy civilisation" I say "make up your goddamn mind whether you want a condo or a three storey house BEFORE we pour the concrete, and we'll talk." No other form of engineering comes up with the ludicrous idea that plans are mere suggestions and subject to change at any time, to produce a product with no real set function (is Word a word processor, a typesetting program, or an HTML editor? MAKE UP YOUR MINDS). However, coming up with small, ruthlessly efficient software entities sounds like UNIX, which he says sucks by definition B of his rant.
As for his ideas that programming languages and interfaces should be humancentric, let me put it this way - computers process DISCRETE SYMBOLIC pieces of information, humans process PATTERNS and CONVOLUTIONS. I don't expect my shovel to shovel my walk for me, why should I expect my computer to respond to me drawing out what I want with magical icons and lines and all other forms of strange ideas when it comes to PROGRAMMING? (Visual Language?) Any machine that can accomplish such a feat would have so much software bloat by definition it sucks by definition A. A computer is a tool, not a mystical genie that's going to solve my problems for me. If I want a secure Internet connection, it behooves me to either learn how TCP/IP works, or hire someone who does. The answer is not to have a big red button that says "secure my system" cause I can assure you, on a system like that, someone's working on a big GREEN button that says "hack this system."
Most software sucks because people don't want to take the time to figure out what it should do or who wants it. Marketing seems to think that rather than research what a product should do and who to sell it to, it's just there to listen to every potential customer ("I want a minivan". "I want a sports car." "I want a quarter ton pickup") and spit back every ludicrous request ("We've got to come up with a sports quarter ton minivan!"). Management seems to think that rather than getting specific specs by a specific deadline and then staffing the needs of the project, giving the engineers and testers the tools, and then getting the hell out of the way, it's all about constant "meetings" and Microsoft Project bar charts.
--- Jump!! Fire!! Bullet time!! - Lego version of the Matrix
They are annoying, time destroying, silicon paperweights.
Much, MUCH better.