Embedded - 269: Ultra-Precise Death Ray

Episode Date: December 6, 2018

Alan Cohen (@proto2product) wrote a great book about taking an idea and making it into a product. We spoke with him about the development process and the eleven deadly sins of product development. We did not talk about ultra-precise death rays. Books we discussed: Alan’s Prototype to Product: A Practical Guide for Getting to Market Elecia’s Making Embedded Systems The Mythical Man-Month, Anniversary Edition: Essays On Software Engineering by Frederick P. Brooks Jr.   The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier Alan mentioned writing software graphically with Enterprise Architect

Hello, and welcome to Embedded. I am Elysia White, here with Christopher White. Have you ever wished for a book that could help you understand the path from idea to product? It turns out there is such a book, and it is a pretty good one. Its author is our guest, Alan Cohen, Prototype to Product, a Practical Guide for Getting to Market. Hi, Alan. Thanks for joining us.

Hi. Thanks for having me. Could you tell us about your background? Sure. I am a systems engineer. My background prior to doing systems engineering is in electronics and software. My career has been in product development, primarily in the development of medical devices. So probably about 80% of what I've done is medical devices, but I've done a few other things as well. And I'm also an author of the O'Reilly book, Prototype to Product, A Practical Guide to Getting to Market. Currently, I'm at Massachusetts General Hospital

on the Department of Radiation Oncology, where I'm helping to do some renovations on a very, very large medical device, something called a proton therapy system, which is basically an ultra-precise death ray that does a 3D scan of a tumor. The listeners are going to be really angry when I don't ask anything about the ultra-precise death ray. Yeah. But maybe we'll get to that at the end, or maybe not.

Okay. Okay, so lightning round is on break due to recent extensive lightning-related questions. You've been spared. You've been spared. You've been spared. Okay. I hope that's okay. So let's get straight to your book. Uh, I have heard that if everyone in Silicon Valley and other tech centers read and followed the advice in your book, products would be cheaper, less engineering time would be wasted,

and general happiness would descend over the world. And puppies. Happiness and puppies? Is that all correct? I mean, is that a good summary of your book? Well, I think that that's certainly the intent, and I think it would go a long way. It's not the only thing that would cause those things to happen.

But yeah, I think that the intent is to give people a realistic overview of what the product development process is like. A lot of people just sort of stumble into it and try different things and find out that it's a little different than what they thought it was going to be. So the idea is to give people an idea of what it will be like and also to give them some recipes for things that will help them to minimize the path between prototype and product and getting to market. So who's your intended audience? Is this an MBA sort of book or an engineering sort of book? Well, the intent is for it to be an everything, an everybody kind of a book. So one thing I should maybe describe a little bit is what a systems engineer is.

I think a lot of your audience probably knows what that is, but some may not. So a systems engineer is an engineer that's responsible for the system as a whole. So in any large engineering effort, particularly when there's hardware involved, there'll be different types of engineers. There'll be software developers. There'll be hardware, electrical engineers, mechanical engineers, designers, various disciplines. So a systems engineer traditionally is the person or set of people that try to bring everybody together as a group to make sure that you end up with a product that, you know,

adheres to what its, you know, sort of goal is. It's, you know, the vision of the product, as opposed to being different disparate sets of things that happen to be cobbled, you know, past vision of the product, as opposed to being different disparate sets of things that happen to be cobbled, you know, pasted together. So as a systems engineer, I'm working with various people in various engineering disciplines, but also working with, you know, various management and sales types and, you know, different people throughout the organization. And I tend to spend a lot of time describing to different people what, I guess, first of all, what the overall product development process is.

But then also each group kind of wants to know what the other groups are doing and why things are taking so long. Or, gee, why does it take, the CEO might say, well, you know, a $200 cell phone and I've got USB on it. So why is it going to take $20,000 and four weeks to design USB on our product? And, you know, so I have to describe those types of things. So the hope was to write a book that would cover sort of a little bit of everything at a high level and how everything hangs together so that people participating in the project would understand those things. And it's that job of integration that gets skipped over a lot.

Having somebody have that actual job of getting all the different people in the same room. Sometimes it's just getting people in the same room to argue or to hash things out. That's a really important thing that a lot of companies kind of skip over until the end of the project when things don't work together. Yes, I agree with you 100%.

It's critical, and the best time to do that is the beginning, as early as possible, because as I touch on in my book, sort of the fundamental law of product development is that the earlier that you find issues, the things you want to change, the cheaper it is. As time goes on, things become exponentially more expensive to change. So getting people together at the start and arguing in some sort of a process, that's sort of where the systems engineering comes in. It puts a process around those debates and arguments. So you come out of those with everybody hopefully being on the same page and requirements and specifications for a great product. And then people can go off and build it.

Requirements and specifications. Gosh, that sounds waterfall-ish. That sounds so nice. Sounds so great. Can we please go back to a system that makes sense? Oh, sorry. Yeah. Well, it's, you know, I shouldn't. Well, coming from medical, that's unavoidable.

It's true. Well, it is. And although I don't want to leave anybody with the impression that you start off with perfect requirements and specifications, you can do a reasonable job at the beginning, better than probably most people do from what I've seen in product development. But things will evolve as the system moves forward, as the development moves forward. It's funny, in your book, as I discovered it, I started highlighting things. And I'm not much of a highlighter as far as books go, but stuff just, like, made sense.

