"It works on my machine" - Please Comment!

Published 11 December 4 10:48 PM | William

Ok, a friend of mine has had a lot of bad experiences with developers.  When we first became friends, it was because she couldn't believe that I was a programmer and not a total a33hole.   The first company she worked at she worked in support and their software left something to be desired.  But there was total stratification there and she was told not to talk to the programmers under any circumstances - as a matter of fact, this person was told that she was not even to say “hello” to any of  the developers in passing. 

Before I continue, let me point out a few things.  This girl graduated 2nd in her high school class in a class of over 1,000 people.  She received a sizable scholarship to one of the most prestigious universities in the South and graduate with honors.  I worked with her for about 5 months and found her not only really easy to work with, but much smarter than just about any of my fellow programmers.  For instance, we had a lot of manual file moving and had to ensure that certain directories stayed in Sync on the machine that was used for deployment.  Instead of doing this crap manually - which our Senior Programmer did when he handled updates, she wrote a batch file to handle the move to make sure that she didn't forget anything. 

As a tester (which she worked as when I got there), she came back with great bug reports complete with screen shots and very detailed descriptions of how to duplicate the bug.  The other testers used to say things like “It doesn't work” or “The tab stops are wrong”.  She'd send stuff like “Tab stops 4,5, 6, 7 are out of sequence on Form1.  When you tab from tbSocialSecurityNumber (3), you immediately go to tbCity (8) obviously indicating that 8 is actually 4...”

When I first got there, the Senior developer and I had some bad interactions.  He told me how stupid OOP was and database normalization was because they both killed performance.  He graduated from college in 1978 (I was still breast feeding back then) and although everyone talked about how smart he was, I never saw it.  Anyway, after this girl and I became friends, she asked me what I thought about him.  I told her that he was a primadona, which was fine, except for the fact that his stuff SUCKED!  If your mouth writes checks your a33 can't cash, I'm not impressed - I don't care what Title you have or what you did in the past.  She defended him but said that she knew he could be a jerk.  Since I'm not Southern, Jerk isn't in my vocabulary.  D*****ad, B**ch, stuff like that is my default response.  So as we got to talking, she started telling me some of her 'ideas' about how our stuff should work.

This is 100% true as much BS as it sounds and it was in 2001!  If you needed to undo a transaction in one of our most popular applications, you had to change the system clock time back to when it 'should have happened' , rerun another transaction and then reset your clock back.  If you forgot to change it back, everything you did until you changed it would be screwed up.

Another one of his brilliant apps made users have to check for Hex codes.  Unskilled office clerks at small town government offices had to go into notepad and read back Hex to the support people.  He'd simply tell the clerks, “Are there Fox Foxes?”  What are the chances that some non computer science/math major can read hex on the fly?  What are the chances that most programmers can read hex on the fly?  When he had to explain it to them, he'd go back and bitch about how “stupid” everyone was because they didn't like resetting the system clock or decipher hex on the fly.  Mind you this is the same guy that didn't believe in relational databases or OOP because joins have 'performance issues'.  This was in 2001 btw.  I went to school back in 95 and even in old school C++, If I wrote a program that made the Professor change the system clock manually - it wouldn't be accepted.  They wouldn't even waste their time failing me.  Now here I am in 2001, at a company selling expensive software, that requires lay people to change the system clock in order to undo a transaction and read hex values to people.   This a-hole was the king of “It works on my machine“

--------------------------------------------------

That's where I learned to hate the phrase “It works on my machine”.  At the end of Traffic, David Ayela (Steven Bauer)  asks Arnie Metzger (Dennis Quaid), “Do you think there's a difference between a reason and an excuse?  Because I don't Arnie”  That's what I think of every time I hear anyone pulling the “It works on my machine”.

My friend works at a different company, but they also have a lot of drama.  They have a developer there that is the king of “It works on my machine”

I'd be fired if I pulled some crap like that.  If I wrote it, my responsibility doesn't end until it's on the users machine, running and they LIKE IT!  Until they sign off on it.  So if I pulled some “It works on my machine” type nonsense, the client wouldn't much care because we don't get paid until that signoff.  But even if our incentive system wasn't based on signoffs, there's this thing called “Pride in my work”

To me, telling a customer, or a support person “It works on my machine” is pretty much the same as saying “It sucks to be you”.  Except I CAUSED THE PROBLEM.  It's my code. 

Every job is a self-portrait of the person who does it Autograph your work with excellence.

So what does “It works on my machine” show the world?  “I'm lazy, incompetent, apathetic, overpaid and actually should be unemployed.” 

My friend called me the other day frustrated because she's responsible for making sure that stuff works.  Old boy pulled about every variation “You must be doing something wrong because it works on my machine” and after she wasted about 6 hours Proving it wasn't anythign she or the customer was doing, he still wouldn't own up to the problem.

