Most significant elements (for me) of presentation(s) this week were:
1) The anecdotes that amplified the points made in the presentation and
2) A focus on prevention
Day 4 - Slide 20:
During development of the product, the engineers should constantly ask What are the potential problems in this design? Can I avoid them? Will my change affect anybody else?
@danlafleur: Operations in the military/government are definitely different than the private sector. There are lots of engineering and management training out there. Each company is different on how much importance they put on continuing education. Even within HP it had been up and down over the years.
@apdobaj: One thing that helps provide a framework for doing things right the first time is to look into the future. What would version 2.0 and 3.0 of your product look like? That gets you steered in the right direction for right now. Another thing to consider is to record all concerns or missing aspects about the design or process. It may be a searchable comment in the code, like this, /* LATER: Add support for the wrong-button input. */
@MazianLab: Gamma Rays are definitely something that requires special handling given health and security concerns. Modeling the behavior is good but it definitely needs to be an accurate model. One option is to record the behavior of the current source when using the real isotopes and then play that back. Do this for various types of readings. One thing I would strongly suggest is to add some datalogging capability on your side of the device that can capture the timing, the amplitude, the wave shape, etc. Then when you are able to test it with the real stuff, you can compare a real wave form against the simulated wave form. I would also suggest leaving that capability in when you ship the product so that when it is used in an unusual situation, you can retrieve the waveform and figure out why. A good test suite would then be running your code in a test harness and then feeding it each of these different sampled waveforms. I'm limited here by not being able to draw pictures or ask you questions. Contact me if you want more help on this.
@mark_t00: Hum, sounds like there are already some bad feelings going on. Here are some ideas. Ask them why it's not in their area. Then ask them why again, then again. Challenge the individuals to prove the problem isn't in their area; they can't just state that it isn't, they have to prove it. Proving it may require extra debug code or scope traces. Bring both sides into the same room and walk through the problem, from the beginning, and examine each step in detail. Put both sides in the same room without any managers, mediators, or arbitrators and tell them they can't come out until they resolve it. Take other assigned tasks off their platter so that this is the only thing they are allowed to work on. Bring in an unbiased, third party individual/team to look into it. If they end up successfully working together to fix it, take them out to dinner, or something.
Never got the audio - it just kept on buffering. Stream must be blocked by IT as I have current Flash version. Will just have to listen to archive when available. Slides need some commentary to be meaningful.
@Ann R. Thryft: Are management practices different for engineer than for someone else, like marketing? The basic human-to-human aspects are the same, show respect (to both managers and underlings), treat them like intelligent human beings, etc. Differences come in the details. A marketing team would enjoy a reward to go golfing for the afternoon. Engineers would rather pick up the free food, go back to the desk, and keep coding. :-)
@Rob Spiegel: Have I seen improvements in management? That's like asking if parents today are better than parents two decades ago. You still have different personalities involved for both the manager and the underlings and you still have new people coming into those positions that don't know it yet. Company culture and country/ethnic cultures come into play too. Someone made a comment about parenting. "There is no such thing as a parenting style; it is a parenting hybrid." Each kid is different. I know that because I have six of my own. Same with management. What's effective depends on the people involved.
In my military experience, a promotion usually meant corses to teach the knowledge and skills needed for the new position. Leadership training, admin skills and lots of encouragement to practice them.
I don't see the private sector ever having the will to spend money on training people for supervisory or management roles. It's expected that ypu just pick up what's needed and sdtart doing the job.
I almost forgot to answer your question. I'm involved in both hardware and software with a little bit of management thrown in. (I try to minimize the management parts.)
Some have mentioned females vs. males. I agree, females make good managers; I've had a few over the years. In fact, I'd say that two of three best managers I've ever worked under were females.
but a framework for achieving that goal of doing it right the first time is critical. there are so many moving parts that nobody can remember them all. and not all touchpoints are appropriate for all maturity levels of the project. "The Checklist Manifesto" is a good reference to this concept.
Thanks for you input. We have a strategy meeting planned next week. We will be pulling all of the information we have collected together and planning our next steps. I agree ownership of the problem needs to be shared.
Gary, I am involved in upgrading some Gamma Ray Dose Calibrators. Unfortunately I don't have access to Gamma Isotope, infact I am not allowed to keep it. So far, I simulated Current Source circuit instead of Isotope. But this simulation is limited. Do you have any suggestion to solve my problem?
@raghu comments that "doing it right the first time" only comes after experience. True. Because the experience is what tells you what might fail. But anybody can develop a mind set to look out for what might go wrong, whether they have little or lots of experience in that domain.
mark_t00 - Joint ownership is key since the system is shipped as a system, not hardware or software seperated. The customer doesn't care where the issue is and they shouldn't either and work together to solve the issue.
mark_t00, have you tried formalizing your approach? I've found engaging in a structured and agreed upon DOE goes a long way in reducing the finger pointing.
@apdobaj- I agree with this, but would add that any manager has to have some human element, to quote Gary from earlier. I have met engineers that would fit into that category that you describe, but you know they would never make good managers because they have no idea how to deal with people individually, and how to capitalize on everyones strengths without allowing each individuals weaknesses to bring down the project. Nothing against them as engineers, or people for that matter; they just didn't have that skill.
My engineering career began after 25 years of being an electronic technician for the same company. I designed a test fixture, which helped to analyze a serious problem being caused by a safety defect within a digital timer circuit that would intermittently lock-up and cause a critical output to become enrergized. Doing that, allowed me to become a member of the Systems Integration Engineering Team.
In my view, a good (engineering) manager is one who provides a framework for bringing to bear critical efficiencies and learning from having been through the process numerous times, while at the same time allowing creativity to prosper.
@raghu brings up an interesting (but maybe rhetorical) question. "Isn't debugging an integral part of design process itself?" It is but sometimes it is not planned for in the schedule. It is but it requires that you do some testing before you know what needs to be debugged.
Question: I am currently working on a team with an embedded soft core processor in an FPGA. We have been struggling to find a particular problem and there has been a lot of finger pointing between FPGA design and software design. Having some trouble getting some people to be willing to add code/hardware to "hack" the problem and get a better picture of what is happening. I believe EGO is getting in the way, some unwillingness to do this because the problem "can't" be there. Here come the people skills. Any suggestions on how to proceed without laying down the iron fist?
Do management and teambuilding theories and practices work differently for engineers than for, say, marketing and sales people? Are there different management and teambuilding practices that should be used for engineers?
There have been a lot of management and team-building theories tested over the past two decades. Given that, do you see things improving in effective management and team-building with your clients?
@luizcosta - Fully agree that MBAs without specific education and field experience in the problems their teams are involved, are useless. That's one of the reasons that I enrolled in an Executive MBA program. Only individuals with a minimum of 10 years of experience in their fields could apply and it made the education much more valuable.
I once told a manager that; "I would rather club small furry animals with a stick for food than work for him." Moved on and was infinitely happier in a new position
Alex - I received a nice email from UBM / Design News regarding an offer for attending today's session. While I appreciate the offer, I'd personally rather not have to deal with my corporate ethics department. Can UBM / Design News donate the "gift" to charity?
I always assume that two rational people with the same data should come to the same conclusion, so if I had a difference of an opionion with someone, my assumption was they must have some additional data that I did not, instead of jumping to the conclusion that they were wrong.
For designing: All the time consider "The worst situation".
For debugging: First you should suspect to everything is wrong. Second try to localize the bug. Change the part if you are at least 70% sure. Otherwise look more to find the problem.
Useful things: 1) Things with a lot of functionality, I offer two ways to configure them, one that is really simple (think big green button named RUN) and another that lets you tweak every possible feature. You can run it either way or with a combo.
2) I do all my testing that I possibly can from a system level perspective which lets me know what observability and controllability to put in.
3) Include example use cases in documentation and use them as test cases.
Test early, test often during development. I have found it most helpful to test individual components as they are developed, then the system testing goes much smoother. I have worked with some who leave all the testing to the end, it usually makes system testing take much longer, much harder to solve issues, and the solutions often are less than ideal in order to get the product ready to ship.
One thing to remember: Don't ignore anomalies seen during testing that are hard / "impossible" to reproduce. They often are clues to a subtle problem that will be much harder to deal with after release.
Key debug: Get everyone to agree on what the problem is. I think people think they know but if you discuss it then you find out everyone has a different interpretation. You cannot debug without clarity.
My key thing used in most problem solving situations is confidently using my intuition. I follow my nose as I sniff through the symptoms and responses.
We actually bring in the guy who writes the manual for the product early in the game. If *he* can't explain it or figure out how a user is going to understand it, you probably have a product full of lousy features. Then you invite the test guys in once you think you know what problem you're solving. Only *then* do you start actually designing the product.
Key aspect that I have found in my work: collaborating with others. I have worked on a project with another programmer, and I was able to find all of the bugs in her code that she missed and she was able to find the ones in my own code that I had missed. Worked well together.
the hardware designers should consult with the software guys BEFORE they design the board. Sometimes parts are designed you be used (port allocation for example) in certain ways by software
Many years ago, a manager said, "Good engineers are a dime a dozen, but a good manager is hard to find." That says a lot about the attitude of managers toward engineers. In part, he was correct: "Good managers are hard to find."
The day I left the company, I gave this manager a dime and told him he would need it. :.)
Alexander Wolfe: What's the most significant point that you think Gary made this week, point or info that's new to you?
During Part 2 of this track, Gary talked about Test Plans. To make his points, he provided stories of his experiences at HP. We ALL are familiar with ink jet printers, and hearing his stories of HPs testing allow his points to be driven home in excellent fashion. We don't get to see behind the curtain very often, so this was the next best thing to getting a tour at HP. Well done, Gary!
totally agree... i wrote a best practices in creating automation test scripts, design, structure, coding, environment setup, teardown, error handling, reporting and review process
Good point about making sure test code is clean. When we would have product failures during testing, the Design Engineers would first be very critical of our testing setups to try and prove it was not their issue.
Again, I'd stress co-development of test and executable code is critical -- and it's equally important to have peer review on both early. Recall that the same guy who wrote the code to test how the Hubble Space Telescope main mirror was ground was the guy who wrote the grinding algorithm.
@RAN: That manager was an idiot. Leadership is really about taking care of your people or surrounding yourself and your people with the best resources possible.
When I was in the Navy as an Ensign, 1st Divn Officer on USS SARATOGA, I didn't have a chief (you can translate as senior engineer). I had to earn the respect of my guys. I got messed with a lot, but eventually, they saw that I was backing them up and rewarding them as they performed for me.
Build up your team and share your knowledge. Don't play "I've got a secret". Build the tribe...
manager should have some technical knowledge, but *must* be willing to trust their technical leads - not assume that they have more knowledge than the technical lead
I once told a manager that; "I would rather club small furry animals with a stick for food than work for him." Moved on and was infinitely happier in a new position
"Test arena" and "production code". I tend to object to this separation. I believe test should be also a formal part of the development process: all in the same big tem.
aye! Manager should have technical knowledge if managing a technical team! Or make wrong decicions is talent aquisition, not understand what the team is communicating and make bad decisions.
Management? I guess they have to put first things first..So many times, We talk about technical feasibility and the discussion goes towards cost cutting..isnt it more important to make it work and then worry about costs?
Many years ago, a manager said, "Good engineers are a dime a dozen, but a good manager is hard to find." That says a lot about the attitude of managers toward engineers. In part, he was correct: "Good managers are hard to find."
The day I left the company, I gave this manager a dime and told him he would need it. :.)
Management is another challenge. It is good for the right people bad choice for others. Good managers are a great benefit to a project, poor ones can ruin a project.
I left HP a few years ago because Hurd took all the financial rewards away from the really good technical people and gave it to some really poor middle managers.
Had excellent experience with my Managers & Mentors over the years. Good people skills with technical skills as well. Moved into Engineering Management for my last 20 yrs
I'm a generalist PM, so I received much friction from senior SW programmers who had the attitude of "he's not an engr, he's a suit". I had to win them over one at a time and let them know I was a "wannabe engineer but couldn't hack the math". I had 6yrs of deckplate naval leadership to run with.
Well, some managers remember they were engineers once. lol! They try to help juniors grow! I don't really want to comment on their types! Gary's todays session speaks all about it!
Good managers need to part of the engineering team by interacting in the lab. Those that only run engineers from an office tend to direct without insight.
Most engineering management ranks are full of people who didn't like engineering enough to stay with it long enough to become good engineers. Then they're in a position where they feel vulnerable that the people they manage know they don't have good enough chops to do it themselves. And the social dynamic there becomes utterly terrible. The only good engineering managers I've seen were completely ego free or have been in engineering 20+ years themselves -- and that's very rare.
Insanity starts at the top. If your manager is insane, the whole group will be. Don't work for a company with an insane CEO. In R&D, I run into management issues where managers who are trained to be business men or manage manufacturing wreak havok because R&D is all about the unknown but those other fields are all about the known. Known is predictable. Unknown is not.
Best managers are those who worked in the trenches for a long time - Worst the one or two year engineers with an MBA :-) (Nothing against MBA - I have one - but got it after more than 15 years of experience as an engineer)
The engineers that make for good managers are the same that you can introduce the client to. The ones that you want to hide when the client come around, are in the right spot just solving engineering problems.
I work about 60 to 85 hours a week, lots of time after work to work on my robotics,,but I'm a typical engineer, so social skills, lol, engineers as managers,, very few are good,, but very few
I tend to value a job or project that keeps me interested and happily challenged. Management duties takes away from that becuse it isn't as hands on with what I like to do.
the more your job is like hobby the better. you produce far more quality work in an efficient manner.
for me i dig distributed computing using command semaphores between device and c# based hosts with simple packet passing protocols, fun stuff. can access and manipulate control registers, ect.
Alexander Wolfe: What's the most significant point that you think Gary made this week, point or info that's new to you?
During Part 2 of this track, Gary talked about Test Plans. To make his points, he provided stories of his experiences at HP. We ALL are familiar with ink jet printers, and hearing his stories of HPs testing allow his points to be driven home in excellent fashion. We don't get to see behind the curtain very often, so this was the next best thing to getting a tour at HP. Well done, Gary!
and yes I agree with working myself out of a job, the knowledge I pass is free, so I figure work hard, ensure the company can use your data after to leave and you've find you never leave.. problem you never get promoted either, two headed coin
Oh yeah... the term "hackware" is new to me, but the concept is not. Do it all the time to flesh out potential problems with new software routines or hardware changes.
Wosniak an Jobs split, becaue Woz didn't want to make money, just be a geek, and Jobs dodn't want to make money with just any type of business activity. Jobs wanted to be only involved with the best product from the perpective of the customer and plain art.
I design embedded systems so have to debug both hardware and software and decide which one (or both is at fault). And, yes, engineer's egos get involved!
Electrical engineer, software/firmware development primarily but hardware design as needed. Everything from initial bringup and debug of hardware to quality problems on the line.
debug and test over 8 years time frame in production environment, cross trained into MS .NET after which i created terminal emulator applications for both verification engineering and validation engineering stages. now i am doing c# host to device targets with RS232, IC2, SPI and other protocols and OEM test gear control using SCPI all over C# based tools
Been heavily involved in debug and test. In fact, we spend 3x as much time in testbench development as we do developing the actual source code or design. It's often in designing the test that we locate the corner cases that make the design itself better. If you go into the lab to see what will happen, you're already screwed. You go there already knowing, because you've thought the tests through as part of the design.
i design/build MS .NET interface to embedded and other device targets - i am creating youtube video series to illustrate my services - please contact me for further on my services, cheers
Alex - I received a nice email from UBM / Design News regarding an offer for attending today's session. While I appreciate the offer, I'd personally rather not have to deal with my corporate ethics department. Can UBM / Design News donate the "gift" to charity?
The streaming audio player will appear on this web page when the show starts at 2pm eastern Friday. Note however that some companies block live audio streams. If when the show starts you don't hear any audio, try refreshing your browser.
For 3D printing to make the jump from rapid prototyping to manufacturing, engineers will need to find easier ways to move products from their CAD screens to their printers.
Gigabit and PoE are two networking technologies moving ahead in tandem as industrial users power remote Ethernet devices such as IP security cameras at 1,000 Mbps over existing CAT5 cable.
New versions of BASF's Ecovio line are both compostable and designed for either injection molding or thermoforming. These combinations are becoming more common for the single-use bioplastics used in food service and food packaging applications, but are still not widely available.
From Dell / Intel® New Paradigms in Design Work Scott Hamilton, vertical market strategist for Dell Precision workstations, 5/2/2013 5
Early in my career, I worked as a draftsman and remember the days of drawing on vellum with numbered pencils and Mylar with plastic lead. This was a fun experience in the sense that I ...
I've been using workstations for more than 10 years and love finding ways to get more performance from my system. With demanding professional applications that require more power each ...
A lasting memory from my first job as an engineer in an auto assembly plant is standing on hard concrete at six in the morning, vending-machine coffee clutched in hand, listening to ...
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This radio show will show what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.
To save this item to your list of favorite Design News content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
2 
