New book coming out

"Expert Guide to Program Management for Developing Embedded Systems", edited by Kim Fowler. Comes out the end of September.

I wrote chapter 8, "The Discipline of System Design".

The way the chapter took shape was interesting: Kim had wanted me to write a chapter that was mostly about applying control theory to systems with feedback control; instead, that subject kept shrinking until it was just an example and a pointer to a book.

What happened was that I kept circling back to "jeeze, there's going to be wet-behind-the-ears college kids reading this, and I'm writing it like the world is an ideal place!"

So the chapter ended up having a lot of material on solving the real- world problems of extracting comprehensive specifications from non- engineers, how to prototype things for business managers so they know where you're going without thinking you're further than you are, how to design and partition complex systems from the ground up, when to buy stuff vs. when to build it, ways to organize your project team so that systems design doesn't get neglected until integration time, and stuff like that.

I really liked working with Kim. He probably wrote about 10% of the material in the chapter, and we kind of pushed each other into writing something that was much better than I would have done had someone just given me the chapter title and said "go!"

formatting link

--

Tim Wescott 
Wescott Design Services 
http://www.wescottdesign.com
Reply to
Tim Wescott
Loading thread data ...

I might buy that.

I wonder if the stuff that you are talking about can be learned from a book, or is it more like skateboarding, where you just have to do it.

People don't pay enough attention to the human factors of electronic design. They think design is scientific or something.

--

John Larkin         Highland Technology, Inc 

jlarkin att highlandtechnology dott com 
http://www.highlandtechnology.com
Reply to
John Larkin

I don't think all of it can be learned from a book -- some of it sounds like pure BS until you've lived through it.

But there's other material in my chapter that is more concrete and easy to assimilate, like how production volume affects build vs. buy decisions, and some of the commonly used terms at the intersection of finance and engineering like COGS, BOM cost, opportunity cost, NRE, etc.

Someone may read the chapter and realize that yes, you really do want to split your system design into bite-sized chunks, and furthermore that splitting it into chunks that are connected by a pair of power wires and a pair of communications wires is better than splitting it into chunks that are connected by three dozen low-level analog signals lying next to some 500W motor drive leads.

I do think that while a total newbie may not learn it all from the book, they will be prepared to learn it faster once they get on the job and reality slaps them in the face like a week-old cod.

--

Tim Wescott 
Wescott Design Services 
http://www.wescottdesign.com
Reply to
Tim Wescott

ted by Kim Fowler. Comes out the end of September.

write a chapter that was mostly about applying control theory to systems with feedback control; instead, that subject kept shrinking until it was just an example and a pointer to a book.

be wet-behind-the-ears college kids reading this, and I'm writing it like the world is an ideal place!"

world problems of extracting comprehensive specifications from non- engineers, how to prototype things for business managers so they know where you're going without thinking you're further than you are, how to des ign and partition complex systems from the ground up, when to buy stuff vs. when to build it, ways to organize your project team so that systems desig n doesn't get neglected until integration time, and stuff like that.

Sounds very good indeed.

material in the chapter, and we kind of pushed each other into writing something that was much better than I would have done had someone just given me the chapter title and said "go!"

ok, or is it more like skateboarding, where you just have to do it.

People differ in the amount of stuff than can learn by reading books. You d on't seem to be a member of the group that can learn a lot. You do cite Wil liams and Taylor's "Electronic Filter Design Handbook" from time to time, b ut you also cite Don Lancaster's "Active Filter Cookbook" which is easier t o follow, if less comprehensive.

gn. They think design is scientific or something.

Only if they haven't done any of it. It's an art, like every other kind of creative synthesis, where there a lots of different ways of achieving a des ired result. And of course the result desired depends on the competence of the person perceiving the problem that needs to be solved.

The phrase "lets take a step back and look at this in it's context" isn't h eard often enough.

--
Bill Sloman, Sydney
Reply to
Bill Sloman

That sounds great, Tim, and what you said above is totally applicable to software-only projects too, and very necessary.

You can't learn to do it perhaps, but you can learn which things you should be doing. If you don't know those, you'll never even attempt them, and can never learn how.

Design is to find the best compromise, including human factors as well as technical ones.

Reply to
Clifford Heath

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.