And it made sense in ways that I could explain to other people. One of the things you had was a quote from General Dwight Eisenhower, plans are worthless, but planning is everything. And then you went on to say, while specific plans are inevitably broken by the end of the first week of work, spending substantial time and effort in the planning process is indispensable. Could you talk a little bit more about that? Sure. Yeah, so I think there's a few reasons why you put together a project plan. over budget, sometimes by a lot. They tend to be delayed sometimes by a lot.

A lot of the reason for that is just lack of understanding what the project actually involved. So by putting a lot of time into building a detailed project plan, even though a lot of your details might be wrong, you're going to catch a lot of things that you wouldn't, you know, sort of take into account if you're doing things off the top of your head. You know, so like, let's say you're talking about, let's say a board spin, you know, electronics, you know, doing a new PC board. You might forget, you know, when you're, you know, sort of just guesstimating how long it's going to take to do a new board spin. You might think about, well, the layout should take this long and, you know, then we build

it and then, you know, give it a week to test. But, you know, you're not thinking about maybe, oh, gee, we got to, you know, make sure we have a couple of rounder reviews of the board before we send it off to the vendor. And those things need to be scheduled with people. You know, people can't just, you know, pop out of their cubes and do a review when you want them to do a review, not if you want to do a good review. You have to take into account, you know, the initial board bring up and what happens if, you know, it turns out that there's some problem on the board and you need to do some, you know, cuts and jumpers and things like that. So as you walk through the process in detail, you'll pick up a lot of issues. And then,

you know, suddenly you'll realize that, gee, it's going to take twice as long as my gut told me it was going to take when you put all these things together. So that's important. The other thing that's important is to understand dependencies. I guess I touched on that a little bit, but there are different parts of the project that can be dependent on other parts. And if you're not thinking about what those dependencies are, then you could get very surprised when something's, some part of the project is ready to go forward. But, you know, like, let's say the electronics are, you know, done, but the software is not caught up yet and doesn't have certain milestones met yet. So you need to understand what those things are that you're dependent on, that the different

parts of the project are dependent on in order to, you know, for things to proceed at the fastest possible rate. Another thing that you can do during planning is to understand what are the signs that I'm succeeding or failing? So you can think about, you know, how do I show myself and everybody on the project that things are progressing the way we want them to progress. Or conversely, if they're not, we can flag things and we'll know there's a problem and we have to attend to it.

So that's kind of what I mean by planning. The best laid plans will break quickly, but you'll at least have a good shot at a reasonable plan. And as time goes on, you keep your project plan up to date, and it'll give you a good idea of what's going to happen moving forward. But these do take time. Ideally, they save time in the end, but so many times I hear from people, oh, writing a requirement spec is just too much effort, and then we'll have to change it every week. We won't get anything done. We'll spend all our time dorking with the documents. How can I tell them, no, maybe if we write a good document and just update it once a month,

we'll all be making the same project. How do I get people to pay me to do the right sort of engineering instead of just slamming it all together? It's a very valid point. I think that both sides have a good point, right? I think that engineers, you know, doers, the people who are building the system don't want to spend time dealing with, you know, filling out forms and planning and things like that,

particularly not once they're in the thick of it. And it's also difficult, it can be difficult for organizations to accept that kind of planning, spending money on that. Particularly people who are non-technical people, they want to see engineers doing engineering very often and not, you know, planning. And I don't actually have a great answer to that other than to pick good companies to work for. So in my experience, the company culture is very difficult to change. And in very good companies, so the very good companies that I've worked for or with, there's a very good understanding of how important this process is. You know, and in fact, I'll tell you a little story. One, I remember one time I was working for a company, we were doing, well, it was a company

about 100, we had about 150 designers and engineers, and we were doing contract development. About half of our work was contract medical device development. And one of the large medical device makers, a very good, well-known maker, they needed some work done. They needed a new device developed, next generation of some device. And they sort of did a bake-off. And they started with about 10 companies, and they got initial quotes from those companies and ours was one of them. And I was, I co-led the effort to quote for them. So we made it through that first round. They picked like the three ones they liked the best. And then they asked for, you know, very detailed quotes. So

you know, we gave them a detailed quote and I got a call and they, the person who was leading the effort on their side said, we'd like to come over and talk with you guys about your quote. So I said, sure, of course. So they came over, and they started by saying, you guys were the most expensive by far of the bids we got. So, of course, my heart sank because usually cost is the driver. And they said, but you guys were the only people who obviously understood what needed to be done and did the proper planning to understand what this project was going to look like. So therefore, you guys get the job. So in that case, even though we were more expensive, because that was an organization that understood how important the planning was, they would pay a premium for that. It's good to hear a success story when someone actually realizes

that you've put thought into it and is willing to pay the extra money. But I know that when I've done a schedule, or I've seen when Chris does a schedule, and we think about the whole system, even though our part is the firmware, we tend to be the end, so you kind of want to think about the whole system so that you don't just end up being the end of the dog, of the tail, of the wagging.

Yeah. And yet, I've been told that the result is far too long. We should be able to do better than that. We should be able to innovate. You engineers, you always sandbag things. Exactly. And then at the end of the project, it pretty much went according to our schedule. Because we had the mechanical, electrical retry, because of course it's going to happen.

