Slashdot Mirror

Process isn't the problem, environment isn't the problem, language isn't the problem. The problem is that everyone looks to all of these things as the silver bullet that's going to "fix" software. Test driven development doesn't make good software any more than I-495 makes New York City. There is no silver bullet.

That may be true, but that doesn't make a valid argument.

Is that so F-ing hard to figure out?

http://www.virtualschool.edu/mon/SocialConstruction/Logic.html

No, it does not work. It sucks. Ask Toyota :-). Look at it this way. If software were any good, our cars would be driving themselves by now. The reason that they don't is that the code gets so complex that it cannot be guaranteed to be 100% reliable. In fact, since the publication of Brooks's No Silver Bullet paper, most people are convinced that there is no hope in finding a solution to the software reliability crisis. Others disagree, of course.

http://www.virtualschool.edu/mon/SoftwareEngineering/BrooksNoSilverBullet.html

If you want to do object oriented programming you use Java or C# (or Objective C on the Apple platforms). They have object systems that make sense.

One of the BIG things about C++ is that it is multi-paradigm. If I want to do some object-oriented programming, but not all the time (because it is no silver bullet), C++ is a choice that is extremely well-supported on many platforms.

He experimented further. In one class he had everyone write all hour about the back of his thumb. Everyone gave him funny looks at the beginning of the hour, but everyone did it, and there wasn't a single complaint about "nothing to say."

In another class he changed the subject from the thumb to a coin, and got a full hour's writing from every student. In other classes it was the same. Some asked, "Do you have to write about both sides?" Once they got into the idea of seeing directly for themselves they also saw there was no limit to the amount they could say. It was a confidence-building assignment too, because what they wrote, even though seemingly trivial, was nevertheless their own thing, not a mimicking of someone else's. Classes where he used that coin exercise were always less balky and more interested.

As a result of his experiments he concluded that imitation was a real evil that had to be broken before real rhetoric teaching could begin. This imitation seemed to be an external compulsion. Little children didn't have it. It seemed to come later on, possibly as a result of school itself.

That sounded right, and the more he thought about it the more right it sounded. Schools teach you to imitate. If you don't imitate what the teacher wants you get a bad grade. Here, in college, it was more sophisticated, of course; you were supposed to imitate the teacher in such a way as to convince the teacher you were not imitating, but taking the essence of the instruction and going ahead with it on your own. That got you A's. Originality on the other hand could get you anything...from A to F. The whole grading system cautioned against it.

He discussed this with a professor of psychology who lived next door to him, an extremely imaginative teacher, who said, "Right. Eliminate the whole degree-and-grading system and then you'll get real education."

From Zen and the Art of Motorcycle Maintenance by Robert M. Pirsig

Java is a train-wreck (in my opinion) because it treats OOP as a silver bullet, and every developer should know that there is no silver bullet .

So maybe OOP was the biggest advance in software engineering in recent years, but that still doesn't mean it's a good fit for everything. I like to use everything, so I work in C++ professionally, and I dabble in Python and Lisp for those parts of "everything" that still haven't caught on in the mainstream.

NextSTEP created Objective-C for their OS and API (which became Cocoa later on). So, it's not uncommon per se, it's merely created for that purpose. Although you can code on Windows with Objective-C (since gcc supports it on all platforms), without Cocoa it wouldn't be a seamless adventure. TBH I'd be surprise if anyone does any serious works with it outside of anything apple-related.

I develop with iPhone and OSX everyday and I agree Objective-C is a beautiful and well-designed language, but most of the fantastic experience of using it comes from the API part, not the language by itself.

Correction: Brad J. Cox Founder of Productivity Products International created Objective-C.

Object-oriented Programming: An Evolutionary Approach, by Brad J. Cox.

Brad later co-founded Stepstone and NeXT eventually bought all rights to Objective-C as they developed their own version, based on Brad's works.

