Issue link: https://iconnect007.uberflip.com/i/553274
44 The PCB Design Magazine • August 2015 engineer puts demands on you that prove that he doesn't understand what you actually do? I've certainly run into that. I've had mechanical engineers question why we are bothering with circuit boards in- stead of designing the circuitry into the plastic housing of the device. I've had manufacturing engineers demand that I shelve the electrical considerations in order to meet manufactur- ing requirements, and electrical engineers who could care less if the product could actually be built. I've had engineers hover over my shoul- der watching each and every stroke of the mouse that I make, and oth- ers who are never available for important questions, which ultimately brought the whole project to a grinding halt. And then like some of you, I've had my share of moments where, after the job was completed and the engineering team got their recognition, my efforts were completely ignored. It can really be tough to not look at this sort of treat- ment as a complete failure. Of course it isn't a failure on our part, but it can sure feel that way. Have any of you ever been working on a design only to have your work station sudden- ly shut down because someone else was fooling around instead of working? I did, and boy was I mad! I'm not sure how long it had been since I had done a save, but all that time was lost just because this guy thought that he was being clever by logging into my machine and pulling the plug—on purpose. And in case you were wondering, yes, shortly after that stunt this person no longer had a job. Back in those days I also remember talking to a designer at another company who used the same software that I was using. He had a crash and wanted some help in recovering his work. The problem is that he hadn't saved his work for many, many days. He was in the habit of always keeping his design open, and every now and then he would do a little work on it. But because he would never save it, he didn't have anything to go back to. Thank goodness now for the ability to schedule auto-saves and replaying the transcripts of our work to avoid those kinds of failures. Now that I am working in the customer sup- port arena, I have seen a greater variety of failure scenarios. One of the biggest failures that I see involves users who don't understand what their software is capable of. I will find people doing manual operations and getting really frustrated with how much time it is taking and how many errors they are dealing with, simply because they didn't know that the same process was already avail- able in the core application as an automated function. To avoid this type of failure, please spend time in your user manual, look at the tutorials, and talk with other users. And if you can, look into taking a refresher course in your soft- ware from time to time, too. Another failure that I have seen is almost in the opposite direction. Users will some- times rely too much on au- tomation for something that they should just do them- selves with the functionality provided in the core applica- tion. I had one user call me for help after he switched compa- nies because his original company had created a whole set of automated scripts for post-processing, and now he didn't know how to create a simple Gerber file. I've also seen us- ers introduce design errors because they tried to do something that the software just isn't able to do. Again, knowing what your software can and can't do is the key to avoiding these kinds of failures. I started this column by mentioning the movie Apollo 13, when the flight director said that failure was not an option. But later on in the movie, when it was suggested that this could be the worst disaster NASA had ever faced, Ed Har- ris' character responded with this: "With all due respect sir, I believe that this will be our finest I've had engineers hover over my shoulder watching each and every stroke of the mouse that I make, and others who are never available for important questions, which ultimately brought the whole project to a grinding halt. " " tim's takeaways FAILURE MAy NOT BE AN OPTION, BUT SOMETIMES IT'S A REALITy continues