"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!" http://tinyurl.com/ljuv88l -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
New book coming out
Started by ●August 4, 2014
Reply by ●August 4, 20142014-08-04
On Mon, 04 Aug 2014 16:00:33 -0500, Tim Wescott <tim@seemywebsite.really> wrote:>"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!" > >http://tinyurl.com/ljuv88lI 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 by ●August 4, 20142014-08-04
On Mon, 04 Aug 2014 14:10:31 -0700, John Larkin wrote:> On Mon, 04 Aug 2014 16:00:33 -0500, Tim Wescott > <tim@seemywebsite.really> wrote: > >>"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!" >> >>http://tinyurl.com/ljuv88l > > 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.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 by ●August 6, 20142014-08-06
On 05/08/14 07:10, John Larkin wrote:> On Mon, 04 Aug 2014 16:00:33 -0500, Tim Wescott > <tim@seemywebsite.really> wrote: >> "Expert Guide to Program Management for Developing Embedded >> Systems", edited by Kim Fowler. Comes out the end of September. >> 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.That sounds great, Tim, and what you said above is totally applicable to software-only projects too, and very necessary.> 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.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.> People don't pay enough attention to the human factors of electronic > design. They think design is scientific or something.Design is to find the best compromise, including human factors as well as technical ones.