Brad J. Cox's current info: http://www.virtualschool.edu/cox/

The self-documenting approach to coding that Objective-C inherits from Smalltalk makes for understanding what the hell is going on, by design, more rapidly than traditional C++ jargon. Of course, for every single book on Objective-C/Cocoa there are one hundred C++ or Java tombs. Somehow, the sheer volume of repeated books has helped reinforce in the minds of those never programming in Objective-C that it's some quasi-exotic language that no one ever uses. That's changing in a large way. As the growth of OS X 10.6 and beyond becomes apparent, so will the growth of books published and developers exposure to both help learn and evolve the language where it makes sense.

Quite a bit of Java's design was grafted from ObjC, yet that C++ syntax of Java somehow gives people the notion it's a derivative of C++ alone.

Regarding the Frameworks of Cocoa and without them the language wouldn't be so elogant. The same is true for all programming languages. Without Trolltech Qt's Libraries C++ wouldnt' be so elogant. Without the overkill of solutions within Java the Java language wouldn't have become the Server-side standard. So on and so forth.

http://www.virtualschool.edu/mon/ElectronicFrontie r/LaserPatentWars

First to office can be crucial

What Makes Software Development So Hard?

Asked and answered in 1987, and still spot-on. No Silver Bullet: Essence and Accidents of Software Engineering

See also: The Iceberg Secret, Revealed.

Back in the day, before any banks had gotten clueful, we used First Virtual. Each transaction required an email confirmation, which was nice for security, but probably too big a pain in the posterior. It didn't last very long.

Bullshit!

Why even bother with engineers if that is your attitude? Why bother having projects at all? Let's just funnel money directly into defense and aerospace contractors' pockets, and make it easier for them to pay off the politicians. It'll be a whole lot more efficient, and, in cases like the shuttle, won't lead to any loss of life.

I've posted this link elsewhere, but it bears repeating.

And WTF is a "newspaper deal"?

For the record, your new owners are Japanese. All your base, baby. w00t!

Japanese do exhibit nationalistic pride

This has been an ongoing thing in Japan. It drives the Japanese imported car idustry in places like New Zealand. Forcing local consumption also helps Japan develop new products in its quest to export. For an interesting read http://www.virtualschool.edu/mon/Economics/Japan/J apanYes. I don't endorse or condemn what's written here, not that my endorsement or condemnation are worth jack.

"We see much more of this loneliness now. It's paradoxical that where people are the most closely crowded, in the big coastal cities in the East and West, the loneliness is the greatest. Back where people were so spread out in western Oregon and Idaho and Montana and the Dakotas you'd think the loneliness would have been greater, but we didn't see it so much.

The explanation, I suppose, is that the physical distance between people has nothing to do with loneliness. It's psychic distance, and in Montana and Idaho the physical distances are big but the psychic distances between people are small, and here it's reversed. ...There's this primary America of freeways and jet flights and TV and movie spectaculars. And people caught up in this primary America seem to go through huge portions of their lives without much consciousness of what's immediately around them. The media have convinced them that what's right around them is unimportant. And that's why they're lonely. You see it in their faces. First the little flicker of searching, and then when they look at you, you're just a kind of an object. You don't count. You're not what they're looking for. You're not on TV.

But in the secondary America we've been through, of back roads, and Chinaman's ditches, and Appaloosa horses, and sweeping mountain ranges, and meditative thoughts, and kids with pinecones and bumblebees and open sky above us mile after mile after mile, all through that, what was real, what was around us dominated. And so there wasn't much feeling of loneliness. That's the way it must have been a hundred or two hundred years ago. Hardly any people and hardly any loneliness. I'm undoubtedly over-generalizing, but if the proper qualifications were introduced it would be true.

Technology is blamed for a lot of this loneliness, since the loneliness is certainly associated with the newer technological devices...TV, jets, freeways and so on...but I hope it's been made plain that the real evil isn't the objects of technology but the tendency of technology to isolate people into lonely attitudes of objectivity. It's the objectivity, the dualistic way of looking at things underlying technology, that produces the evil."

