Yes 'Qzz' ; thats a nice twist on 'Correct, Cheap or Soon - pick any two'. Chris G - analog is the best place to start engineering because you can understand everything else from there. Once you've seen a PLL's lock-in transient and really 'got it!', everything else will seem dull (except possibly the sheer effrontery of the Stack). Anyone else care to share the engineering features that lit up their path to enlightment?
Has anyone talked about the dependent and independent variables in project management? If you fix the performance then you don't know the cost or schedule. If you fix the cost then you don't know the performance. etc
I unfortunately missed that session, being stuck in my booth for the whole show, but it sounds like a great one.
The joke has always been that engineering schedules are meaningless because you can't schedule the unknown. In my experience though, most experienced engineers can do a pretty decent job of predicting their development schedules. After having been through a few cycles of the "unknown", they get a feel for how their problems solving goes and on balance, they can make pretty good estimations.
Certainly there are design challenges that come up from time to time that will flatten the best engineer, but the biggest issues always seem to come from feature creep, schedule shrinkage or budget changes.
The real challenge for management is in letting the design team to hold tight to to the spec and schedule - not changing for the worse after a certain point in the project unless there's a very good reason. The real world all too often works very hard against the quest to hold true to the original plan, but in the majority of cases I've seen, the extra week or two that the engineers had originally asked for would well pay for itself via reduced post-design problems and happier customers.
My Mom the Radio Star Max MaxfieldPost a comment I've said it before and I'll say it again -- it's a funny old world when you come to think about it. Last Friday lunchtime, for example, I received an email from Tim Levell, the editor for ...
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...