It's odd you should say this, because I've had a Windows guru/sysadmin try several times to get this working (with his Dell running XP), and every time he's given up after about 45 minutes of messing with configuration settings. I myself tried it on both of my work-issued PCs (an HP and a Lenovo, both running XP) and found it completely impossible. Of the many Windows users I know, none have ever successfully used their laptop as an AP or a reverse bridge (providing connectivity over ethernet from a single wireless connection).

Therefore, you are either lying, or a statistical anomaly. I trust you're recounting the story accurately, so I'm going to conclude that your success is the exception rather than the rule.

I dunno, I think that if Windows is your biggest concern, you've clearly figured out all the other more important aspects of life, and therefore you've probably got a better grip on the world.

;-)

I think Shuttleworth's basic premise is completely sound -- I know from experience that watching actual users, in the field, using my 'well-thought-out' and 'intuitive' software, found it much less intuitive and well-thought-out than I did. It was a valuable (and, yes, painful) learning experience. The problem I see is that he suggests putting the software in the hands of user interface experts, which are even worse than developers at predicting how real users work.

I've read lots of articles written by usability experts that talk about idioms, efficiency, doing what the user expects, etc. etc. And that's all great, except that it's wrong. If you follow the experts, then you get in a habit of saying "users are used to software X, so if we want to make our software easy to pick up, we'll make it use the same idioms and concepts as software X." Out in the real world (yes, I worked there for a while, and yes, it was painful), people are asking themselves, "why, for the love of god, does every piece of software do this same stupid thing?"

In every conversation I've had with a well-educated, progressive developer about usability, the argument they believe is that users expect the status quo. (I've been shot down from making a few small changes to our software's user interface on these grounds.) When I've asked everyday, non-technical people who actually use our software what they would think of the change, despite the fact that it behaves differently than all the other software they use, over 90% of them have said "oh yes! That would be a GREAT change! I'm so sick of programs always doing it the other way!"

Now, I'll be the first to admit that what users say they would enjoy and what they'll actually enjoy are often different. But I'm inclined to believe them, because I too have been in situations where I constantly have to fight with an interface choice even as I watch other software rush to copy it. I know that experience first-hand. And I know how nice it would be to find software that stopped listening to the so-called 'experts' and actually spent some damn time thinking about what the best design choices would be.

The Linux/OSS community, as a whole, has spent a long time and a great amount of effort trying to become as Windows-like or Mac-like as possible. And I'm not going to say they/we shouldn't have done that, because one thing that such similarity does is it lowers the learning curve for people who want to try Linux/OSS or switch completely. Both Apple and Microsoft have also figured out how to focus their development efforts on the user, instead of developing for their own use, and that's another lesson it's good for the Linux world to learn. But we shouldn't be afraid to ignore the way the commercial OS writers are trampling and take some time to consider what the BEST direction is. Too much regurgitation of the accepted "expert" design, and you get into a feedback loop where you can't make a better design decision because you've written too much stuff that behaves the "expert" way. And then you're Redmond.

So should we put our software in front of the users? Absolutely! There is no better, more accurate, more incisive, more disillusioning gauntlet for our software to go through. But screw the "experts." Seriously.

In my experience, code reviews help the developer much more than they help the product. And this is a Good Thing.

Take me, for example. A few years ago, I was just out of college, 9 months on the job with a global consulting firm, working on a large Java-based web application for a government department. I was assigned a complex and poorly-defined module to write. While my first stab at the module worked fine, passed unit testing, and satisfied all the functional requirements, it was kludgy and would have been inelegant for maintenance programmers to work with. One of the project managers took the time (about two hours!) to go over my module, reading the code until he understood it, and then asked me penetrating questions and made really good suggestions about how to change it so that it didn't just work, but was elegant and maintainable as well.

Those two hours, and the subsequent 30 that I spent rewriting that module, cost my firm one or two thousand dollars, I suspect, on a fixed-price contract that was already over-budget. From an economic point of view, it made no sense for that review and rewrite to occur. But they made me into a much better developer both from a technical standpoint (I learned a better way to design the algorithm) and from a social standpoint (I learned a better way to make my code maintainable). I really liked being part of a company that was willing to sink that time and money into helping me improve my skills.

So should companies have code reviews? Absolutely -- if they care about increasing the skills and maturity of their developers. If they intend for their developers' skills to stagnate, and they don't understand the value of investing in the continued education of their staff, then surely not.

I'd love for you to explain to me where I should have gone on my old Samsung T729 to set the alternate emergency number. No? You can't do that? Well then, maybe you could tell me, on my new Samsung T739, what emergency phrases are available to be automatically spoken? I can't find this information anywhere in the manual. Or on my friend's new Nokia N75, would you mind explaining exactly how it is that the phone makes it more difficult to hang up a 911 call, compared to any other call?

I'd love to hear this, because you're so unbelievably full of Wrong that we should tap you and serve you as a refreshment at the next Microsoft design meeting.

And this is why you don't do the string comparison on the database side. SELECT hash FROM users WHERE login = [the entered login] and then, in your application, hash the entered password and compare the strings. Problem solved (before it began!). If your app is doing the comparison in the database, it's your own fault.

(This also has the advantage that the hash of the entered password never travels over the wire (if your db server is on a different box). Granted, that would only be a problem if your network security was otherwise compromised, but it is slightly safer.)

*shrug*

Bullhonky.

At my most recent job (one of the top-ranked IT consulting firms in the world, rhymes with 'adventure') I was issued a laptop, lovingly imaged by the finest technicians that corporate enterprise IT has to offer, with XP SP2 on it. I had to kill and restart explorer.exe roughly once a day when the interface would stop responding, and BSOD's would happen about once every two weeks.

Contrast that with my 8 years of OSX experience, where I've had maybe 12 kernel panics ever (and at least 75% of those were prior to 10.3). Or contrast it with the small fleet of Ubuntu computers that I maintain (12 servers and around 50 client computers), where we have never had a single kernel panic, ever.

So let's sum this up. Over the course of 2007 and 2008, kernel panics / BSOD's I experienced, by OS:

Windows: ~25 / year
Mac OS X: ~1.5 / year
Ubuntu: 0 / year

Deal with reality.