Slashdot Mirror

This is already being done. Many of the most successful FOSS projects have corporate contributors, so this "design conundrum" doesn't really exist.

That's not how I read it. FOSS projects have corporate contributors as a weapon used to commoditize their rival's products. (IBM versus Sun, to make it impossible to monetize Java) FOSS projects are also funded in order to create commodity complements to company's products. Sell servers? Commoditize software that runs on servers!

http://www.joelonsoftware.com/articles/StrategyLetterV.html

There's a problem with this. It reduces FOSS to ammunition. A tactical move. If FOSS can't produce really slick interfaces, then FOSS will always be a lackey of the corporations in order to achieve first-rate success. If the corporations don't like you or can't use you, then you're left out in the bush leagues, the farm teams. Just look at the software out there. Almost every piece of software that gets widespread corporate or consumer traction is being used as a weapon or market driver.

In fact Apple, like it or not, is a pretty good example of how to monetize FOSS. Can't say I'm thrilled with the methods they employ to achieve that, but it's still a fact that they do achieve it.

The problem is that it makes FOSS critically dependent on the corporate masters if a particular project wants to be "first-rate." It's as if FOSS is like indy music/film, and the corporations are the music industry, and everyone is trying to get signed. Maybe that's how things should be. But it would be better if we never had to admit, "can't say I'm thrilled," about how our funders are treating our ideals. FOSS needs its equivalent of bittorrent, Pirate Bay, and independent musicians who can give the finger to the big music distributors, yet still turn out first-rate product. Where's our Protools for interfaces? (Actually, the problem is likely cultural and not technological.)

I came across this article a few days ago and it's worth a read in this context.

http://www.joelonsoftware.com/articles/fog0000000339.html

Basically, this person's observation was: once he gets started, it's easy going, he's able to keep working; the key is to start as early in the day as possible on the real work.

Apart from this, from personal experience -

1. Try working with the internet off - disable proxies if you need one to connect to it, or switch off your router/modem after downloading any online documents/documentation that you need to refer to.
2. Keep water/soda/snacks near you so you don't have to get up to drink or eat. Even better if you work in the bathroom.
3. Start with core functionality that can be unit tested. Leave the bells and whistles for later. Small parts that work give a great kick and motivate more.

All the best for your project.

I admit no knowledge of Blackberry phones or their apps. Your detailed account of development was super-interesting and I wish you the best of luck. Just one comment:

You've been trying to contact Audible but they're not returning your calls. Reminds me of this:

http://www.joelonsoftware.com/items/2009/06/10c.html

Maybe Audible doesn't want to help you because they want to implement what you've already done?

Basically what the parent poster is pointing out is that absolutely any metric that management can come up with can be fooled.

For instance, now that you know that "time to close the ticket" is the metric, you can always close the ticket and then go work on the problem rather than the other way around. Or if it's an average time to close, you can get a pal who works in another department to open up a bunch of phony tickets for you to resolve quickly.

To quote extensively from Joel Spolsky:

Robert Austin, in his book Measuring and Managing Performance in Organizations, says there are two phases when you introduce new performance metrics. At first, you actually get what you wanted, because nobody has figured out how to cheat. In the second phase, you actually get something worse, as everyone figures out the trick to maximizing the thing that you're measuring, even at the cost of ruining the company.

Worse, Econ 101 managers think that they can somehow avoid this situation just by tweaking the metrics. Dr. Austin's conclusion is that you just can't. It never works. No matter how much you try to adjust the metrics to reflect what you think you want, it always backfires.

For the record, your facts are wrong.

There was NEVER a time when IE6 was the only browser. Did you forget about Netscape? (all over the post you JUST replied to?)