-- Zen and the Art of Motorcycle Maintenance, Pirsig, Ch 29 (online here)

http://www.virtualschool.edu/mon/Internet/CerfHowI nternetCame2B.html ......

"Even at the beginning of this work we were faced with using satellite communications technology as well as ARPANET and packet radio. We went through four iterations of the TCP suite, the last of which came out in 1978.

The earliest demonstration of the triple network Internet was in July 1977. We had several people involved. In order to link a mobile packet radio in the Bay Area, Jim Mathis was driving a van on the San Francisco Bayshore Freeway with a packet radio system running on an LSI-11. This was connected to a gateway developed by .i.Internet: history of: Strazisar, Virginia; Virginia Strazisar at BBN. Ginny was monitoring the gateway and had artificially adjusted the routing in the system. It went over the Atlantic via a point-to-point satellite link to Norway and down to London, by land line, and then back through the Atlantic Packet Satellite network (SATNET) through a Single Channel Per Carrier (SCPC) system, which had ground stations in Etam, West Virginia, Goonhilly Downs England, and Tanum, Sweden. The German and Italian sites of SATNET hadn't been hooked in yet. Ginny was responsible for gateways from packet radio to ARPANET, and from ARPANET to SATNET. Traffic passed from the mobile unit on the Packet Radio network across the ARPANET over an internal point-to-point satellite link to University College London, and then back through the SATNET into the ARPANET again, and then across the ARPANET to the USC Information Sciences Institute to one of their DEC KA-10 (ISIC) machines. So what we were simulating was someone in a mobile battlefield environment going across a continental network, then across an intercontinental satellite network, and then back into a wireline network to a major computing resource in national headquarters. Since the Defense Department was paying for this, we were looking for demonstrations that would translate to militarily interesting scenarios. So the packets were traveling 94,000 miles round trip, as opposed to what would have been an 800-mile round trip directly on the ARPANET. We didn't lose a bit! ........"

(Copyright (C) 1993 Vinton Cerf. All rights reserved. May be reproduced in any medium for noncommercial purposes.)

Yes, I agree wholeheartedly in this particular case and for these particular patents. I don't necessarily agree in all instances and cases, however. But that's a different issue.

Java, unfortunately, is not the son of Objective-C, it is the son of Object Pascal and C++.

When seing "my college doesn't teach me anything useful" debates, I am always reminded of Robert M Pirsig's description of a university in Zen and the Art of Motorcycle Maintenance:

The real University, he said, has no specific location. It owns no property, pays no salaries and receives no material dues. The real University is a state of mind. It is that great heritage of rational thought that has been brought down to us through the centuries and which does not exist at any specific location. It's a state of mind which is regenerated throughout the centuries by a body of people who traditionally carry the title of professor, but even that title is not part of the real University. The real University is nothing less than the continuing body of reason itself.

What you IMHO should learn in university is to become part of that great heritage of rational thought. Or as other poster's have described it: "To learn how to learn".

PS. Great book BTW. It's really worth a read.
PPS. This might be a bit lofty view, when you have to get up at eight in the morning to go to classes ;)

.. that they are granted to the one who is first to patent office, and that close submissions of the same concept don't even count as showing that the invention was "obvious" to those working in the field:
http://www.virtualschool.edu/mon/ElectronicFrontie r/LaserPatentWars

Ah, here was the post I was looking for.
Object C, of course, was inspired by Smalltalk.

a) Java was DESIGNED for embedded systems, first and foremost. That's why it is hardware-agnostic; because it allows the hardware makers to throw in whatever chips are cheap in bulk at the time, change on a whim, and still push out the same upgrade to everyone. Being cross-platform in the MacOS/Linux/Windows way was just sort of a side-effect. Think about how much this will benefit set-top manufacturers!!