How do you make them listen? How do you make them realize that, no, really, this is what it's going to be. You can't say we're going to ship whatever we have in a year. It's a minimum viable product for a product that takes 18 months to do. Yeah. So I have some, I know some sort of tactics that have been helpful, but I don't have a magic bullet for it, certainly. So one thing is, one of the nice things about a detailed project plan is that you can put that in front of people and say, this is, you know, here I've got 200 lines of tasks on this project plan, on this Gantt chart. And they're documented, you know. Let's walk through this together and maybe you can help me. Maybe I'm not understanding the project properly. And maybe, you know, as we walk through this, you can tell me that there are things here that we don't need or that I'm overestimating time on. And that sometimes can be very good because then people, as they walk through it,

they realize that you've really thought things through. And, and also maybe you'll find out that, you know, you're, you're over- over engineering something um the other thing you could do is set things up as as um uh sort of contingencies based on um uh assumptions not being correct so you can and actually this is very important whenever you do a project plan is to put together a set of assumptions and you you know, that are, that are reasonable assumptions. Don't make kind of crazy assumptions, you know, and then say, Hey, in the event that X happens, then, you know, this project changes. And here's sort of, you know, how it might change rather than building everything right into the project

plan initially. Yeah. If you contingency or plan B's paths is nice. And I agree that bombarding them with actual information is sometimes helpful. And yet I have still been in that meeting where they say, well, we just can't afford for it to go on this long, so it'll have to be shorter. And I, yeah, I guess I've walked from at least one of those companies. But I wish more people would realize. Well, I think that part of it is back scheduling, right? They decide we need a product by June of 2019.

Yeah. And so everything has to be done by April of 2019. And then everything has to line up to that. And the resources you have are the same. And it's just kind of a fiction, right? Oh, yeah. Recently I had a client and I was like, oh, we want it by March 1st. And I'm like, and I gave them the schedule for my work and it led out to June.

And I said, you're not going to have it by March 1st no matter what I do. So, uh, yeah, it's not that I'm taking too long. It's just that you have no idea it's going to take this long. I guess my point is that's contrary to both Agile and Waterfall and any other method where Agile is supposed to be, well, there is no set date. Really. You're, you're working towards a minimum viable product at all times. And, you work in small increments and waterfall as well we we spec everything out and and then we plan based on how long we think it's going to take and then we get the date so back scheduling is i think the root of a lot of the problems and it it's contrary to almost all planning but it's important for businesses because they have this much money there's this conflict we have to ship something for ces or for some conference so yeah there's always that tension

yeah and i think you know certainly you can have a conversation around that so if if somebody you know if a company has some something they want to hit like like CES or one of the medical trade shows or something, I think it's good to sit down and have a conversation about that and say, okay, well, let's talk about what could be done by then and then try to prioritize and understand what's most important here. Is it having something because you've promised your shareholders that you'd file with FDA by a certain date? Or, you know, is it more important to get the final product out? Or, you know, and it can be challenging. It takes a while.

I mean, planning is, you know, it takes time. And, you know, people often feel like that's taking away from doing time. But it really is doing time. Your product will be completed faster and cheaper if you put that legwork in. And it's interesting, if you look at by industry, the industries that do sort of the largest, scariest engineering projects, I think. So, you know, aerospace, automotive, healthcare, you know, medical devices, military, they understand, you know, they have very strong cultures of having a process where, you know, you do a good job, a thorough job of planning beforehand, you know, just sit down, you start working. Yeah. and when i went from a medical company to a military company or faa sort of company it it wasn't hard i already knew all the processes but when i went

from an faa product to consumer toys i was severely over engineering things and i just needed to understand no it's okay if it fails in the field. It's fine. Nobody dies. It's fine. Right, exactly. Maybe a kid cries, but that's okay. Yeah, right.

Yeah, absolutely. One of the things in your book that I highlighted, I can't believe I highlighted this much. The goal of detailed product definition is to minimize bad surprises. I sometimes think we should change the phrase detailed planning to surprise management as it sounds less stuffy. Yes. Have you gotten any takers on that? Because I kind of, yeah, if I told a CFO or a CEO, no, no, we're not going to go into detailed planning right now. We're just going to do a little bit of surprise management. They would be into that.

I mean, I do sometimes say risk management, and they're more willing to let me do a plan. But have you had much success? Well, yeah, I do almost always use that phrase when I'm discussing, you know, detailed requirements and specifications and planning, you know, to continually remind people that that's what we're really trying to do here. You know, in the medical area, risk management tends to mean something a little different, but it is managing risk, right? It's managing the risk of an unpredictable product or unpredictable development cycle, which is ruinous. If you can't predict how much something's going

to cost and how long it's going to take, you can get into pretty big trouble as a company. So yes, I do use that phrase, and it does resonate with people. Okay, so I have been getting into detailed parts of your book, but I probably should go back to the general question of how do you suggest getting from a prototype to a product? Yeah, can you summarize your book in 25 to 30 words instead of 400 pages? Let's see. Very thoughtful iteration. It's really about, so there's a tension in product development.

And it's kind of the tension between agile and waterfall in a way. When you're building a product, it's one thing to have a prototype, right? So nowadays, it's so easy to put together a prototype. It's just unbelievable. It's so wonderful that we can now. It used to be hard, and now I'll just go to SparkFun and DigiKey and boom, boom, boom. Yeah, exactly. It's just it's incredible um you know my wife's tired of me sitting there and babbling about how like amazingly easy it is to like put together