IE6 was the best browser because it REALLY WAS the best browser, it wasnt because it was "the only browser." You are either ignoring history on purpose (because you don't like it,) or you are ignorant but feel like having a vocal opinion on the subject you are ignorant about anyways.

Netscape had all the advantages, being pushed by the largest internet service, AOL. Availability wasn't even an issue, since you couldn't help but recieve dozens of AOL CD's (in the mail, at grocery stores, colleges, and so on and on.) The average first timer "got online" by installing Netscape and giving AOL their credit card number.

You claim that "firefox has proven that the only thing keeping back innovation was IE," yet IE is *still* bundled with Windows.. but there it is.. Firefox has a very respectable market share in spite of it. You are just imagining that innovation was held back by I.E. when the reality was that Netscape fucked up and did a 100% rewrite. The lag in innovation was a direct result of the competition WILLINGLY taking YEARS to reinvent the wheel. They threw away FOUR YEARS of work and THEN took another SIX YEARS to catch up. By my math, thats a whole decade wasted, not by Internet Explorer, but instead by the Netscape/Mozilla team.

The facts are right there. Internet Explorer enjoys the momentum it has not because of bundling, but because the competition really REALLY fucked up. The single worst strategic mistake that any software company can make.

That is not the hallmark of simplicity.

Let me quote what Joel On Software wrote about Ozzie and all this "Mesh" thing:

And now Ray Ozzie's big achievement arrives and what is it? (drumroll...) Microsoft Live Mesh. The future of everything. Microsoft is "moving into the cloud."

What's Microsoft Live Mesh?

Hmm, let's see.

"Imagine all your devices--PCs, and soon Macs and mobile phones--working together to give you anywhere access to the information you care about."

Wait a minute. Something smells fishy here. Isn't that exactly what Hailstorm was supposed to be? I smell an architecture astronaut.

And what is this Windows Live Mesh?

It's a way to synchronize files.

Jeez, we've had that forever. When did the first sync web sites start coming out? 1999? There were a million versions. xdrive, mydrive, idrive, youdrive, wealldrive for ice cream. Nobody cared then and nobody cares now, because synchronizing files is just not a killer application. I'm sorry. It seems like it should be. But it's not.

But Windows Live Mesh is not just a way to synchronize files. That's just the sample app. It's a whole goddamned architecture, with an API and developer tools and in insane diagram showing all the nifty layers of acronyms, and it seems like the chief astronauts at Microsoft literally expect this to be their gigantic platform in the sky which will take over when Windows becomes irrelevant on the desktop. And synchronizing files is supposed to be, like, the equivalent of Microsoft Write on Windows 1.0.

It's Groove, rewritten from scratch, one more time. Ray Ozzie just can't stop rewriting this damn app, again and again and again, and taking 5-7 years each time.

And the fact that customers never asked for this feature and none of the earlier versions really took off as huge platforms doesn't stop him.

Netscape didnt die because Microsoft worked to remove it from OEM's.

Netscape died because its developers were morons. Complete and utter morons. Not only was 4.0 a complete turd, but 6.0 was the single worst strategic mistake that any software company can make.

You anti-microsoft zealots sure like to rewrite history.

An excellent way to state the architecture astronaut point of view. Now, if you could just spice it up a little, put it through a few iterations that make it more obscure and difficult for us plebs to understand...

Netscape destroyed Netscape, and Sun destroyed Java. (At least for Windows GUI apps.)

Netscape released years and years worth of shitty, buggy products. With apologies to Joel Spolski*, their release plan basically was "if it builds, release it. If a bug big enough to hit the press surfaces, hotfix it." Netscape decided to spend their time dinking around with email, chat, newsgroups-- basically shoveling every piece of shit into their flagship product they could-- instead of making it fast and stable.

The instant IE stopped sucking, people switched over in droves. (And as proof that OS bundling wasn't nearly as big a factor as Netscape claims: the exact same thing happened on Macintosh computers, even though Apple included *both* IE and Netscape on the system disk.)

Then, as if they weren't already mis-managed enough, Netscape decided to throw their entire product in the dumpster and start over from scratch. They went, what, three and a half years with no release?

Sorry, the simple fact of the matter was that Netscape was run by idiots. They had some early successes, but the only thing really propping them up from day one was the hype surrounding the web itself.

Sun's Java was killed due to these two facts:
1) Sun was telling everybody Java was a write-once-deploy-everywhere product for GUI apps.
2) Java's OS integration sucked ass. (Even now, a decade on, Java's OS integration sucks ass.)

Microsoft made the stupid error of believing that Java was salvageable, so they added extensions to it to make it suck a little bit less at OS integration. Of course, what ended up happening, is that developers would write their Java apps to depend on those extensions and thus make them incompatible with Java on other platforms. If Sun had gotten their ducks in a row with Java from day one, Microsoft wouldn't have had to extend the language.

Now I'm not saying that there's anything wrong with Java for server development, and yes I know that there are 50 kajillion Java products out right now, etc etc. But for GUI development, Java was still-born.

