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.

Comments

Unix UIs, open source, sucky software

[Sloppy]

You can't just slap any arbitrary user interface onto Unix, because Unix dictates its inner self onto all layers that ride atop it.

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.

"I think you could have open source movements that, through a peer review system, adhere to the strictest, most anal-retentive quality control program as well as open source projects that function in a perpetual state of redesign. Both are entirely doable."

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.

---

Re:Dammit, the command line is natural

[Hard_Code]

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.

What exactly did he say?

[mat catastrophe]

I read this article, really - I did - and I am not certain at all what Lanier said about software "sucking." At least, not in the sense that we all know about (bloat, fixes, patches, rush jobs, M$ in general, etc)

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.

Re:What exactly did he say?

[Junks Jerzey]

Did you read the original paper at edge.org or did you just read the fluffy overview that this story references? The original paper is several months old and is much more detailed. It's somewhat surprising that the Slashdot guys missed the original paper completely.

My feeling

[Trinition]

I have a feeling softwrae sucks because it is not engineered properly.

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.

Re:My feeling

[fhwang]

I agree with most of what your saying, but allow me to take issue with the idea of logical proofs in software. Not that I've done it much, but there are a few reasons I'd rather not rely on this:

• The vast majority of software is a question of implementation, not algorithmic logic. It seems like it's a lot more complicated to prove implementation than algorithms.
• There are currently a very small number of people with both the analytical skills and the severely rational temperment required to do these proofs. So relying on that for QA seems like it would put a really nasty bottleneck on the process.
• I have this sneaking suspicion that any abstraction of code -- UML, flowcharts, proofs -- is only that: an abstraction. And that correctness (or, more likely, bugginess) lives in the code, and in the code alone, so that's where you have to weed it out.
• It just seems like it'd be no fun. Don't get me wrong; I try to make my code clean and maintainable and all that. But if I had to run it all through some tortuous logic to prove to myself that it works, I don't think I'd ever want to code at all.

I personally think Extreme Programming holds a high amount of promise. At times it seems like dogma, but in general its principles make a lot of sense to me. Keep those feedback loops tight. Fixed requirements are a myth, so don't ever design for fixed requirements. Well-maintained test cases are as important as coding.

(Of course, I work in a web shop, and the definition of QA in our industry is "Those colors look right in that Photoshop mockup", so it's not like I really know from experience. Just some random thoughts.)

Dammit, the command line is natural

[typical geek]

Lanier pisses me off when he talks about how unnatural UNIX/Linux is with it's focus on the command line. The command line is the most natural way humans communicate.

When you get home at night, and you MOTAS/roomies ask how your day was, do you

• A. Draw pictures and icons of how your day went.
  
• B. Tell them in words how it went.
  

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.

Re:Dammit, the command line is natural

[jaf]

Your roommate understands english, a highly irregular and ambigous language.
You computer understands a different language.

find . -atime +7 -exec rm {} \; rm *purple*

it takes maybe about 5-10 years to learn how to speak english fluently. Shell scripting or even C/C++ is not that difficult.

Don't fight the command line. It is your friend.

Re:Dammit, the command line is natural

[eXtro]

The command line is the least natural way to communicate, though that doesn't mean its always the least efficient. When you get home at night, and you MOTAS/roomies ask how your day was, do you

A. Draw pictures and icons of how your day went. B. Tell them in words how it went.

You tell them in words, but this is completely different than interacting with a device. Many of the words you use are iconic as well, i.e. figures of speech or metaphors. Consider that Lanier "pisses you off", its a metaphoric way of saying that his point of view is incompatible with yours. We understand what you mean even though "pisses you off" doesn't translate directly to "point of view is incompatible with mine". Body language can be purely non-verbal yet every bit as expressive as verbal communication.

Consider an interface to a common device, a home entertainment system. It's almost purely iconic in nature. You press the on button on your remote control, which may be labelled as "ON" or with "1/0" or just green. This is an icon that is seperating you from the real physical hardware and masking the complexity from you. You don't think in terms of "I'll insert a conductor into the circuit, thus completing it and allowing the flow of electrons". You think "I'm going to turn on the television". The interface to your VCR or DVD player is the same. There's a little triangle pointing to the right, you know that it means play, it doesn't say play and you don't command the player to "spin up the motor, focus the laser and detector assembly for optimal signal/noise ratio and start reading", you push the play button.

For most people this is how computers should be. They're tools, incredibly complex tools, but the complexity should be hidden behind simple metaphors. It isn't most peoples business to know about how computers do things, only that they do it. Programmers need to know the how, and they have languages that allow them to control it via a command line environment. Of course PERL, C++ and CSH are all metaphors. In reality you're controlling the flow of electrons through some 10's of millions of transistors. Oh, wait, the transistor is a metaphor too. If you want to be really accurate you're controlling the doping of semiconductors. But wait, there's more, thats a metaphore too, on the atomic level you're... Wash, rinse, repeat. The complexity never ends.

If only project management was an honourable art..

[israfil_kamana]

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.

Software's not that different

[fhwang]

One of Lanier's points is that he thinks software should be fragmented in practice, since it's currently used in so many ways. To quote:

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:

• Who are the users? What are their needs?
• How quickly are the needs likely to change in the future?
• How long should the software stay out of obsolescence?
• How reliable should the software be?
• How can you decrease the amount of repetitive work that humans have to do?

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.

Change behavior by changing the reward system

[cscalfani]

If you want to change the quality of software, you must first determine why the quality is so bad. Economics is the biggest reason for quality being poor. The reward system in place is one that rewards the company who grabs the biggest market share. Once a product has a stronghold on the marketplace, it is extremely difficult to replace it. Software becomes a de facto standard, e.g. Microsoft WORD.

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.

Open Source is making it worse

[Junks Jerzey]

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.

Software simile

[donglekey]

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)