something that does something unbelievably cool uh but building a product i think is now more difficult than it's ever been uh because people there's so many features uh that you know in products there's you know processors and everything and software and sometimes different layers of software and all kinds of fancy electronics and stuff, displays. So let's go back to Waterfall and Agile for a second. So in Waterfall, it doesn't have a very good reputation these days or a good name these days because I think that what had happened in the past is people who maybe weren't engineers would come up with some sort of a schedule for building things and say, we know what we're going to do, so therefore we know what the product's going to be. We know the engineers should know how to build it, so therefore this is the schedule we're going to follow and this is the path we're going to do. So therefore, we know what the product is going to be. We know the engineer should know how to build it.

So therefore, this is the schedule we're going to follow and this is the path we're going to follow. And that doesn't work so well, I think, because there's a lot of things you don't know when you're building a product. You really usually don't know exactly what the customer wants. One of the things I discuss in the book is that in the first chapter, the 11 deadly sins of product development, you know, it's, you should never assume that you know what the customer wants. You should also never assume that the customer knows what the customer wants. You've been there, huh? The customers, I think, don't know what they want until they have it in front of them. So that means that you can't just...

And then they just know they don't want this. Well, you go through a lot of that, right? And that's absolutely true. It's sort of a funny thing that when you build something that people like, maybe they're excited for five minutes and then it's just they're bored because it's like okay yeah this just does what i want okay um so you know it's kind of uh uh less you know i want i want like a parade and bells but i get oh yeah this is great this does what i want thanks um and then i've done my job i feel like i've done a really good job when oh you did what i asked great yeah right or what i. Or what I wanted. Well, sometimes they're good.

Really good customers will say, oh, well, it's doing what I asked, but it turns out that that's actually not going to work well. So yes, somebody who is sentient, that's great. I don't know what I want, but that's not it. Yeah, well, I think you have to start off assuming that that's generally true, particularly if it's a product that's something very new. If it's the ninth generation

of some product that's been around for eight generations, probably marketing has a pretty good idea of what the product should do, but if they're a good marketing group, they'll want to put prototypes in front of people. Functional prototypes that could just be UIs that mock the UI that they're intending to

build to make sure that people can use it properly. But I think in general, you know, and particularly for products that are really new things, until you put things in front of people and you iterate a number of times, until you get to the point where users can look at some sort of user experience, let's say, and say, yeah, that's the user experience I want and that's what I need to get my job done. You really don't know what you want to build. And that's kind of more agile-ish, right?

So I think that when I think of agile i think iteration um and when i think of waterfall i think you know prescribed and i think somehow you need to strike the balance between those two both in terms of the product's uh functionality uh but also in terms of the the nuts and bolts engineering you know so uh gee I need to build a circuit that does such and such, or I need to write code that does this thing. You shouldn't assume that you're just going to know how to do that first time out. You need to have a process that allows for some iterations until you get things right. But to do that in some sort of a framework where it's not 100 monkeys typing on typewriters trying to get Shakespeare, that there's some guidance and there's some sort of a process.

I have seen iterative waterfall as one of the things that goes in medical documents is the way to the process works, where you do a fast waterfall that's a prototype, and then you do a couple of slow ones, and then you do a fast one that's the final product after everything's been cleaned up do you use that terminology or do you have another i have used that terminology um i think that uh that could be used in different ways um so so i tend to be pragmatic in that I will use whatever terminology will resonate with the people who I am working with and or working for. So, you know, I would actually describe what I end up doing as being, you know, iterative waterfall where although more iterations within a waterfall. So there'll be specific processes and there'll be gates that sort of gate moving from one phase of a project to another phase of a project. And there are some, I think, very good reasons to do that. But within those phases, it'll be more agile-ish and waterfall-ish. Excuse me, agile-ish and there'll be a lot of iterating.

Yeah, but it's also important when you think about iterative waterfalls and agile that you do the whole process. You don't just start with, oh, okay, I'm in the middle of development phase, so I must just be doing development. No, in the beginning of this development phase, you probably want to maybe respec this, maybe do some testing. You don't want to do it linearly. That's where Waterfall got us in trouble is you were supposed to design, implement, and then test with no spins.

It was just one way, and that's no good. Oh, yeah. And you need to do all those things in parallel i think that there's so and i don't know if i cover this in the book i probably do i don't know if i have any illustrations but if you were to look at you know the different activities that need to be done you know um let's say uh you know, marketing research, specifications, requirements, specifications, building, testing, those things really happen in parallel to a large degree. Now, there are some things that happen a lot at the beginning and very little at the end. So requirements,

specifications, for example, and testing usually doesn't start during the planning phase. But you should be testing continuously while the product is being developed. I think if you're not developing your tests while you're developing your product, you're going to run into some bad surprises. And you talk about this on a systems scale because you're a systems engineer, but this same mentality works for just for anybody. I mean, for sitting down today and programming what I need to get done today. If I start out with the idea of requirements, which is what do I want to get done? What is this code supposed to do? And testability, how am I going to make sure it does this?

