My boy Bill is always entertaining, especially when he's making a point that he's passionate about. This time it's the way that programmers shirk their duties with phrases like "it works on my machine", or making apps the least amount of user-friendly possible (making the customer read you hex on the phone? wtf?  I've worked with programmers that couldn't read you hex on the phone, and just the other day I had to remind someone who should know better which letters are and are not valid hex characters.)

See, to me, this is bullshit.  And I can say things like bullshit because not nearly as many people read this as read Bill's blog, so I can swear all I want and not worry about offending people.  crap boobs crap!

But anyway, yeah...bullshit.

First of all, "it works on my machine" because you have a highly tailored and customized dev environment.  Stop wearing your ass as a hat and start testing on machines that mirror closely the target environment.  Stop testing with admin priveleges (I develop as admin, so bite me everyone, it's not worth the hassle to not run as admin, but I test as all standard user groups when necessary).  I've managed a lot of software development, and only one time have I ever accepted "it works on my machine".  It was a VB6 app, lots of fucked up dependencies in VB6 folks...VB6 is why they invented the phrase "DLL Hell".  Anyway, we could not track down this bug, but it only worked properly on the developer's machine.  We set up a second machine with an identical setup, and it didn't work there.  That was just weird.

But in most cases, I don't give a tiny rat's ass if it works on your machine, because you are not the end-user.  And if it doesn't work on the end-user's machine, it doesn't fucking work.  Oh yeah Bill, I've worked with a couple of these too, and I hate their guts.

Now, user-friendlyness.  WTF is with programmers being too lazy to make things easier for the user?  Now let's get one thing straight...I'm not some bleeding-heart user-loving hippie.  In general, I disdain the user, mostly because I disdain all people until they give me a reason not to.  So I go out of my way to make sure that any idiot off the street (because that is exactly who they are going to hire to use your software) can use it.  Open-ended configuration options.  Insane error handling.  Everything automated that can be (who the hell writes software that needs the system clock reset anyway?).  This way, I reduce the chances that people are going to call me.  I hate the phone.  I like email.  Why?  because I don't like people remember?  But what do users do when something about the software bugs them?  They call.  I hate the phone (oh shit i'm in a loop...break;).

Writing software, especially corporate software, but especially any software, is like war.  It's you against the users.  Your job is to plan out every possible way they will attack your software, and you have to thwart that attack.  This is not because they are sophisticated hackers, or are the world's best multi-tasker.  This is because some jackass is going to right-click on your button while holding down the scroll wheel and mashing his palm on alt-space-a-s-d-x-c-v-windows key and dragging.  He will do this because he's not paying attention anymore when his hot secretary walks by.  You have to plan for this, go on offense, and stop that impending bug in its tracks.

Now that was all a little tongue-in-cheek.  I don't really hate the user, but I do really hate talking to people.  And I don't really think you are at war with users, or that all users are idiots.  I've been blessed in my career with some very helpful users.  But the point is, you gotta plan for the idiots because they are there.  And the bonus is, if you do this, then you make your good users happier than they have ever been, because you have given them software that seems to do everything they want it to do, and they don't have to read hex to you on the phone (because you want to be like me, and you have started hating the phone).

So, what have we learned?  Test on machines other than your dev workhorse.  I usually ask that my test environment be less powerful than the production environment, because if it's a performer on the crap boxen, it will work on the good ones.  And design with the user in mind.  Handle those scenarios that are going to come up.  Go the extra mile to put a little more user-friendliness into the app.  Usually, the crap that makes users happy is like 5-10 LOC at most.  Just do it and save yourself the headache later.

That is all.