* Too lazy to look up the specific links, but Joel has several articles about Netscape's strategic mistakes on his site: http://www.joelonsoftware.com/

Windows 95 and 98 (and probably the first NT/2000 versions) had a famous bug, which was that the computer was unstable after 49.7 days.

http://discuss.joelonsoftware.com/default.asp?joel.3.9430.16

49.7 days corresponds to 2^32 milliseconds.

What was recommended was to reboot your computer more frequently, not very bad for uptime records.

Let's note that I still have similar bugs on my laptop, where IIS tends to be unresponsive when I put the computer in standby mode two or three days consecutively.

Netscape had the market volume and could easily have survived a few bad versions with their market share. However Microsoft made sure that didn't happen.

Microsoft was not in a position at the time to bury Netscape. They did it themselves.

Way back in April, I wrote that Netscape made the "single worst strategic mistake that any software company can make" by deciding to rewrite their code from scratch. Lou Montulli, one of the 5 programming superstars who did the original version of Navigator, emailed me to say, "I agree completely, it's one of the major reasons I resigned from Netscape." This one decision cost Netscape 3 years. That's three years in which the company couldn't add new features, couldn't respond to the competitive threads from Internet Explorer, and had to sit on their hands while Microsoft completely ate their lunch.

The 20 to 30 apps you'll be breaking are not MS apps, but are (usually misbehaving) third party apps. Read the SimCity example from Joel.

It will be a long time before Wine will have this level of compatibility.

I'd recommend reading Joel Spolsky's bit on the effect of keeping up with the current trends on the .NET framework:

http://joelonsoftware.com/articles/fog0000000339.html

Posting anon, but I was a robotics researcher for many years.

Arkin does a lot of very abstract, and somewhat pie-in-the-sky stuff. He's developed many theories about how robots should operate, but they end up being drastic oversimplifications for someone trying to produce a working robot. The real robots his groups have programmed haven't really done much, when compared to other research robots, because Arkin takes an "architecture over practical function" approach. This is not unlike the over-design people you might meet in software development, in particular Joel Spolsky's Architecture Astronauts. Don't get me wrong, many of his ideas do have worth, and have influenced those doing practical robots, but it's just that his architectures not the silver bullet they often get sold as, and are not a good starting point for a non-toy robot.

Also, Arkin is pretty good at writing convincingly, and thus pulls in a lot of funding, in particular from government and large industry; commissioned reports like this are a specialty. I remember hearing about his work on ethical military robots a few years ago. There are good rules to be implemented there, however by *far* the more important thing is improving sensor and classification accuracy -- If you can't identify friend-or-foe, the majority of the rules and abstraction are useless. Once we have sensors that work better, which is a tremendously hard problem, then the rules will be pretty simple in comparison. Not to mention that much of those rules can be brought from the *existing* protocols the military has for humans; modern soldiers are given very specific rules of engagement.

Sorry for the rant, but it gets annoying to hear about this sort of thing over and over again, knowing that Arkin looks down on research like mine that produced robots measured objectively (in competitions like the Darpa Grand Challenge), while his abstract architectures never seem to turn up on anything real. The hard stuff is at the periphery, vision, other sensing, localization, etc.

The real cost is in the time it takes to prepare the book. It's not fair to compare the cost of a data compression book with, say, a romance title. The size of the markets is vastly different. I would be happy to sell my data compression book at the price of a romance novel if I could sell as many copies.

The money and time it took to prepate the book is called a sunk cost. The market does not care one bit about sunk costs. Apparently, people will not buy it at the price you asked, they either have a choice of doing away with the information or pirate the book. Maybe you could invite people who do that to give you what they feel is fair? If I only need one or two chapters from your book and send you five bucks, it's five bucks you would never get if you stuck to $41 or nothing.

Oh and you should read this article about setting prices.

IE: Bundled with OS. Managed to obtain marketshare due to anti-competitive behaviors that put Netscape out of business

They lost becase, as Joel Splosky put it, they made the "single worst strategic mistake that any software company can make...

...they decided to rewrite the code from scratch."

Damn you for making me reference Joel On Software
http://www.joelonsoftware.com/articles/StrategyLetterV.html

If you're not willing to read most of both sites, I'd say that your answer regarding CS grad school should be "no." Any form of grad school requires an enormous amount of reading, and the amount you should do in preparation ought to in part tell you whether you should go.