It's a lot different than sitting down and going, oh, well, I kind of want something like this, and I don't, yeah, I'm just going to type it. I'm just, I don't need to think about it. I'm just going to type it. Do you, do you interact with all of the small, do you, do you, do you try to convince people to use this sort of process on a smaller scale within their own disciplines? Oh, absolutely. Yeah. I think that the development process really needs to be set up, you know, to work that way, you know, as you're describing. The other thing that's very important, which you touched on, is people need to buy into what's being done. So you can't just prescribe to, say, electrical

engineers, here's how you're going to do this um i mean you can but that's not fun for anybody i think it's you know super duper important that anything you do in the way of process or really anything else that it's important to do um i guess quasi organically i'm not quite sure what to how to say it but uh but basically work with people to put processes into place that they feel are going to be helpful to them. And it aren't just, you know, those, those people with the suits telling them what to do, you know, it's not make work if you're doing it right.

Yeah. Everything should, there should be a really good reason for everything. And if people don't understand, uh, why they're doing something or they think it's a bad idea, then, you know, it probably, if you can't get to the point where you can convince them, then, you know, maybe you shouldn't be doing that or you need to do differently. I think that that's critical. And I think people underestimate, well, it's going to sound funny, but how good it feels when you execute to a plan. Oh, yeah.

You know, I know the A-team, you know, I love it when a plan comes together, but we've sort of lost that in a lot of development lately where we're just all kind of fighting fires on a bi-weekly basis, it seems like, and, you know, making little bits of progress. And then at the end of it, somehow something comes out of it. You're like, whoa, that was tough. Look, it's spaghetti monster. But the times I've been involved in a development out of it. You're like, whoa, that was tough. Look, a spaghetti monster. But the times I've been involved in a development process where we had a good plan, yeah, that we iterated on. And then we actually managed to execute on that.

That feels amazing because it kind of validates what you were thinking, right? And you end up with something that you wanted as opposed to a bunch of little things that kind of work together. Kind of a Darwinian approach to development of everything that dies, you know, we abandoned and this is the product that came out at the end. I think Chris and I are totally on board, but, but have you read the mythical man month?

Yes, I have actually, I just, cause you'd mentioned it recently in our correspondence, I just went back. I had read it about 20 years ago or something. And I went back and read it. It was very, I enjoyed rereading it. I found that I had, throughout my career, found that a lot of what Mr. Burke said was absolutely true.

But so few people do it. And it would make engineering lives easier it'd make business lives easier and yet people aren't willing to why what i still have conversations where you'll say you know oh we need to give a copy of that to to so and so or nine copies. Nine copies. Yeah. So they can read it faster. Yeah, yeah. Right. They can make that baby in one month if they've got nine women, right? So here's something I think we don't talk about a lot, particularly as engineers, but psychology is an amazing thing. Actually, I come from a family of psychologists.

My sister is a practicing psychologist. My father, she has a PhD in psychology. My father has a PhD in psychology. And the ability for the human mind to sort of hold two contradictory things at the same time and not have them affect each other is pretty amazing to me. So I find it's often the case that people will totally agree that it's super important to find out all the potential pitfalls early in a project, but then an hour later to say, no, we don't have time to figure this stuff out. We just have to get going.

And it's just an amazing thing to watch. And you can remind them that you can't make a baby in one month if you have nine women. You can remind them of various things that they know to be true. But sometimes they will just move in a certain direction. And I don't know how to change that. I think it tends to be an organizational thing. There are some organizations that believe in mind over matter, and they usually do not do very well. But I find that the good, the really good companies, you know, so for example, where I'm at now, Massachusetts General Hospital and some of the other people I've worked for, people are very aware that, you know, reality is reality and,

you know, you got to accept it and do the best you can with it. And no amount of magical thinking is going to, you know to make things work out better. But I've been at places where they say, oh, well, we'll just try. We'll just work hard. Literally give the old college a try. I've been told that. Do you ever feel like Cassandra, doomed to tell prophecies no one believes? Yes. In fact, I often tell people that I'm thinking of changing my name to Cassandra. So that's, yeah, that's my lot in life. But, you know, it's not because I'm particularly brilliant or anything.

It's just I've seen enough of this to know when projects fail, they tend to fail in certain predictable ways. That's actually where my first chapter came from. I think it's called the 11 Dead sins. Yeah, right. It's basically the things that tend to crop up all the time when projects fail, when product developments fail. And, you know, you can look at a project and they're not doing some of those things or, you know, they're committing some of those sins. And you just know there's going to be a problem. All you can really do is step back and watch.

Yeah, I liked that chapter. Was it one of your favorites? Yeah, it was my favorite. I mean, you talk about the vice of laziness, about putting off serious testing, the vice of assumption, knowing what people want. It was so funny to have them be called vices because that's what they are. And it's laziness or the vice of cluelessness. And the deadly sin there is number seven, not addressing regulations. Right.

Oh, please honk your horn if you've been there. All the time. Yeah, it happens. Although I have to, I can't take credit for couching those as deadly sins and vices. I originally, that chapter was originally titled 11 Ways to Screw Up a Project. And my editor at O'Reilly, actually two editors there sins, and the sins are related to the vices, but they aren't one for one. Right. The vice of hubris, which is deadly sin number 10, not planning to fail. I'm so amazed at how much information you can get in a meeting where you say, okay, let's pretend it's six months after the ship date and we have failed, failed in every way we can possibly fail. How do you think we did fail?