You can argue it was designed for embedded, but I won't. That was its original intention- I don't know about saying it was designed for embedded. Because Java is not open, "your slap Java on any chip" sounds great until you need a VM. Sure, there are nice free attempts, but you still have problems without your slow, memory hogging VM. Might as well screw deterministic memory- something more than necessary with realtime embedded systems. There are some nice attempts though- I've seen a theoretical maximum of 300 ms in some places for "sitting around" which isn't half bad. Show me a embedded device with a Java device driver. What about an unlaughable scheduler? Directly interfacing with interrupts? Anyhow, it's fun to go back and see how Sun at least had an embedded link compared to now. Where's it going?

b) Java isn't interpreted anymore... its just-in-time compiled and then executed as native code. A bit of a start-up pause while the classes compile, that's all.

Maybe JIT moved Java from being fully interpreted, but it's still interpreted and "compiled" at runtime making it theoretically (a.k.a Javaly) and realistically on average always slower and more of a memory hog than unnamed alternatives, that's all. But, sometimes that's ok right? Look at how Java has taken over the desktop application market where that least matters. How many Java desktop applications do you run? Can you tell it's Java? If programming will always be hard, one might wonder what skeletons in the closets Java fanatics have at the price of conformity to an interface. Java version incompatibilities, buggy VMs, oh my.

And here the British were supposed be good with sarcasm, but the point that interfaces in OOP have been done since time immemorial obviously escaped you. Regardless, it certainly is possible to have interfaces in Simula, by grouping the interface methods into a Class, having the interface class as an attribute on each Class "implementing" that interface, and delegating the instance methods to the enclosing class methods. Then you can test for implementation of the interface, access methods on the interface without knowing the concrete type or supertype(s) of the object, and it is inherited to subclasses.

I should hope your experts could come up with better ways to implement interfaces in Simula. In any case, the idea that Microsoft Research invented interfaces and that's where Java got them is simply wrong on any number of counts.

While we cannot yet convert arbi-trary English to fully specified code, we can use a reasonably expressive subset of English as a visualization tool.

Call it COBOL or call it an "English subset", but in the end, it's just like Brooks said in No Silver Bullet:

For almost 40 years, people have been anticipating and writing about "automatic programming, " or the generation of a program for solving a problem from a statement of the problem specifications. Some today write as if they expect this technology to provide the next breakthrough... automatic programming always has been a euphemism for programming with a higher-level language than was presently available to the programmer.

A database isn't tangible property.

I would agree with you, but look at how the court argued in United States vs Riggs back in 1990 (yes, the famous E911 BellSouth document case) about applying the "interstate transfer of stolen goods" rule to an electronic file. When the issue of tangibility was brought up, the court briefly compared the electronic file with "a colorless, odorless, and tasteless gas", arguing that the "interstate transfer" rule could reasonably be applied to the gas in spite of its "intangibility". Now, even an odorless gas does consist of very tangible atoms, and it seems to me like a rather weak argument for applying the law also to what is essentially a transmission of information. If a TV station broadcasts a movie without paying royalties, is that "interstate transfer of stolen goods" too?

In the E911 case, the "value" of the stolen document was heavily inflated, quoted as $79,499 when a paper copy was actually available from Bellcore for $13.

There are actually two pieces of intangible property involved here. One is the original work as such, the database that may have cost a lot of time and money to compile. The other is an electronic copy of said original, perhaps available for a modest fee. I believe that in both the E911 case and this AOL case, only the copies have been transferred. The difference is that copies of the E911 document was available for sale, while the AOL customer database appearantly wasn't. How do you determine the "value" of something that isn't legally available for sale? Are we talking black market prices with respect to the copy (what someone is prepared to pay for it) here, or estimated damages to the database owner caused by the misappropriation of the information in it?