Run virus.exe in XP (SP2), Vista, or (I presume) 7.

What's that box? A security warning about unsigned code?

Rename the file to virus.txt.exe and try again.
What's that box? A security warning about unsigned code?

Fuck off insecurity experts.

Too bad users don't read dialog boxes

This meme is getting very old. If you had developed a piece of software that was 80% of the way to being the product you wanted it to be (ie Vista, which was released before it was actually ready, as has been widely reported), you would have to be insane to rewrite it from scratch. In fact, one of the problems with Vista was that so much of Windows had been rewritten from the XP codebase, things which used to work just fine no longer did (eg file copying, System Restore...).

I'm glad W7 shares the Vista codebase, and very glad it has gotten no slower. Call it Vista 1.1 or whatever you want, but don't try to imply that's a bad thing.

Further reading: http://www.joelonsoftware.com/articles/fog0000000069.html

Make it shiny, we will fix the bugs later! Of course later never comes, eventually the crap piles up too high and somebody decides to just start over. Which explains the piles of discarded stuff and the new one that also doesn't quite work in most areas, especially in system administration.

Ah, yes, that would be the CADT development model: http://www.jwz.org/doc/cadt.html

Also be sure to read Joel Spolsky's article helpfully titled "Things you should never do": http://joelonsoftware.com/articles/fog0000000069.html

> Blizzard ... could use that money to create a WoW sequel that would be the most technically complex game ever made, with the best graphics and most sophisticated AI ever put in a computer game.

As Joel Spolsky points out, the worst mistake a software company can make is to rewrite software from scratch. There used to be argument that new code was better code because the programmers were building on what they learned from their first version. But in practice, old code is *tested* *working* code, far superior to new and untested. (Ever debugged? Argh!) Plus writing from scratch risks burning out your experienced developers aka "Boss, it's time for me to find a new challenge". A better idea is to incrementally enhance the code over time. In ten years you wouldn't recognize it anyway, and it'd be far better than any Wow 2 written from scratch could be.

http://www.joelonsoftware.com/articles/fog0000000069.html

Full Hungarian notation is a bit redundant, precisely because everyone (for reasonable values of 'everyone') DOES use some form of IDE to code, and any non-epic-fail IDE will at the least tell you variable types when you mouse over them, or pop up a member list for a class/struct when you go to type them.

Um - Hungarian notation is for coding what the variable represents, not the type of variable it's represented by.

Anyone using iVariable or sVariable to indicate that the former is an int and the latter is a string is doing it wrong.

It's this misunderstanding that's resulted in HN's 'bad' reputation.

See http://www.joelonsoftware.com/articles/Wrong.html for an example of how HN should be used.

There's no such thing as "standards compliant" in the real world web.

and as we all know researchers are always the first people to be innovative right? It's not like they hide in their huge university organisations being unproductive where they can pretend to be knowledgeable however wouldn't be able to even land a job in the outside world.

These kind of people are buffoons or as Joel Spolsky would call them, Architecture Astronauts.

Heh. More seriously, as Joel points out:

Microsoft has an incredible amount of cash money in the bank and is still incredibly profitable. It has a long way to fall. It could do everything wrong for a decade before it started to be in remote danger, and you never know... they could reinvent themselves as a shaved-ice company at the last minute.

It's good to see a hint that this fall might finally be starting, but even in this economy, it will be a long time before Microsoft dies.

The detail that I found most interesting is that their revenues dropped by only 6%, but that knocked their earnings down by 32%. This means that, if the company continues to face revenue pressures, they'll continue to spend a lot of cash. Unless they take steps to reduce their costs, they're going to burn up a lot of capital just to continue existing.

The solution is pretty straightforward, of course: Cut costs. But corporations tend to be most vulnerable when their managers start applying their Ivy League MBA wisdom to this excruciatingly difficult problem. Expect turmoil, a good deal of churn, and a lot of their top talent to start looking for greener pastures.

None of this necessarily changes your conclusion that Microsoft is going to be around for a while yet. But what interests me most is what kind of Microsoft will survive.

This all comes as Microsoft posts quarterly sales that have fallen for the first time in the company's 23-year history.

This is a perfect opportunity for trash talk! Suck on failure, Microsoft! Sales looking a little limp this quarter? I guess that's why they call it both micro and soft!