And going through and realizing that people know what's going wrong, but you didn't ask the question right. And that question leads to people saying, oh, well, we didn't do our marketing early enough, or it's uncomfortable, or people are allergic, or, and sure, you get a bunch of stuff you don't need. You get a lot of things that may not happen, that are easily preventable, but at least you get a picture. Yeah, I love the way you phrased that. You know, if it's six months after the project, I think you said six months, and we've totally failed, why have we failed?

I haven't heard that phrasing before, but I like that a lot. But yeah, it's very important to try to get those things out on the table as early as possible. Because people, like you said, they know a lot of this. They may not speak up about it, though. Because nobody likes to talk about things that can go wrong. But that's how you make things go right, is by recognizing the things that can go wrong. How was writing a book for you? You mentioned your O'Reilly editors.

Yes. Yeah, Megan Blanchett. She was very, very helpful in making this a better book. As well as the copy editor, Jillian McGarvey, who was phenomenal. She's the only copy editor I've ever had who was okay with my making up new words that don't exist yet in the English language. She actually thought that was fun. Editors tend to really not like it when you make up new words. So she's just fantastic. So yeah, they were both very, very helpful in making the book what it is for better.

They're responsible for the good parts. I'll take credit for the bad parts. So in terms of doing the book overall, yeah, I kind of have a love-hate relationship with writing. I enjoy it to some degree, and I don't enjoy it to some degree. I guess that's why it's a lot of hate. You know, it's very challenging. The thing I find I spend the most time on is thinking about how to explain something in a way that makes sense to people who, you know, aren't skilled in the art of whatever it is I'm explaining. That can be challenging to do. So I end up taking a lot of walks and thinking about how to explain something.

And the writing part itself takes time, certainly, and the editing and all that. So that takes time out from other things. But ultimately, it's a very rewarding experience. I guess anything really rewarding is rarely all positive all the time. What you said there about thinking about how to explain it to someone who doesn't know it, I have trouble explaining that concept to people who haven't written a book or haven't thought about it a lot. When you read a data sheet or when you read a technical book that maybe isn't that good,

and then six months later after you've finally learned all the material because you had to do it in order to get your job done, you go back to the book and it suddenly is a pretty good book. Why didn't you like it before? That's the sign of a book that is written for people who understand the material. Right. It's not teaching you. It might be a good reference book,

but that split is so hard to explain to people who haven't tried it. I don't know where I was going with that. The way you said that. Well, I think you said it very well. I think to write a good book, I don't know that I've ever written a good book, but for people who do write good books, there's a lot of thought that's put not just into what facts you're going to put out there but how are you going to present those in a way that tells a story and you know put something in the reader's head that you know sort of some sort of structure that helps them to understand you know what's happening and how things go to go together and that kind of thing so the book's just it's not a bunch of

disparate facts it's really a story trivia think. Yeah, and it has to build up. It can't just be, here, I'm going to throw these facts at you. It has to build a framework and then put things in the framework where they're appropriate. Yeah. By the way, I think I've read your book as well, and I think your book did a very good job of that as well. You know, it's the next time I have a sort of a budding firmware developer, I will give them that book to read. It was, yeah, did you, so one of the things I did was I had people in mind, particular people that I was trying to write for. And they had their background and their knowledge, and I tried not to assume anything else. Did you have a particular person

you were writing for? Or how did you figure out what your reader was going to know and what they weren't going to know? I think it was based on real experience. So I think everything in that book is, it really came from what are the things that I end up explaining to most people most of the time. So or software developers how to do software development other than there are a few issues in both of those disciplines and in other things I cover where, you know, software developers, they know how to develop software, but they may not, you know, understand much about how to think about different operating systems, for example, because typically they're given an operating system to use, and they may complain about it. So let's say you're using an RTOS, like Green Hills or something, and they say, oh, this is a terrible, why are we using this?

This is just so freaking hard to use. It doesn't do anything for me. Well, there's reasons for that, and I'm trying to put this in context. Yes, you could use something that's more full-featured, but it's not going to be an RTOS, and it's not going to be as tested, and safety is not going to be as assured, and all those kinds of things. Just to give people an idea of why they're doing what they're doing. I guess that could be applied to the book in general. It's trying to help different people who are involved in product development, trying to help them understand what's going on holistically and how do they fit in and how can they work with other people so everybody has a good time and get a good product out the door. I liked the systems aspect of it, talking about how boards are actually manufactured and how you do all these things, including choose an operating system and processors.

And yet you don't give enough information that someone could make that their career, but you give enough information that a systems engineer or a manager or a CEO of a tiny company would know the right questions to ask and wouldn't make assumptions that just because somebody else used Linux that it is appropriate in their product. And I liked that about it. Yeah, Linux. Let's just run Linux. And yet the boards are, everything's getting cheaper, so why bother to not run Linux as long as you don't mind crashing occasionally?

Right. Or backporting fixes and all those types of things. Security. Yeah. Well, security and, you know, reliability. And it's, you know, I wouldn't say anything bad about Linux or any other operating – well, that's not true. There are probably some operating systems I could say bad things about. But they are what they are, right?

And it's really just understanding what's out there and what are the pluses and minuses and picking the best set of compromises for what you need to do. So would you write another book? Are you currently writing another book? sort of more along the lines of systems engineering, more detailed systems engineering book or software. So I've become very interested in model-based systems engineering and software engineering, which I think is a very important topic, and it's a very powerful way to do things, but I don't think it's often used outside of a few industries.