Before you level an accusation, which “It works on my machine” does implicitly (seriously, you should include the dependent clause “so it must be something you or one of the other dumb asses is doing”), you should make damned sure that it's not your fault. 

I remember   Raymond Chen's    Blow the dust out of the connector which talks about how to handle customers.  Raymond is the man.  He has 1000000000000000000000000000 more accomplishments and reason to be a primadonna than either of the two aforementioned clowns.  Yet he's so commited to professionalism that he'd go out of his way to keep a customer from feeling dumb.  That's why he's Raymond Chen and that's one of the many reasons I admire him. 

----------

If you ever use “It works on my machine” and don't fix the problem you created, I think you should automatically do the following:

Forfeit any right you have to complain about your job moving to a contractor, intern or another country.

Acknowledge that in any other profession you'd be fired.

  “I just paid you two thousand dollars to fix my transmission.  I got one block and it caught on fire”

   “It worked in my garage, it worked when you left. What did you do wrong?”

Attach the following:

I use lame excuses like this because I honestly don't know how to make the code i wrote, work.  I'm incompetent and lazy and an embarassment to my profession.  Please, Please, Please understand it's me, not you.  You're not dumb, I am.  You're not the one with the problem, I am”

---------------------------------------------------------

Anyone care to comment?  My friend is definitely going to read this because I'm sending her the link.  Let's show her most of us bust our asses to write the best stuff we can.  The few of 'them' in our profession don't represent the rest of us, and I personally detest this mentality.  I think 95% of my peers do as well.

Comments

# William said on December 11, 2004 11:52 PM:

I take it we are not mentioning your friends name in this post cause I know who you are talking about and you are correct she is one smart cookie.

Raymond is the man, end of story on that part.

Do you have any idea what my boss would say if I tried that cr@p where I work. I've actually seen him do it with our IS people.

He calls IS and says "my docking station usb doesn't let my phone synch with my laptop but if I pull the laptop out of the docking station and plug it into the laptop directly it will synch".

IS tech says "let me try it on mine" he does and it works fine in both places on his. He says to my boss "well it works fine on mine" my boss says "ok then give me yours, you can bring mine back when it's fixed or you have a new one for me." Tech looks dumb founded but hands over his docking station.

Trust me you do not f#ck with somebody in a corporation who has as much power as my boss. The tech had the good sense not to argue and the next day my boss had a new docking station.

"It works for me" carries zero weight where I work and you could very easily get fired if you said it to the wrong person.

# William said on December 12, 2004 1:03 AM:

The only way to solve this is -

a) Everyone must realize the common goal - TO MAKE IT WORK !!
b) Upper management must delete any trace of finger pointing or any heed towards that. They must keep a good atmosphere running.

Once you have the above 2, you'd never have
a) Can't talk to developers. Nobody enters their cave.
b) Must go thru project manager for all communication with customer.

And as far as "It works on my machine." Usually that attitude stems from someone trying to make an MS project file look good - "Issue #10992 completed - Customer was crazy". If we backtrack from there - the developer did that because his manager asked him to - the manager asked that because the upper management likes to have credibility and responsibility and trackability - they like to have the c & r & t because they lack the inability to make every in the team feel points a & b mentioned above.

Add to that, the upper management in larger organizations prefers to run their companies in a disconnected mode from a golf course. They really do view us as ants, and that is just wrong. So I don't work for a huge company as anything but a contractor. Keeps the system fair !!! And developers - most of them - code not for a job but for a passion - a huge testament to that fact is all the open source software written that brings huge companies down to their knees.

# William said on December 12, 2004 1:12 AM:

Excellent points on all counts. But assume that it's not the manager... that it's the programmer that demands he not be spoken to by anyone other than a manager. And they actually make you change the system clock to change a transaction?


2004 and this is still happening, and not even in large companies, although they probably have a lot worse ;-)

# William said on December 12, 2004 1:20 AM:

Andy:

Amen, and he answered it correctly. I'm more of the "So what's your point, I didn't pay for it to run correctly on your machine" variety, but his response is better.

I know Tiba would have my Ass if I ever pulled this on a customer, and the a33 of whoever hired me. This type of nonsense shouldn't even be allowed in the front door, and fortunately, i work somehwere where it ISN'T. But the implication is that someone else screwed up - not the programmer, and mgt usually buys this bullshit.

She'll be reading this post, and she'll be paying attention to your response - Much appreciated!

# William said on December 12, 2004 2:38 AM:

My red flag is: "In theory it works."

Much of the stuff software developers write goes out the door without thorough testing. I happened to me and it will happen to you. It is all a matter of money and the bottom line.