Heh. More seriously, as Joel points out:

Microsoft has an incredible amount of cash money in the bank and is still incredibly profitable. It has a long way to fall. It could do everything wrong for a decade before it started to be in remote danger, and you never know... they could reinvent themselves as a shaved-ice company at the last minute.

It's good to see a hint that this fall might finally be starting, but even in this economy, it will be a long time before Microsoft dies.

http://www.joelonsoftware.com/items/2008/01/22.html

You are exactly right. People like what they are used to. More importantly, they'll even think inferior things are superior, due to familiarity. Here's a good link that explains it better than I can: http://www.joelonsoftware.com/items/2007/06/12.html

Read this, then rethink your stance a bit. It's fine to START a company with just geeks, and it's great to allow geeks to decide where things go, but you need the business folks to handle the parts geeks can't (or more likely don't want to) deal with due to time constraints.

And yet, how many of the programmers you conclude cannot program because of how they handled the test have in fact written successful software for years?

Not a one. People who've been "successfully writing software for years" are interesting people with an interesting history and skills to back it up. They're the ones I hire. The ones who have been faking it for years are the ones that fail.

I understand where you're coming from. We've all been in a situation where a company had a stupid or unfair screening process that eliminated the best candidates rather than the worst. Please don't project that on what I and my colleagues are doing. We give the candidate every possible opportunity to show their competence. (As I said, "failing" the test I give is pretty damned hard for anyone who can code.) If they can't even code a loop, three if statements, and some Sysouts, I don't want them. These are the people who have trouble with System.out.

What you need to realize about what I'm saying is that the good (or even decent or mediocre) programmers are hard to find. The vast majority of people you'll talk to can't code their way out of a paper bag. Joel on Software had a piece a few years back that explained why this is:

http://www.joelonsoftware.com/items/2005/01/27.html

[W]hen you get those 200 resumes [magically sorted from best to worst], and hire the best person from the top 200, does that mean you're hiring the top 0.5%?

"Maybe."

No. You're not. Think about what happens to the other 199 that you didn't hire.

They go look for another job.

That means, in this horribly simplified universe, that the entire world could consist of 1,000,000 programmers, of whom the worst 199 keep applying for every job and never getting them, but the best 999,801 always get jobs as soon as they apply for one. So every time a job is listed the 199 losers apply, as usual, and one guy from the pool of 999,801 applies, and he gets the job, of course, because he's the best, and now, in this contrived example, every employer thinks they're getting the top 0.5% when they're actually getting the top 99.9801%.

Now will you please stop casting me as the bad guy? I'm not the one who asks you to figure out the Metallica problem or place 8 queens on a checkerboard. That stuff is stupid, useless, and weeds out the best candidates. I'm the guy looking for candidates who will look at me strangely when I ask them to write "Hello World". I'm not going to ask you to quote documentation from memory, nor am I going to ask for a copy of Quake by lunchtime. I'm just going to ask for a little bit of logic. Nothing more, nothing less. Most programmers here on Slashdot would qualify without any trouble.

As a personal exercise sometime, try writing out the solution to FizzBuzz. You may gain a greater appreciation for it as a tool. Remember, the output should look like "1 2 Fizz 4 Buzz Fizz 7 8 ... 13 14 FizzBuzz 16 etc." Simple.

My father made this observation:

"Old doctors and old lawyers are like old wines. Old engineers are like old fish fillets."

There probably is some outright age-ism out there, although I haven't had it smack me in the face yet.

But I suspect that what is much more common is a desire for the latest shiny technologies. When I went to school, Java hadn't been invented yet, and most of my classes were taught in Pascal. The colleges now are presumably teaching the new cool stuff. So, while you will be 35, you will be 35 with a fresh degree.

As I would advise any college student considering a computer career, I recommend you do projects on the side as much as you can. Find an open-source project, learn your way around it, contribute a few lines of code. Figure out what your college isn't teaching you, and study it on your own. For example, if your school teaches only Java and you don't get any assembly language or C programming, study that on your own. Joel (who writes Joel on Software) says he won't hire anyone who doesn't know how to work with pointers; he may be an extreme case, but knowing pointers can only help you.

Study the want ads now, and try to figure out what the employers are looking for; make sure you are learning it. But you can't learn everything... I don't have any Visual Basic experience, and I was never interested in the jobs that require it. So I guess what I'm saying is, try to figure out an area you would like to be qualified for, and get the skills for it.

