Verification and Validation
You Might Also Like...
Episode Show Notes
Guest engineer and consultant Pat Sweet, P.Eng., talks about two of his favorite words in engineering: verification and validation. They describe concepts whose importance cuts across all the engineering disciplines, and so engineering educators could also teach these fundamental concepts to kids and teens. This episode is a rebroadcast of two short episodes of Engineering Word Of The Day, a podcast on the favorite, fascinating, or funny words and phrases used in various engineering disciplines.
Our closing music is from "Late for School" by Bleeptor, used under a Creative Commons Attribution License.
Listen to the Engineering Word Of The Day podcast. Also check out the book and ebook Engineer’s Guide to Improv and Art Games by Pius Wong, on Amazon, Kindle, Apple iBooks, Barnes & Noble Nook, and other retailers.
Subscribe and leave episode reviews wherever you get your podcasts. Support Pios Labs with regular donations on Patreon or by buying a copy of the reference book Engineer's Guide to Improv and Art Games by Pius Wong. Thanks to our donors and listeners for making the show possible. The K12 Engineering Education Podcast is a production of Pios Labs.
Pius Wong 0:00
It's August 21st, 2017, and this is The K12 Engineering Education Podcast. This episode, we celebrate two really important words in engineering, "verification" and "validation". Engineers across every discipline should know about these fundamental concepts. Know the difference? Listen up, next.
Pius Wong 0:30
I'm Pius Wong. Recently on another podcast of mine called Engineering Word Of The Day, the very knowledgeable engineer and consultant Pat Sweet joined me to talk about two of his favorite words in engineering. It was a great set of conversations. So before those episodes get archived away from that podcast and disappear off the internet, I wanted to share them on this show, because the conversations probably concern engineering educators just as much as working engineers. So let's get into Part 1.
Pius Wong 1:06
Pat Sweet 1:06
Pius Wong 1:07
How are you doing?
Pat Sweet 1:08
I'm just fantastic. How are you, Pius?
Pius Wong 1:10
I'm all right. I am sitting here in Texas, trying to get some podcast episodes ready. And you are in Canada, right?
Pat Sweet 1:17
Yeah, Halifax, Nova Scotia. So the far east coast of Canada.
Pius Wong 1:21
Awesome. And you are actually the first guest that I'm having on my Engineering Word Of The Day podcast. So this is a little bit of an experiment. Thank you for doing that, for joining me.
Pat Sweet 1:31
Thank you for having me. This will be exciting, a lot of fun.
Pius Wong 1:34
Yeah. And I know just a little bit about you. But maybe people listening don't know who you are. Could you explain your background?
Pat Sweet 1:42
Yeah, absolutely. So again, my name is Pat Sweet. I'm a professional engineer. I've been practicing engineering in Canada for over a decade now. And I run a blog and a podcast called Engineering and Leadership. So you can find that at engineeringandleadership.com, or the podcast is on iTunes, if you just search Engineering Leadership. What I'm interested in, and what I do is, I help engineers and engineering companies thrive through a better understanding of the business and professional side of our profession. So I kind of recognize the fact that a lot of my own success in my career came as a result of understanding the soft skills and the business side. So eventually I went out and got an MBA and moved into product management, which is a really cool field that kind of merges both business and engineering. And I absolutely love that. So it's that kind of nexus where I operate now. So I do consulting as my as my main occupation now, and I do speaking and training and that kind of thing. So anyway, given that I love being on podcasts, I think it's a phenomenal way to meet people and to reach out to new people. So I'm super excited that you've invited me here today.
Pius Wong 3:04
No, that's excellent. So we heard that you are a PE, a professional engineer. You also are a businessman. You got an MBA. It sounds like you're very well qualified to know all about engineering jargon and terminology. Before we get into your favorite engineering words, because you do know a lot about, I guess, climbing up in the professional careers of engineers, why are communication skills and language and these soft skills -- Why are they even important for engineers to grasp?
Pat Sweet 3:34
It's interesting to say that. Just before we hit the record button, I was telling you about a seminar I gave in Mississippi a few weeks ago, and I dedicated about a quarter of my time to communication skills. In my own professional experience, what I've noticed is that there are plenty of engineers who have brilliant ideas. I like to think that engineers are pretty bright bunch. The trouble is, if you can't effectively communicate those ideas to anyone else and really convince them of the value of those ideas, you might as well have not had the idea in the first place. So if you can't use communication as a tool to get done what you're trying to get done, be that a new design and new idea, and organizational transformation, you know, a change to your project -- It really doesn't matter what it is. If you can't get across to others the value of your ideas, then you're dead in the water. So understanding the right way to communicate, the right people to communicate to, is absolutely critical.
Pius Wong 4:42
All right. So I guess people can go look up Engineering and Leadership and consult with you to try to find out how to better communicate as an engineer.
Pat Sweet 4:51
I like to think so. Yeah.
Pius Wong 4:54
All right. Well, I also wanted to ask you about some of your favorite engineering terms. I was wondering if we could talk about one of them, in particular: Validation. Validation. Is that correct? Is that one of your most interesting engineering words?
Pat Sweet 5:11
Yeah, it sounds like a boring word. But it's a super important word. So validation with respect to a design means that you're actually designing the right thing. A valid design actually fits the the need that your client has, and the client doesn't have to be someone external to your company. It could be someone else you're doing work for internally. The reason validation is important is that your client doesn't always know what they want. They have a sense for the fact that they have a need, there's a problem a pain or a fear that they have that they want addressed. And often clients will come to you with an idea of what they want but might be thinking too narrowly, in terms of what the actual solution is. So let me give you an example. I used to work in the rail industry. And often, what would happen is we would have clients who would come to us and say, I want this kind of train, I want it to weigh this much, I want it to go this fast, I want it to be this color, when in reality, what they wanted was some kind of a system that would move 20,000 people per direction per hour. So the real need was to move the people. What they were asking for was a specific kind of train, when in reality, there are any number of different kinds of systems or designs that really could be valid.
Pius Wong 6:40
Pat Sweet 6:40
As opposed to just that one that was specified.
Pius Wong 6:44
That sounds like the engineer's job, especially in that beginning phase, is to really understand not only what the client or the customer is saying, but maybe what they're not saying and just understanding their overall problem.
Pat Sweet 6:59
For sure, for sure. And it's not even just understanding the client's problem. It's helping the client understand their own problem. And if you're not able to do that, then it's very difficult to get to a valid design. And no matter how many brilliant ideas you have, no matter how much time or effort you put into a design, if it's not valid, the project will fail. The design will fail, as technologically advanced and fancy as it may be. So validation of a design is an absolutely critical first step, no matter what it is you're designing.
Pius Wong 7:32
All right. And real briefly, how can engineers validate a design? How can they help -- or how can they figure out if a design or design idea will actually solve the customers problem?
Pat Sweet 7:48
One of the most basic ways and probably the most important way is to keep the client in the loop. Don't wait until you've completed a design. Don't wait until it's, you know, ready to be manufactured before you let the client in on what you've done. There are quite a few books out there about lean design and scrum project management that are, to me really, really fascinating. But what it all boils down to is: Show the client early and often what you're working on so that when you do need to make adjustments, because you will. You can't read the client's mind. If you have something to show them, and they can give you feedback early, you can adjust course along the way, so that you're not starting from square one after putting all sorts of time and effort into it. So incremental validation is is the way to go.
Pius Wong 8:39
So Pat, that's really interesting. I guess I learned that validation is kind of an ongoing process within the design cycle. And I hope that everyone listening, especially the engineers listening, really take that to heart.
Pat Sweet 8:51
Yeah, absolutely. I think you've got it.
Pius Wong 8:53
All right. Thank you. I've just spoken to Pat Sweet, engineer and consultant. You can find him at engineeringandleadership.com.
Pat Sweet 9:02
Thank you so much. Thank you very much, Pius.
Pius Wong 9:08
And now here's Part 2 of the conversation we had, which is an important follow-up to the engineering terminology of "validation".
Pat Sweet 9:20
Alright, welcome. I'm talking with engineer Pat Sweet, professional engineer, in fact, PE. Welcome, Pat.
Pat Sweet 9:27
Thank you very much. Pius. It's nice to be back.
Pius Wong 9:29
And this is Part 2. You were previously on this Engineering Word Of The Day podcast to talk about another word: "validation". And we're going to talk about a very related word pretty soon. But just real briefly, just as a recap, can you explain to everyone listening who you are and what you do?
Pat Sweet 9:47
Yeah, absolutely. So my name is Pat Sweet. I run a blog and a podcast called Engineering and Leadership, which you can find at engineeringandleadership.com or on iTunes. And what my work is all about is helping engineers and engineering teams do better work to help engineers and teams thrive through an understanding of the business side and the management side, the soft skills of engineering, the whole idea being that through my own career, I recognize that the people who really advanced in the teams, who really did fantastic work, were teams that were well-rounded in that regard. So that's what I'm all about. So I do speaking. I do consulting. And yeah, that's the nature of the work.
Pius Wong 10:38
And you have plenty of experience. You're up in Canada, but you travel all around, it sounds like, to help engineers and businesses do better work. And you're drawing on, I guess, your background in both business school and also your engineering background as a PE. I just wanted to ask you briefly, before we get into our engineering jargon here, I'm going to ask you about another piece of engineering jargon, the PE, the professional engineering designation. Can you explain what that is? In case someone doesn't know?
Pat Sweet 11:10
Yeah, no, fair enough. In Canada, we have to differentiate ourselves, we decided to call it PEng. But it's --
Pius Wong 11:17
Oh, I did not know that.
Pat Sweet 11:18
Yeah, it's -- But fundamentally, it's the same thing. Where I studied in -- where I practice in Canada, your professional engineering designation is an absolute requirement with respect to be able to certify drawings, for example, and really practice as an engineer. So in Canada, it would be very rare, I would say, for a practicing engineer, not to be a PEng. And I believe it's similar to the requirements in the States. We have a law and ethics exam, there's experience requirements, education requirements. And in many cases, provinces, but not all yet, which is a little bit funny -- You also have continuing education requirements. So where I had been practicing in Ontario, there is currently no continuing education requirement. But I think it's probably the last province for that to be the case. I think there's a move afoot to change that right now.
Pius Wong 12:19
So that actually does sound very similar to the US case for the PE certification, where, like you said, there's continuing education, at least in most places, and you definitely had to get some education and take some tests, and you have to work under other professional engineers before you can get your own certifications.
Pat Sweet 12:39
Pius Wong 12:40
So I think the point is, you know what you're talking about.
Pat Sweet 12:45
[laughs] Thank you very much.
Pius Wong 12:47
Alright, so this podcast is all about important engineering terms or terms that engineers should know, and maybe people outside engineering should know. And the term that I want to bring today is very much related to the term we spoke about last time. Last time, we brought up validation as our engineering word of the day. And today, I wanted to talk about verification.
Pat Sweet 13:12
Pius Wong 13:12
Which I understand is one of your favorite engineering words.
Pat Sweet 13:17
Yeah, absolutely. So validation and verification together is is one of my favorite kind of concepts.
Pius Wong 13:25
Yeah. Tell me about that.
Pat Sweet 13:26
So well, the last time we spoke, we talked about validation being building the right thing. Verification is about building that thing right. So where validation is designing something or doing something that actually satisfies the customer's need, that all happens on paper, right? You can explain to a client, what you want to do for design, and they can tell you, Okay, that sounds great, that'll that'll fit the need. Verification is what happens once you've actually built whatever it is you're doing, be that process, product, you name it. Verification is the act of testing or analyzing that product, to make sure that whatever it is you design actually performs as you expected. So let's say, for example, a client wants a car and you design a car. That's a valid design. But when you go to verify it, if that car doesn't go two hundred kilometers an hour, and that was the requirement that the client gave you, then you have not produced a design that actually does the job. It may have been valid, but failed verification. So both of the V words are critical with respect to successful design.
Pius Wong 14:43
You can't do just one or the other. An engineer has to do both.
Pat Sweet 14:47
Absolutely. Yeah. Because if you don't validate, you don't know that you built the right thing in the first place. And if you don't verify, you don't know that it really does what you said it would on paper.
Pius Wong 14:57
That's a subtle difference. And I'm sure there's some people who, if they've never thought about those differences here, they're sitting there thinking about that.
Pat Sweet 15:05
Pius Wong 15:07
How can someone learn more about these differences? Or think about these differences? Are there any like, ways to teach themselves the subtleties of this?
Pat Sweet 15:19
Probably the best way to think about it is that, in validation, it's the client who can validate, right? It's only the client who can tell you what you've done is right. But when you verify, that's something you check, you as the engineer. And there are a couple different ways to verify your design. You can test it. You can do analysis. So for example, structural engineers do finite element analysis. So instead of physically crushing their design, they can use a computer to figure out whether or not the stress and strain matches up with what they expected. You can verify something through design, which is kind of a silly thing. The idea there is if the client asks for something blue, you designed it to be blue, and you can see that it's blue, right?
Pius Wong 16:07
Pat Sweet 16:07
But the point there is that you do have to actually check at the end of the day that you've met all those requirements, even the things that aren't really hard to verify, you still have to verify. It's amazing how many simple things can get missed, especially in a complex design.
Pius Wong 16:24
Sure. And so in the last conversation, the last episode, you had said that validation is kind of an ongoing process. You involve the clients from the very beginning. And you kind of keep on contacting the client and referring to the client to make sure that your design is being validated. Do you think that verification is something that engineers kind of do throughout the design cycle as well?
Pat Sweet 16:49
To some extent, yeah. I'm looking back through your old podcasts. I noticed one of the words of the day was "iterate". Is that right?
Pius Wong 16:56
Yeah, that was my first one.
Pat Sweet 17:00
So iteration occurs when you test over and over and over again, right? You can do iterative verification, because often, a design doesn't work the way you think it will the first time. You go back to the drawing board. You try the design again.
Pius Wong 17:15
I'm very familiar.
Pat Sweet 17:15
Yeah, absolutely. Absolutely. And everyone who's practiced for any length of time can know that. But then you can also verify recursively. So recursion happens when you're doing the same process at different levels of the design. For example, you can verify a subsystem and say, Okay, yeah, that's subsystem, all the tests pass, all the analysis looks good. Then that subsystem gets plugged into its parent system. So for example, I mentioned before that I worked in the rail industry. Maybe you test a propulsion system, you verify, and it does what it's meant to do. Well, how does that system now work once it's plugged into a full train? How does it interact with the train controls? How does it coordinate with the braking system? You have to verify the propulsion system at that level as well, once it's plugged into everything, and it's part of the bigger picture. So verification, like validation, happens more than once. It's not a point a time. It can happen iteratively and recursively.
Pius Wong 18:22
And it sounds like there's this hierarchy of it, like simpler tests, and then more complicated tests. And we were bringing up even more engineering terms like "subsystem", and you probably have to test at different levels of that system and subsystem.
Pat Sweet 18:37
Yeah. And it's a -- you know, it's a function of how complicated your design is. And whether or not it makes sense to look at it through a systems engineering lens versus, you know, a simple or off-the-shelf design.
Pius Wong 18:51
Right, right. Okay, well, I think that you've definitely helped clarify some differences between verification and validation, both very important steps when designing something. Any last words for the listeners about anything? About who you are and what you do?
Pat Sweet 19:09
Well, probably most importantly, if you want to learn more about what I do, I've got a I've got a ton of free material on my website on engineeringandleadership.com. And I do have a free 12-week Engineering Leadership course that you can sign up for. Just take a look on -- Once you go on the website, just take a look at the right-hand sidebar, and you just plop your email in and sign up for that, and I'll send you emails for the next couple weeks.
Pius Wong 19:35
All right. So Pat, thank you so much. This is Pat sweet, professional engineer, and you should check out his website and podcast engineeringandleadership.com. Thank you.
Pat Sweet 19:47
Thank you very much, Pius. It was a blast.
Pius Wong 19:54
Thanks for listening. If you're interested in my other strange musings on engineering acronyms, slang, hard-to-pronounce words and the like, check out episodes of the podcast Engineering Word Of The Day. You can find it at engineeringwordoftheday.com or find it on any podcast player. For all the information on the podcast that you're listening to right now, just go to the show website k12engineering.net. Please rate and review the show, especially if you're listening on iTunes or on Stitcher, and share The K12 Engineering Education Podcast with your colleagues and your friends. Maybe now that school is starting up you might find that this show and certain episodes are more relevant, especially the one on teachers' dreams and nightmares. Who knows? Message the show on Twitter @K12Engineering or tweet me directly @PiusWong. Follow us on Facebook. And finally you can financially help out this show and me and other projects of Pios Labs by donating on Patreon. The website for them is www.patreon.com/pioslabs. Our closing music is from "Late for School" by Bleeptor under a Creative Commons Attribution License. The K12 Engineering Education Podcast is a production of Pios Labs.
Pius Wong 21:18
So the voting window is almost up for the South by Southwest Edu proposals. And I just want to say thank you to everyone who has voted for our session. We saw a lot of likes and a lot of tweets and a lot of Facebook shares for our session, Podcasting for Education Meetup. And so Rachel and I and Sadhan, because he's helping out a bit too, we're all really grateful for your support, and we hope that we make it. If we do, we'll definitely let you know. You'll hear about it at the end of every episode, I'm sure. And you should totally make it out to Austin, Texas. Join us and engage us in some conversation. Thank you.