How many hours of a working day do you spend reviewing code, code written by somebody else? Say "I write buggy software" every time before you check in a piece of code. Make sure your manager knows about it. People make mistakes. But most mistakes can be caught and all mistakes can be corrected.

Having said that, when a customer tells me that there is something wrong with a piece of software that I wrote or helped write, I feel shame. My bad. IMO the biggest mistake you can make is to not own the problem. Tell the customer how bad you feel for him/her and that you will help in any way that you can.

About the smartness of your friend. Signalling falsities is step one on the ladder to management. Doing something about is step two.

BTW. "bug duplication"? LOL. Did you mean "bug replication" or "bug reproduction"?

# William said on December 12, 2004 11:01 AM:

Ah Bill, always ranting and raving about something! ;p

I've made my response over at my place, but let me just say that I'm with you on all points.

I would have done something very evil to that senior guy at the one job. I tend to have a short fuse when it comes to stupidity, and I mean *short*. He would have ended up with a special non-propagating virus or something.

# William said on December 12, 2004 11:04 AM:

@Roland: "I feel shame" - nice

I get the same thing, especially because you know that at least half of the time it's something stupid. If it takes you less than a minute to find and fix (not including recompile) a bug in a production system then you know you want to hang your head in shame.

I mean, if you are going to have a bug in a system, at least have it be a good one that takes a while to track down. Then it's lilke a puzzle, and puzzles are fun!

# William said on December 12, 2004 1:06 PM:

Roland, Scott, I'm with you on all counts. Two statements stick out:

1)I feel shame. Me too!
2) IMO the biggest mistake you can make is to not own the problem. Amen. This causes so much crap because not owning up to it is usually followed by spending time and energy sending people down other paths or covering up the problem.

And one second down this path is too much. The customer shouldn't suffer becuase of my ego or ineptitude.. and Yes, I'm going to make mistakes, but that's where owning up to stuff comes in. And "It works on my machine" != Owning up to it.

# William said on December 12, 2004 3:34 PM:

Well, when I find myself *thinking* the phrase "it works on my machine", I end up joking about it with the poor individual (usually on the other end of a 'phone), using kick-backs like: "well, it works on my machine, which is exactly what you didn't want to hear!"

But, joking aside, this immediately moves us into a different realm of reasoning as far as technical support goes. IWOMM should not be the end of the conversation, but the start of a new, more analytical one: one where the differences between the client's machine and the tester/developer machines are noted. After all, if the client has a problem running your application, it means you don't have tests that cover this scenario, so what's different? Can you learn from the IWOMM scenario, can you write more tests that help you determine the problem and the solution?

# William said on December 13, 2004 9:58 AM:

A lot of the trouble I have with "it works on my machine" is sometimes it's literally true--because I only have one dev machine. When I was writing an installer for the app I work on, I had another machine and used Norton Ghost to produce a large variety of different configurations.

Why organizations are so damned stingy about providing developers with hardware resources, is beyond me. People developing rich client apps really ought to do basic testing on a few different platforms/configurations easily. And it doesn't hurt with web apps.

Depends on the company, though. Some are smart enough to realize that giving people the tools to succeed, drastically reduces the buck-passing instinct.

# William said on December 13, 2004 11:08 AM:

"Having said that, when a customer tells me that there is something wrong with a piece of software that I wrote or helped write, I feel shame."

I can understand discomfort, but shame? From my perspective I do everything I can to prevent bugs from going out; but ultimately it's actually the company's responsibility to control quality, too.

Personally I haven't run into many jackasses with zero customer empathy on the job, like Bill describes. That guy strikes me as a plain old sociopath. To me the norm is people who want the customer to be happy. But even so we still ship bugs to people.

It's just the company's decision to ship software with bugs, instead of making it an absolute requirement that software we ship has zero (if such a thing is possible). That's just practical business in this industry.

The jackass in Bill's article should feel shame for being an utter incompetent; but someone who gives a damn, is competent, and works within typical organizational constraints? No way.

By the way, I've certainly worked in companies that will take the "ownership" idea and turn it against developers, making them responsible for anything and everything that goes wrong. This is just as bad as having primadonnas on the team, just in the opposite way--everyone burns out and quits, and the customer is still screwed in the end.

# William said on December 13, 2004 4:01 PM:

"
"Having said that, when a customer tells me that there is something wrong with a piece of software that I wrote or helped write, I feel shame."

I can understand discomfort, but shame? From my perspective I do everything I can to prevent bugs from going out; but ultimately it's actually the company's responsibility to control quality, too. "

I too feel shame when a user finds something wrong with something I wrote or helped write. I know that the company has responsibility to control quality as well, but I still feel bad knowing that I did something wrong or missed something.

# William said on December 13, 2004 4:07 PM:

Me too. The reason I mainly feel shame is that I caused the customer inconvenience. I know it's part of the business, but it still bugs me. If it's trivial, I'm not losing too much sleep but it still bugs me, but if it's something serious - then I definitely am bothered by it.

# William said on December 13, 2004 4:51 PM:

Well, to me quality is a metric; not so much a high-and-holy goal of the software I produce. If quality means 100 bugs per feature, and that's what the company decided, then I pretty much have to accept that outcome--because it was a cost/benefits decision to have that level of "quality."

Of course that's a theoretical decision; a lot of companies (especially small ones) just make that tradeoff implicitly by (under)allocating certain resources to a task. But you get the idea.

Personally I feel shame if I misrepresent something to the customer (or, more often in my situation, to my employer who deals with the customer). My standard is to have integrity about what I'm putting out there, and in representing that it's what the business and customer want.

Definitely bugs inconvienence the customer, but that's still weighed against the total value they get out of the software you're providing. I guess I don't feel "shame" if there are bugs, as long as I represented what I did (ie, what was implemented) fairly and straightforwardly.

# William said on December 13, 2004 4:57 PM:

JMW, I agree with you. Bugs are definitely part of the process. The more that's tested correctly the less likely it is that they'll show up. If your company doesn't test very well, like the one I was referring to didn't, then they'll certainly show up. And it's embarassing in the same way that perhaps having a spouse or sibling get really drunk and behave like a jerk at a company party might be embarassing.

I'm pretty neurotic so it doesn't take much to make me feel guilty if I'm in some way tied to a problem, whatever that is and I definitely take bugs really seriously some times too much so.

# William said on December 13, 2004 5:09 PM:

Bill:

Yea, I've been working without independent testing/QA for a while now. In the right environment I'd probably have the same neurotic behavior; but in my "write n thousand lines of code, test it all yourself" world, you kinda learn to live with your own limitations. It's like software survivalism. :)

Speaking of which, "it works on my machine"--that actually has a lot more bearing when you don't have a QA person to work with, or quick access to an independent machine. But you also learn to be more efficient about writing good code, because after you see a lot of code break the first time on another machine a few times, it gets old. :)

Anyway, cool thread as usual...:)