I highly recommend you study Python; a good book that walks you through the whole language will expose you to some cool stuff. Other people would urge you to study LISP; that will stretch your mind a bit. (When I was playing with LISP, I used the book The Little Schemer, and the DrScheme environment to run my code.)

The point of the last few paragraphs is to make you stand out a bit when you have your degree. You won't just be a 35-year-old with a fresh degree, you'll also be able to write cool Python scripts, juggle C pointers, maybe write mind-stretching LISP functions. I believe those sort of extras will help someone decide to hire you.

If you have to work full time and support a family while going to school nights, this is going to be hard. I have a friend doing this right now, and sometimes he does his homework from midnight to 4am, then gets up and goes to work. He's doing it and he's probably ten years older than you, so I'm sure you can do it too.

The good news is that if you are really right for a computer software career, and it is right for you, you will actually enjoy a lot of your work. Building software projects and watching them actually start to work is a special pleasure.

steveha

Shouldn't Microsoft buy it?

Look MS doesn't have an Enterprise API anymore.

(see http://www.joelonsoftware.com/articles/APIWar.html)

Why not buy Sun and get into the high end server business?

In the process they buy and control Java (what they wanted all along).

C# and Perl pay my bills right now, but I was hired based on an interview question that was something like "how do you reverse a linked list?", which is a classical pointer question. As Joel puts it:

I've come to realize that understanding pointers in C is not a skill, it's an aptitude. In first year computer science classes, there are always about 200 kids at the beginning of the semester, all of whom wrote complex adventure games in BASIC for their PCs when they were 4 years old. They are having a good ol' time learning C or Pascal in college, until one day they professor introduces pointers, and suddenly, they don't get it. They just don't understand anything any more. 90% of the class goes off and becomes Political Science majors, then they tell their friends that there weren't enough good looking members of the appropriate sex in their CompSci classes, that's why they switched. For some reason most people seem to be born without the part of the brain that understands pointers. Pointers require a complex form of doubly-indirected thinking that some people just can't do, and it's pretty crucial to good programming. A lot of the "script jocks" who started programming by copying JavaScript snippets into their web pages and went on to learn Perl never learned about pointers, and they can never quite produce code of the quality you need.

How does that make it cool? It sounds more like desperation.

It's also what got us into the whole Java School mess.

I see this argument occasionally on /. and always find it more than a bit puzzling: if software that you think is "bloated" continues to be used (and to be sold to people willing to pay for it), then it must be of more value to its users than whatever hypothetical small and beautiful software that you're imagining. In fact, Joel Spolsky wrote a pretty good article called Bloatware and the 80/20 myth attacking the very line of thinking you're espousing.

I can't believe something so short sighted is modded insightful.

If a developer's machine takes too long for some non-interactive activity, they'll stop paying attention (probably to read the onion or something #9). Or *cough* post on Slashdot, then lose track of time and not get back to work for hours.

So what if a for loop isn't as optimal as it could be? These days the difference between optimal code and good code is usually too small to be measured in anything but milliseconds; and thus, not very important (link quotes Martin Fowler's PDF).

Contrast this with losing hours of usefulness from extremely expensive equipment (read: good developers).

I've read couple of these books, but not "Outliers". I found a bit annoying but couldn't place my finger on it until I read Joel's Review. He's right on the money - the author just states the obvious.....

Perhaps you should read this article written years ago that explains it very nicely.

It's true. Null terminated strings are slow, and they suck in lots of ways.

Holy flippin' crap. The company I work for has around 140 employees, with about half a dozen locations (a couple are even in different states). Our IS department consists of 4 people, including myself. Our rate of help requests is several orders of magnitude smaller than what you're describing.

There is something seriously out of whack, and I don't think it's the help desk software. I strongly recommend you and your cohorts read Joel Spolsky's Seven steps to remarkable customer service. Step 1 is of particular relevance here, but there's no reason not to read the other six steps too. You have to look at not just "How do I solve this user's problem?", but also consider "How do I either prevent this problem from happening in the future, or at least lessen the user's reliance on the help desk in solving it?"

Users are inherently lazy. This is not some anti-social commentary on the sad state of society, it's the simple truth. We prefer to find the easiest way to get something accomplished, and if you make it easier for them to ask you for some data, or how to do something in your ERP software, as opposed to running a report on your intranet site, or reading a manual or FAQ, then that is exactly what they will do, and you won't be able to get anything done besides act as a natural-language front end to your information systems.

Here's my take: Microsoft took 6 years to release Vista. While I realize they're hemorrhaging market share (how sad), they should consider taking a bit of time to meet as many user needs as possible. The end result will be a product that people actually want to use rather than Vista with a little less suck.

Of course, that would require a re-engineering of the development philosophy. Longhorn/Vista was a perfect example of how "too many cooks spoil the broth". Microsoft needs to get back to being customer-focused if they want to compete.

Nah, I bet their accounting staff are using Excel, and came across another bug such as this one.

Good article on Joel on Software about the IE8 standards mess: http://www.joelonsoftware.com/items/2008/03/17.html

If you are considering the "money" suggestion you should probably keep the quirks of human psychology in mind. Excluding the stone-cold-homo-economicus types(who are fairly rare in practice), most people can be motivated for almost no money, or a good deal of money; but often won't be motivated by just a little money.

A lot of people voluntarily do valuable work, or come up with valuable ideas, for essentially no money, because there is something else that hooks them. Think Free Software people, various sorts of volunteers, people who do more than they need to at work, and so on. People will also, obviously, be motivated by large amounts of money(large being a relative measure).

The middle ground, though, can be a bad idea. People think about economic and non-economic activity differently. Somebody who would submit a linux kernel patch for free might well be insulted if they were offered rentacoder rates for their work. Somebody who will voluntarily suggest a valuable process improvement just because he takes pride in his work would probably not be pleased by a toaster. This is a somewhat interesting piece on the subject.

Either you create an environment that gives people the social warm and fuzzies(this includes paying decent money; but relies on social factors) or you give people real rewards to motivate them. Nobody on a professional salary is going to innovate for condescension and peanuts. They'll innovate because the environment is good and they want to, or for real money.

The idea is to make multiple versions, so you can sell the cheap version to people who can't or won't afford the normal version, and the normal version to people who can. If they had only the normal version, the "cheap" people would buy nothing. If they make the normal version cheaper, everyone will buy it, including the people who where willing to pay more. This way they can maximize profit. See http://www.joelonsoftware.com/articles/CamelsandRubberDuckies.html for a very good explanation of this principle

"One linux to rule them all" reeks of Architecture Astronauts. Yes oneday we can achieve this, but until you can fit the same desktop on my mini cell phone, you just can't do it.

The limitation is the hardware, not the software. If this wasn't true why is Intel even creating the Atom cpu platform? Why can't the iPhone run true OSX (do you Linux geeks really want to take on the BSD people?)

The Development Abstraction Layer

Joel Spolsky has a good article that touches on this (figuring out how people actually use your program):

http://www.joelonsoftware.com/uibook/chapters/fog0000000065.html

Create a fast drawing program
Build a real-time spell checker with wavy red underlines
Warn users that they are going to lose their work if they hit the close box of the browser
Update a small part of the display based on a change that the user makes without a full roundtrip to the server
Create a fast keyboard-driven interface that doesn't require the mouse
Let people continue working when they are not connected to the Internet

These are not all big issues. Some of them will be solved very soon by witty Javascript developers. Two new web applications, Gmail and Oddpost, both email apps, do a really decent job of working around or completely solving some of these issues. And users don't seem to care about the little UI glitches and slowness of web interfaces. Almost all the normal people I know are perfectly happy with web-based email, for some reason, no matter how much I try to convince them that the rich client is, uh, richer.

And these issues shrink all the time. I agree with Joel regarding rich clients--I use Mail.app for e-mail, but virtually no one else I know does. Photoshop and Final Cut Pro aren't moving to the web anytime in the short to medium term, but other apps will, and it's hard to see this guy's ideas mattering. Sure, they might be true, but the web is still more convenient. For me, it's become a central repository for book and other commentary in the form of The Story's Story and write about grant writing at Grant Writing Confidential. Yeah, I write my posts in Textmate, but most people don't--and most people aren't going to buy and install Textmate.

sacrificing the bells and whistles that are offered by conventional software that hardly anyone uses anyway

I think if you took out all the features that 'hardly anyone uses' you wouldn't have much of a product left. Bloatware and the 80/20 Myth