Debouncing....at About 1Mhz - Uobtanium Obtained ;-)
in [Design]
|
Prev: TL499A boost converter question
Next: PIC sanity test
From: Charlie Edmondson on 13 Nov 2007 11:54 John Larkin wrote: > On Mon, 12 Nov 2007 13:40:30 -0800, Charlie Edmondson > <edmondson(a)ieee.org> wrote: > > >>John Larkin wrote: >> >>>On Sun, 11 Nov 2007 09:05:43 -0700, Jim Thompson >>><To-Email-Use-The-Envelope-Icon(a)My-Web-Site.com> wrote: >>> >>> >>> >>>>On Sun, 11 Nov 2007 07:50:44 -0800, John Larkin >>>><jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >>>> >>>> >>>> >>>>>On Sun, 11 Nov 2007 08:25:59 -0700, Jim Thompson >>>>><To-Email-Use-The-Envelope-Icon(a)My-Web-Site.com> wrote: >>>>> >>>> >>>>[snip] >>>> >>>> >>>>>>When I feel confused I drinks a glass of wine ;-) >>>>>> >>>>>> ...Jim Thompson >>>>> >>>>> >>>>>One of the great engineering virtues is laziness. I consider a circuit >>>>>or a piece of code or a mechanism and say "that's going to be way too >>>>>much work" so I put it off for a while, or talk to somebody about it. >>>>>Usually something simpler emerges. Too many people, cursed with excess >>>>>energy, just plow ahead and implement the first idea they have. And >>>>>when it turns out to have bugs, as complex things will, they add stuff >>>>>to repair the bugs. >>>>> >>>>>John >>>> >>>>I've been known to toss designs that I had been working for >>>>weeks/months, because of too many "patches". >>>> >>>>Panics the hell out of clients until they see the results of a clean >>>>start. >>>> >>>> ...Jim Thompson >>> >>> >>> >>>It takes guts to dump something you've put three months into. Even if >>>the new thing would be better and finished sooner. It's even more >>>difficult in a team design, where peer pressure exists. But yeah, I'll >>>consider dumping a design that's far along, even finished, when a >>>better or simpler idea pops up, or when the original starts creaking >>>of its own weight. >>> >>>That's why it's better to not start too soon, to play with ideas for a >>>while at the start. >>> >>>John >>> >> >>On a similiar subject... >> >>A team I was working with was developing a vehicle classifier using an >>overhead laser rangefinder and some other sensors. Their problem was >>that the laser system was not very accurate or precise, it gave the >>range to a vehicle with an 'error' of several inches. The laser system >>had actually been developed just to detect presense, not range, and >>range was just an unsupported feature. >> >>So, the team went to work. Unfortunately, they were of the 'hacker' >>level of software developers - lets write code, and figure out how to do >>things later! So, after about four months, they had working code, but >>it was of the consistency of spaghetti, having had four different >>hackers working on it simultaneously. >> >>So, the project team went to management and said "We now know how to do >>it, and make good determinations. Let us have another month, and we can >>start from scratch and build it right, from the ground up, and you will >>have a system that will be much more stable and dependable. >> >>Management told them to get off their duffs and start on the next >>project, the system worked and that was all they needed, and that they >>were behind schedule anyway. >> >>Then they fired the head of R&D! >> >>I transfered out to the field... >> >>Charlie > > > Engineers should just say "no, it's not good enough, it's not ready, > and we won't release it until it is." > > Really. > > John > Yep, but then management always has the option of then firing the design team, which in this case was a real threat. They instead just fired the manager, and broke up the team. Charlie
From: Jim Thompson on 13 Nov 2007 12:09 On Tue, 13 Nov 2007 08:54:14 -0800, Charlie Edmondson <edmondson(a)ieee.org> wrote: >John Larkin wrote: > [snip] >> >> Engineers should just say "no, it's not good enough, it's not ready, >> and we won't release it until it is." >> >> Really. >> >> John >> >Yep, but then management always has the option of then firing the design >team, which in this case was a real threat. They instead just fired the >manager, and broke up the team. > >Charlie Most of the time I've had the luxury of being the "hired gun" and they wanted ME to sign off on the project. Even happened once during the Shuttle redesign. I dug in my heels and won the changes necessary. ...Jim Thompson -- | James E.Thompson, P.E. | mens | | Analog Innovations, Inc. | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | Phoenix, Arizona Voice:(480)460-2350 | | | E-mail Address at Website Fax:(480)460-2142 | Brass Rat | | http://www.analog-innovations.com | 1962 | America: Land of the Free, Because of the Brave
From: John Larkin on 13 Nov 2007 12:12 On Tue, 13 Nov 2007 08:54:14 -0800, Charlie Edmondson <edmondson(a)ieee.org> wrote: >>>On a similiar subject... >>> >>>A team I was working with was developing a vehicle classifier using an >>>overhead laser rangefinder and some other sensors. Their problem was >>>that the laser system was not very accurate or precise, it gave the >>>range to a vehicle with an 'error' of several inches. The laser system >>>had actually been developed just to detect presense, not range, and >>>range was just an unsupported feature. >>> >>>So, the team went to work. Unfortunately, they were of the 'hacker' >>>level of software developers - lets write code, and figure out how to do >>>things later! So, after about four months, they had working code, but >>>it was of the consistency of spaghetti, having had four different >>>hackers working on it simultaneously. >>> >>>So, the project team went to management and said "We now know how to do >>>it, and make good determinations. Let us have another month, and we can >>>start from scratch and build it right, from the ground up, and you will >>>have a system that will be much more stable and dependable. >>> >>>Management told them to get off their duffs and start on the next >>>project, the system worked and that was all they needed, and that they >>>were behind schedule anyway. >>> >>>Then they fired the head of R&D! >>> >>>I transfered out to the field... >>> >>>Charlie >> >> >> Engineers should just say "no, it's not good enough, it's not ready, >> and we won't release it until it is." >> >> Really. >> >> John >> >Yep, but then management always has the option of then firing the design >team, which in this case was a real threat. They instead just fired the >manager, and broke up the team. > >Charlie I have two reactions to that: 1. If they fired the team, the project would be delayed a lot more than if they negotiated a cleanup/release plan that delivered a good product. So they probably wouldn't fire them. 2. If I discovered that my management was such jerks, I'd quit before they could fire me. John
From: John Larkin on 13 Nov 2007 12:24 On Tue, 13 Nov 2007 10:09:11 -0700, Jim Thompson <To-Email-Use-The-Envelope-Icon(a)My-Web-Site.com> wrote: >On Tue, 13 Nov 2007 08:54:14 -0800, Charlie Edmondson ><edmondson(a)ieee.org> wrote: > >>John Larkin wrote: >> >[snip] >>> >>> Engineers should just say "no, it's not good enough, it's not ready, >>> and we won't release it until it is." >>> >>> Really. >>> >>> John >>> >>Yep, but then management always has the option of then firing the design >>team, which in this case was a real threat. They instead just fired the >>manager, and broke up the team. >> >>Charlie > >Most of the time I've had the luxury of being the "hired gun" and they >wanted ME to sign off on the project. Even happened once during the >Shuttle redesign. I dug in my heels and won the changes necessary. > > ...Jim Thompson Yup, management is easy to manage. Just set it up so that if they don't do what you want, success or failure will be their public responsibility. That works miracles. The function of management is to provide engineering with the resources it needs to do good work, to do the admin scut work so we can design. John
From: Charlie Edmondson on 13 Nov 2007 13:59
John Larkin wrote: > On Tue, 13 Nov 2007 08:54:14 -0800, Charlie Edmondson > <edmondson(a)ieee.org> wrote: > > >>>>On a similiar subject... >>>> >>>>A team I was working with was developing a vehicle classifier using an >>>>overhead laser rangefinder and some other sensors. Their problem was >>>>that the laser system was not very accurate or precise, it gave the >>>>range to a vehicle with an 'error' of several inches. The laser system >>>>had actually been developed just to detect presense, not range, and >>>>range was just an unsupported feature. >>>> >>>>So, the team went to work. Unfortunately, they were of the 'hacker' >>>>level of software developers - lets write code, and figure out how to do >>>>things later! So, after about four months, they had working code, but >>>>it was of the consistency of spaghetti, having had four different >>>>hackers working on it simultaneously. >>>> >>>>So, the project team went to management and said "We now know how to do >>>>it, and make good determinations. Let us have another month, and we can >>>>start from scratch and build it right, from the ground up, and you will >>>>have a system that will be much more stable and dependable. >>>> >>>>Management told them to get off their duffs and start on the next >>>>project, the system worked and that was all they needed, and that they >>>>were behind schedule anyway. >>>> >>>>Then they fired the head of R&D! >>>> >>>>I transfered out to the field... >>>> >>>>Charlie >>> >>> >>>Engineers should just say "no, it's not good enough, it's not ready, >>>and we won't release it until it is." >>> >>>Really. >>> >>>John >>> >> >>Yep, but then management always has the option of then firing the design >>team, which in this case was a real threat. They instead just fired the >>manager, and broke up the team. >> >>Charlie > > > I have two reactions to that: > > 1. If they fired the team, the project would be delayed a lot more > than if they negotiated a cleanup/release plan that delivered a good > product. So they probably wouldn't fire them. > > 2. If I discovered that my management was such jerks, I'd quit before > they could fire me. > > John > Yeah, but they had the 'product' that they needed to fulfil a contract requirement, even if it was a piece of cr*p, and that was all they really cared about. They kept most of the team on, and made one of the senior folk the new 'manager' (on a very short leash!) for the 9 months they spent keeping the team on until the contract was ready to finish. I transfered to the actual project from the R&D team to get back to CA and out of Omaha, and was laid off a year later (also referred to as my Year in Hell...) Should have quit, but they held this big carrot of bonuses if I stayed out the project. Then, just before Christmas, they had a special meeting where they handed out the bonus checks. Imagine my reaction when at the end of the meeting, I was the only one that didn't get a check! I should have sued them, but just wanted out so bad that I just left... Charlie |