# William said on December 13, 2004 7:22 PM:

I'm small business IT so guess who the customers are? The people I work with (for the most part).

I only with our companies customers on a portal we're GIVING them for free. (-1). Add to that it's a Java implementation (-1 depending on who you talk to). Add to that them always being late on updates (-1). Add to that them never giving me the proper documentation so that I am their QA team by finding every bug they produce within seconds (-5). Add to that the portal does work for the customer but it's like pulling out my teeth with a socket wrench whenever I implement a new customer or make any change (-1). Add to that the incredible amount of time I take for their GUI with no backside server/SQL scripting or anything to make my day better (-5). Add to that the recent "Import" utility that doesn't hash the passwords so that means individually editing (a total of 3-4 clicks + time on the clock) which I had to recently do for 160+ users (-109090909290880238390832908430928).

Add it up and what do you get? Pure unadultered CRAP. I wouldn't sell this damned thing if they paid me to do it and yet we're paying something like $500 a month to upkeep this garbage. I plan on forking dotnetnuke or .Text or something similar as a base and making an extremely oversimplified portal that only does what we need it to do. No overcomplicated CRM suite with tons of bells and whistles NO ONE F-ING USES.

Okay sorry for that rant but that's the only time I deal with a "professional" "development" "company" outside of what I do.

I'm lucky when it comes to my customers. It works on my machine? No. I have VNC setup on all machines and Remote Desktop capabilities to Windows Server 2003. It works on YOUR machine! 9/10 times the problem is simple user error where the person "forgot" how they were doing things 1 hour ago and they somehow fudged their work. The other 1 time it's a real problem but because it's next to impossible to duplicate some of the stuff the people do at my office, it's extremely hard to fix their problems. At least I get to tell them "It works on YOUR machine." If it's something I can't duplicate I have to put it off until a better symptom comes along that lets me isolate the event. Sometimes it's EXTREMELY difficult to fix certain problems with applications, hardware, or anything else computer related. I sometimes wish there was a history that let you look at the last few things a person did to retrace their steps but apparently no OS maker has spent 20 minutes with an IT staff to understand how beneficial something like that would be. Or maybe it exists but it's so outrageously overpriced we'd never buy it. Either way we're screwed.

Search

This Blog

Tags

Community

Archives

News

My other sites

Cool Stuff

Book Stuff

Security

ORM

Data Access

Funny Stuff

Compact Framework Stuff

Web Casts

My KnowledgeBase Articles

My MVP Profile

Design Patterns

Performance

Debugging

Remoting

My Fellow Authors

My Books

LINQ

Misc

Speech

Syndication

Email Notifications