So I'm kind of thinking about maybe doing something along those lines but you know it's a lot of work so yeah and i'm lazy so i i don't know we'll see uh you sent me a slide that included model based and i want to hear more about it so let me describe this slide a little bit. It was about defects and software methodologies. And it talked about different software methods, waterfall, iterative, object-oriented, agile, stuff I don't know, stuff I don't know, model-based. And then it talks about what the defect potential was with a number I didn't understand and the number of defects you can expect to be delivered. And waterfall was by far the worst and model-based was pretty good. Agile was between them. Can't we just type? But yeah, okay. So what is model-based mean?

Well, the idea is that, so let's say, let's move away from software for a second. Let's talk about, let's say you're building a mechanical, let's say you're going to, you know, build some sort of a mold or something, right? You have a plastic part you want to build. You're not going to, you know, if you were going to 3D print it, right? Ultimately, you're going to end up with G-code instructions that go to the 3D printer. I think it's called G-code. But you're not going to sit there and write G-code that tells the printheads how to move and all that kind of stuff. You're going to draw some stuff on a screen that describes the part that you want, and then it's going to get turned into an STL model and then turned into G- code and whatnot. So sort of the way that model-based engineering is similar

is that you're, so in the case of software, right, ultimately you're going to end up with code, right? C code or, you know, C++ code or Python or whatever it is. But maybe there's a way to sort of at a high level draw diagrams that show what the system should do and then have it turn that into code. So I guess, well, why would you do that? If you do things as diagrams, it makes it a lot easier for people to analyze what's going on.

And, you know, let's say if you've got a piece of code, let's say a state machine, for example. I don't know about you guys. You guys do the kind of work where I suspect you've been exposed to state machines and have probably dealt with them to some degree, or maybe to a larger degree. But those are...

I've never found a great way to do state machines in code where everything's clear and easy and people can do a good review of them. That kind of a thing. They're always just sort of clunky and nasty. But if you were to draw a state machine as a diagram, you can do a great job of that. That everybody can understand and all the stakeholders can look at it and say, yeah, that makes sense. These states make sense and these are the right transitions. Or, oh, we forgot about this event occurring that will cause such and such transition

in this other error state and things like that. So by doing these things as diagrams, we can, I think, understand them a lot better at a high level and then reduce things to code. So it basically lets you fail faster. You could put together diagrams rather than writing a ton of code and work with the diagrams, in some cases, execute the diagram. So the tool that I use for model-based software engineering is something called Enterprise

Architect, which is actually not a very expensive product. It's a very good product. And it will actually generate code in a lot of instances from the diagrams that you draw. So, for example, state machines. You could draw a reasonably simple state machine, and it will kick out a thousand lines of code that's documented and good code and sturdy and all that kind of stuff. So it's quite nice.

I'm having my normal new things are bad engineering reaction. Because I mean, I remember UML and I remember UML to C generators, or C++, I guess. And I'm remembering every time I tried to learn LabVIEW and then ran away screaming. I'm not sold on the diagrams. Can you sell me a bit more? Yeah, so I share, well, LabVIEW I think is great. This is kind of an aside but um i i labview is great for certain types of things i think it's great for test engineering um but for writing

doing products it's not great um and hopefully that doesn't uh bias you too much against uh model-based software engineering um uml um yeah that was kind of a big thing in the turn of the century, shall we say. And then I think people didn't see a lot of benefit for what they were doing. And also UML is very picky. To do it in a way where you can generate code from that is pretty challenging. And actually, the tool that I'm using, and actually the typical tools for doing model-based engineering use, do use UML and an extension of that called SysML for system engineering. And it is, I would say two things. One is that the learning curve is actually very steep for getting to the point where uh you can you can use this to to do

something useful uh and also um you've got to uh well there there are certain things that it's good for and there's certain things that it's not good for so i my suspicion i'm not an expert on this by any means i'm actually being tutored on this by somebody who's an expert at it. There are certain things that are good, I think, that work well in terms of modeling and then generating code. So, for example, doing classes, like if you're going to do classes and state machines, things like that, there's a lot of boilerplate code that it's easy to mess up if you're doing it by hand. But if you're drawing a nice diagram and then pressing a button, it'll generate nice code that if you did it by hand, you'd probably screw up. But if you're trying to do detailed algorithms and things like that, no, I don't think you're going to do that with a model. I don't think that's going to work too well. So that was a lot of talking,

and I'm not sure what I said, other than I think there's some very, very good uses for it, and there's definitely ways to abuse it. And it does require a steep learning curve, which is actually what makes it attractive to me as something to write about, which is that I think a lot of the steep warning curve has to do with there not being books available that teach the user in a good way how to use these technologies. One of the good things that comes from technologies like that, and I don't know about Enterprise Architect itself, I've never seen it. But the idea of this model-based system is like you said about state machines. You put one together and it's an understood state and the code generates it, or understood pattern. It's an understood pattern. And then the code