When a copy of a printed book is stolen, the value is considered to be the retail price for the copy (and that copy is quite tangible). No license fee for a reprint or damages for copyright infringement is ever involved. If an original manuscript is stolen, that is quite a different thing. But if you make an unauthorized copy (on paper) of an unpublished manuscript?

On the other hand, that could make fraud easier, as you don't see suspicious swells or dips in the voter count. *shrug* Six of one, half a dozen of the other, and Seven-of-Nine.

Close, very close, but not quite right. The trigger is a single fission bomb; the radiation it produces is redirected cleverly so as to compress the fusion charge (a concept referred to as a "Hohlraum"). In some designs there are more than two "stages" where fission triggers fusion, which then is used to trigger more fission or, in some cases, another fusion stage (the Soviet "Tsar Bomba" was a multistage fusion device of 60-120 Mtons. Check out the Nuclear Weapons FAQ for more info.

The "neutron bomb" was a planned attempt to replace the fission warheads with chemical explosives, creating a thermonuclear explosion with no radioactive fallout- a truly impressive feat if it were possible.

Not the neutron bomb I'm familiar with. It was a very low-yield fission-triggered device that had a fusion stage. There has long been a dream at LLNL to figure out how to initiate fusion with a conventional high-explosive trigger, but to my knowledge, no such weapon has ever been tested or fielded. The neutron bomb of the 80's would have created plenty of fallout and radioactivity; the point was it created less blast damage and so didn't sound as bad (the fallout was sort-of ignored).

He is talking about the tritiated lithium hydride,....Since the bomb was lost 46 years ago, which is about 4 tritium half lives, the maximum possible yield has in theory been reduced to 1/16 of what it was in 1958, and the actual yield is probably zero.

I think there is a small mis-understanding here. A fusion weapon of this type uses tritium to boost the yield of the fission trigger, NOT as a component in the fusion main stage fuel. The fusion stage creates the tritum needed at the time of explosion by neutron-spallation of the Lithium. So, after 4 half-lives the fission trigger yield will be greatly reduced - probably enough to prevent any significant second-stage fusion. This means that if it exploded, the yield would be in the 10-kiloton range, not the megaton range. However, if the fusion stage were to ignite, it would do so with as much yield as ever.

Sorry, that link should be http://www.virtualschool.edu/mon/SoftwareEngineeri ng/BrooksNoSilverBullet.html

One of these days I'll learn to preview...

people that value such things as knowledge and spreading happiness

Ah yes, well we all do. But the question was, how do you measure such things? From there, you quickly get into the problem of trying to define quality, which some claim you just know already with out having to put a number on it, others turn into babbling idiots trying, and others solve the problem by just attaching dollar values to it.

Unfortunately for the romantic, we are economically dominated by the hard boiled scientific minded who insist on measuring and assigning dollar values to everything. If it can't be measured it doesn't exist.

She says:

It is widely known that few significant development projects, if any, finish successfully, on time, and within budget.

What bothers me about statements like this, is that no one is suggesting that perhaps our estimation and budgeting methods are off.

What if someone scheduled one week and allocate $100 for design and construction of a skyscraper, and when the engineers failed to deliver, who should be blamed? The engineers?!

Second, your example would be more apt if the building materials (steel and concrete) or the blueprints and construction tools were being blamed for cost overruns and schedule slips. No one would suggest that building skyscrapers would be easier and more reliable if the bricks and jackhammers were more intuitive.

What she is saying smacks of silver bullets (see Fred Brooks Mythical Man-Month, chapter 16: No Silver Bullets - Essence and Accident in Software Engineering (and succeeding chapters in the 20th Anniversary Edition)) and just can't be taken seriously. To summarize Brooks:

There is simply no way to take the programming and software engineering tasks and make them easy: they are difficult by their very essence, not by the accident of what tools we use.

It is true that software should be tested, however, testing doesn't asure the absence of bugs, it only shows that there were bugs for the code tested...

Read any Software Engineering book - It should give you some background as to what is really involved in "Software Engineering" - Programming is not Software Engineering or Development... Also, read "No Silver Bullet - Essense..." @ No silver bullet...

Software is very complex and the complexity is part of the software, hence, impossible (?) to assure it's reliability due to the factorial explotion of combinations...

is another evaluation ala Richard P. Feynman. Too bad he is no longer available, having shifted off this mortal coil... 'Unique perspectives' can be very enlightening. Feynman's Challenger Report

I read this article recently, and it pertains to this topic. (By pertains, I mean proves this guy wrong :) Check it out here. It was written in 1987, but it still rings very true today.

I actually did my PhD and Masters' work with the idea originally being to develop a visual or direct-manipulation (see Ben Schneiderman's stuff if you don't know the term) programming environment. You know what happened? I went to Fred Brooks' original "No Silver Bullet" presentation (see the paper to see the details) and found that I couldn't manage to refute his arguments. (I hate it when that happens. :-)

The basic argument is this: are the complexities of notation (language, whatever) essential or accidental aspects of the difficulties in programming? Brooks' argument is that the notation is an accidental issue -- that you can't gain, say, an order of magnitude improvement by chaning notation alone.

This is clearly not 100 percent true 100 percent of the time -- "drawing" a GUI with something like Powerbuilder, Eclipse, or JBuilder is clearly a lot more effective than coding it, even with EMACS. On the other hand, in real industrial development, actual coding is only about 15 percent of the total time and cost invested -- so no matter how wonderful the language is, it can't possibly account for more than about a 15 percent improvement.

There's no excuse for IIS, but you fail to appreciate the fundamental differences between software and traditional engineering. Don't confuse "complexity" with "difficulty". Your argument actually sounds a lot like Cox's response to Brooks, which blames the lack of market incentives to reuse modular components (in many, not all cases), but doesn't recognize other differences. Check out the Wikipedia summary starting with the "Software Engineering versus Traditional Engineering" section.

I'm of the opinion that our software engineering could be as reliable as other kinds, today, but that would involve a huge tradeoff in development time and a decrease in the rate of innovation. Windows is lame, but I'll remain pleased with the way things have turned out overall, so long as improvement continues to be made.

There's no excuse for IIS, but you fail to appreciate the fundamental differences between software and traditional engineering. Don't confuse "complexity" with "difficulty". Your argument actually sounds a lot like Cox's response to Brooks, which blames the lack of market incentives to reuse modular components (in many, not all cases), but doesn't recognize other differences. Check out the Wikipedia summary starting with the "Software Engineering versus Traditional Engineering" section.

I'm of the opinion that our software engineering could be as reliable as other kinds, today, but that would involve a huge tradeoff in development time and a decrease in the rate of innovation. Windows is lame, but I'll remain pleased with the way things have turned out overall, so long as improvement continues to be made.

The shuttle was a wrong design from the start and can't be fixed. Read this:

• Beam Me Out Of This Death Trap, Scotty
• Feynman on the Shuttle
• Pournelle on "Why have NASA"

Shuttle was designed to employ about 20,000 people. It met that goal admirably; you can't fly Shuttle with fewer people. It just can't be done.

Plus, it's rooted in object-oriented design. That, at the very least, is a step in the right direction (i.e. away from the long-term logistics nightmare of functional decomposition) . Keep in mind, however, it's not a method. What you do with it determines it's effectiveness.

Sheez yourself. I know they existed back then because I used them.

V42bis and MNP5 compression have been around since the early 90's. They have nothing to do with modulation techniques.

modem history

All you people who are interested in this article, you should read the book "Surely, you are joking Mr. Feynman!" To take a glimpse at the report that Feynman submitted after investigating the Challenger incident, Check Out Personal observations on the reliability of the Shuttle by Richard P. Feynman

One more post in this regard from TIME

Also, it's interesting to look back at Feynman's analysis of the Challenger case.

Concluding quote from the doc: "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled"...

This type of crap is getting really annoying. It's all BS, and I wish the major outlets would stop reporting it. Nothing is being lost! What's really happening is this: potential revenues are being unrealized. They're even projected revenues (note the word "estimates"?), which means the numbers are BS anyway. The truth doesn't sound nearly as sexy, does it? Much more sensational to say 'lost', 'stolen', and 'pirates are everywhere'. Put them all together for more impact (tell me if this sounds familiar):

"We're losing gazillions of dollars every year because we're surrounded on all sides by terrorist, anti-capitalist, stealing pirates who are trying to destroy our happy, profitable businesses."

Here's more BS from the article:
The industries argue that the lack of a coherent approach to protecting intellectual property in the digital environment has led to the rise of a black market in pirated material.

This is not an argument. Using my trusty BS-argument buster, I see that this kind of statement is actually the fallacy of non causa pro causa. But what is the cause they don't mention? To understand where black markets come from, you have to use economics. Black markets only develop where they are profitable, i.e. where the marginal price is higher than the marginal cost. This never occurs in a free market, but does happen when the market is regulated (take drugs, for instance) or when there are not enough players, which is clearly not the case here. In the case of drugs, active regulation drives up the marginal price artifically (it sucks to go to jail, and part of the price of your dime bag compensates your dealer for the risk they take). In the case under consideration, the marginal cost is being driven up by bad IP laws (which Microsoft and the content industry were so excited about, I might add).

This is the elusive flaw with their argument, and just goes to show that they created their own hell. Now they're complaining about having to live in it. Morons.

There is silver bullet. We must emulate the parallelism of hardware ICs in our software ICs. In a 1995 article titled "What if there's a Silver Bullet..." Dr. Brad Cox wrote the following:

Building applications (rack-level modules)
solely with tightly-coupled technologies like
subroutine libraries (block-level modules) is
logically equivalent to wafer-scale
integration, something that hardware
engineering can barely accomplish to this day.

I disagree with Dr. Cox, primarily because subroutine libraries have no analog in integrated circuits. The biggest difference between hardware and software is that the former operates in a parallel, signal-based environment, whereas the latter uses sequential algorithmic code. I believe that this is the main reason that hardware is orders of magnitude more reliable than software. My approach completely eliminates algorithmic coding from everyday software development.

Blame software unreliability on a software coding practice that is as old as Lady Ada Lovelace: the algorithmic code. I am convinced that, if we stop basing software construction on the algorithm, we can expect several orders of magnitude improvement in the reliability of our software.

This is exactly right. To assume that "software is generally of poor quality" insults many, many software developers. For example, the team who developed the avionics for the shuttle took huge and justifiable pride in a process which kept the software correct (see http://www.virtualschool.edu/mon/SocialConstructio n/FeynmanChallengerRpt.html and scroll down to the section on avionics).

But much software doesn't have to be written to such a high quality requirement, so it isn't. As, for example, document production isn't safety critical, market forces will decide the level of quality required, and the resulting market profile is a direct result of the care with which purchasing decisions are made.

Sorry to say this, but we get the software we choose, and the poor state of the market now reflect that we will pay loads of money for something which we buy effectively sight unseen, and where we accept licence agreements which take away our rights to complain.

Dunstan

No Silver Bullet In any case, software engineering is still ill-understand and fundamentally "fuzzy". People have unrealistic expectations about how software can be retrofitted. Despite out best efforts, I do not see software cost estimation becoming more precise in the near future.

Ofcourse, if you do 99% of the software development without coding, and then do clean room development for the coding, you may be able to estimate that phase fairly well. But, the overall project will still take a very difficult to determine ammount of time as a whole.

It's great to see physicists with integrity rather the embarasment to the field perpetrated by Drs. Martin Fleischmann and Stanley Pons in March 1989 when they claimed to have devised a process to produce cold fusion.

--CTH

Incidentaly, the idea that the use of comptuers by the government helps contribute to the demonization of cracking/hacking isn't just fluff. Check out this article

everything revolves around the 'process'. The result is determined by the process.

I'm working on a large NASA project now. I have determined that the purpose of this project is not to produce a working software system, but rather to produce a wall full of loose-leaf binders of incomprehensible documentation that no one will ever refer to again.

The process says we must have code reviews - great! But instead of being an analysis of the logic of my code, it turns into a check against the local code formatting standards - "You can't declare two variables with one declaration, use int a; int b; instead of int a,b;" (yes, that's an actual standard around here) instead of "Hey, if foo is true and bar is negative, you're going to dereference a garbage pointer here!"

The forms are observed, but the meaning is forgotten, like Christians going to church on Sunday then cutting people off and flipping them the bird on the drive home.

"Process" won't save us. Which doesn't mean that a certain amount of it can't help, but there is no silver bullet.

Firstly, "intuitive" is a slippery word. There's "intuitive for power users", "intuitive for somewhat experienced users", and "intuitive for newbies". Some would say the last category is the empty set.

Metaphors are the key. Read John Lawler's 1987 lecture "Metaphors we compute by" for a quick intro on metaphor and metaphors in computing. The situation has unfortunately changed very little in the last 13 years. George Lakoff's book "Philosophy in the Flesh" shows how metaphors actually are the basic working units of the mind, and that all basic metaphors are based on sensory-motor concepts - in fact, sensory-motor neurons very probably do double duty as metaphor processors.

So, as long as one bases GUI metaphors on basic sensory-motor stuff - things like "time is space-like" (progress bars), "nearer means on top" (overlapping windows), and so forth - you have some chance of being more newbie-intuitive. I've used a prototype ancient GUI where scrollbars worked the other way around; the thumb moved down to scroll up for some reason the designer considered compelling, and it was pure hell to use. Needless to say it didn't survive.

Now, something I've noticed in most (thankfully not all) replies here is a restricted understanding of what a GUI should do. Yes, having icons represent files is useful; installing by running a single program and marking off some options is useful; using menus is often useful. But that's only a small part.

I've released an application for the Mac OS recently. As long as one uses the standard system calls, one gets the expected GUI functionality for basic items - that is, menus work like a Mac user thinks they should, windows drag, roll up, close and whatever. But I spent very little time on that - thanks to a neat C++ framework called PowerPlant - and spent much time making sure other things worked as Mac users are used to.

For instance, placement of the exact hot spot in cursors is important. Shift-click selection of long sections of text is important. Exact timing and graphical progression of drag-and-drop is important. Wording, defaults and back-out options in dialog boxes, sound cues, selection behavior - the list is very long. And the extra time spent on subtleties was rewarded by a five-star review where the reviewer said "I love using this program, but it's often hard to say why unless I watch very closely".

When I'm using CAD software I'm often forced to use Windows NT, and frankly, it's terrible. People argument there are Microsoft UI guidelines, but it seems most people either don't know them or think they're unimportant. For instance, in the PCB layout program I'm using right now, if you select a library component to place on the layout, you select the component from a list - OK, the cursor changes to a translucent image of the component - also OK, but if you want to click on the scroll bar to place the component somewhere else, the component is placed _under_ the scroll bar with no visual indication that the scroll bars are inactive! If you click on a tool palette the component is placed under the palette! If people don't think this sort of flagrant misbehavior is important, are they likely to worry about more subtle things? No way...

So, what the original article says about "skins" being just skin deep is very accurate. Most Linux programmers seem naturally disdainful of graphic interfaces and therefore are slapdash in implementing one. And reaching consensus among a large group about any particular GUI feature is nearly impossible. This is definitely a field where the "absolute dictator" method is the only one which may work - granted it may also fail spectacularly.