is generated according to fairly standard methods. And then there are other patterns. Many of these newer UML to C++ systems like Java and Swift are very pattern-based. Like you want to do this and so you use a subscriber publisher pattern. You want to do that, so you use this. And so we end up with bolt, don't redesign it. Just use the bolt, give it the size you need and the thread count you need, and go. You just stop redesigning the bolts. Oh, absolutely. Yeah, that's, you know, one of the things I tell engineers who I work with or who work for me, I'll tell them, your job is to finish a product, not to design stuff, which is a little disappointing in some ways. But there's still plenty of room for creativity. But the bottom line is that the job is to get it done as quickly and efficiently as possible.

And if that means just getting something off the shelf or using something that's already been designed, that's all the better. Has writing a book changed the trajectory of your career? I'd like to say the heavens opened up and, you know, all kinds of great things happened. But I would say not really. No, I mean, I'm actually pretty happy where I am in my career. But, you know, I mean, it's nice, nice you know people recognize it and uh it is kind of a shorthand i can give that to people and they will kind of quickly know that i kind of know a little bit of what i'm talking about that kind of thing and i'm i am able to use it to um on

projects where i can you know ask people you know people start talking about some topic i'll say hey you should read pages you're usually talking about three or four or five pages, because I tend to be pretty concise in the book about that topic. And, you know, that might be of interest to you. But no, I don't think it's changed my career trajectory in any sort of a huge way. Have you ever taken it to an interview with potential clients and pulled it out at the right time? I haven't had that opportunity. So, I mean, I've been, since I wrote it, I've been fortunate. Of course, neither have I. Yeah.

You know, I, at some point, you know, maybe that'll happen. But no, I've been, I mean, it hasn't been out for two, you out for three years, I think, which isn't that long in book years. And I've been just sort of working on some fun stuff, and people have asked me to work on things. So I haven't had to really do that, going around looking for work kind of thing. So it's not yet, but I'm sure it'll help a lot if and when that happens. I just wanted to briefly ask about Mass General Hospital, because when I worked at a medical place, we had a relationship with them, and I was surprised at the time that, oh, this hospital does all this research and stuff. And I think people would be interested to just hear about what's

done there. It's kind of a cool a cool organization yeah mass general is an amazing amazing place i feel really really fortunate to work there um it is so it's one of harvard's teaching hospitals um and it's the largest of their teaching hospitals uh it's also the uh they have the largest research budget of any hospital in the United States. They – I'm trying to remember what it is. It's a billion dollars plus or minus a year that they spend on research. Wow. Yeah, it's huge.

They do a tremendous amount of research. They also do excellent patient care. And those two things don't – very often don't go together. But in the case of Mass General and the Brigham and Women's here and some other hospitals, they do go together. And they are sort of just, you know, I can't say enough good things about it. There are so many smart people there. I mean, it's, you know, it's Harvard Medical School, right? So these are the people I work with, the physicists, which are all very, very – all physicists are just very smart people. And these are sort of cream of the crop or among that top high-end group. There is great research going on.

I mean, in the area I'm in, radiation oncology, there's a lot of people doing great research on you know better ways to do different kinds of therapy the system that i work on now the proton therapy system uh that was proton therapy for clinical use was really pioneered at um uh mass general slash harvard um you know probably about 40 years ago they started doing it They were the first people to do it clinically on a large scale. So, yeah, any area of medicine, they're doing something really great. And it's fun to work there, and people are really nice, too. So it's great. Awesome.

Cool. Thank you. Evan, we'll let you get back to your weekend. Al, do you have any thoughts you'd like to leave us with? So, you know, one of the leave us with? So, you know, one of the things in writing a book, you know, the book I wrote sort of talked a lot about,

I'll say, tactics and strategies and, you know, how to do stuff. But one of the things that I didn't really touch on, which I think is super duper important, is the people aspect of all this. That I think one of the things that you realize as a systems engineer, because you're working across so many different groups of people,

is how important people and people's brains and their psychology are to a project. And it's something that you guys were sort of touched on earlier about how do you get people to think about things in certain ways that make for good outcomes. The flip side of that is teams of people. One of the things that's really, really super important when you're building a product is having a good team of people. And there's really nothing more important, I think, than having a good team of people who are smart, motivated. Egos aren't too big. Self-confidence is good, but egos aren't so great. Forgetting things done of any sort. So I would say that I hope people read the book and take

it to heart. But also, be very thoughtful of the people you're working with and making sure that they're motivated and you know, that, that everybody's happy. And then they'll do a great job. Cool. That is, that is very good advice. Our guest has been Alan Cohen, author of Prototype to Product Practical Guide for Getting to Market. It's published by O'Reilly and available at all the usual bookstores. Thank you for being with us.

Oh, thank you guys. It's been a pleasure. Thank you to Christopher for producing and co-hosting. And of course, thank you for listening. You can always contact us at show at embedded.fm or hit the contact link on the website embedded.fm, which has a blog if you didn't know. And now a quote to leave you with. This was kind of odd because I read Camille Fournier's The Manager's Path right before I started Al's book. And the two of them together,

I've never highlighted so much in my life. And what Al was saying about teams, Camille has some things to say too. Do remember to be kind. It's natural and perfectly human to want to be liked by other people. Many of us believe that the way to be liked, to be seen as nice, that niceness itself is the goal.

Your goal as a manager, however, should not be nice. It should be to be kind. Embedded is an independently produced radio show that focuses on the many aspects of engineering. It is a production of Logical Elegance, an embedded software consulting company in California. If there are advertisements in the show, we did not put them there and do not receive money from them. At this time, our sponsors are Logical Elegance and listeners like you.