Short Answers
Suhaib3RA
ForumUnitIAnartforsolvingproblems.docx1. Ethics is integral to Engineering
Top of Form
1.1 Introduction
This quad may be the most important quad of all. It presents the over-arching theme of the course, what I'm calling the master narrative.
A narrative is a story, and this is the story around which the course is based. Everything we do --- the other quads, the assignments, the questions --- are related to this story, and provide some detail to this story.
The master narrative is a story about engineering and ethics: about how ethics is integral to engineering.
Let's look a little more closely at that claim:
ethics is integral to engineering.
This claim involves two key concepts --- ethics, engineering --- and it makes the assertion that the things described by those concepts have a particular relationship. Namely, one is ``integral to" the other.
An explanation of that claim then, will say something about what ethics is, what engineering is, and what it means to say that the one is integral to the other.
In the next three sections of this quad, that's what we're going to do. I will give explanations of the two concepts, and how they are related. All of the quads will have that structure. The first one will introduce a claim to be explained, and the rest of the entries in the quad will give the explanation. In the rest of the course will be looking at that explanation in more detail, in other ways.
Notice that this is a good example (in fact, an actual example) of what I'll be asking for in the short answer questions. As a short answer question it would look like the this:
Explain: ethics is integral to engineering.
Your task is to understand the explanation given in the quad and boil it down to a 3-sentence answer, as described in the Short Answer Question guide. A strategy is to use one sentence to say something about ethics (one concept), and the second sentence to say something about engineering. Do that in a way which makes plain what it means to say, and how it is the case that, the one is integral to the other. (Again, you'll do this in the 3-sentence format described in the guide.)
So, just to recap.
The master narrative of the course is that ethics is integral to engineering, not just something you do after the engineering is done, or something someone else can do.
If you're doing engineering, you're doing ethics, whether you know it or not. And you're a better engineer if you are aware that you're doing it, and if you can do it well.
Bottom of Form
1.2. Engineering is an art for solving problems
The first step in explaining how ethics is integral to engineering is to ask, you can probably guess, what is engineering?
Maybe you've never asked yourself this question before. Even though you're an engineering major it might never have come up, or occurred to you to reflect on what engineering actually is. Usually you're too busy just trying to get the homework done, or pass an exam.
At the University of British Columbia, where I studied electrical engineering, the engineering faculty wasn't called the faculty of engineering, it was called "applied science". Not everyone in the faculty was happy with that. Some thought it made engineering sound like it was secondary to science.
But there is something important in thinking about engineering as applied science. Engineering does, in fact, involve applying science --- but applying how, and to what?
The definition we'll use is that engineering is an art for solving problems. Engineering uses science, technology, labour for solving problems. In that sense engineering is applied science. It's the application of expertise, to be more general.
We'll have more to say about problems and problem-solving coming up, but for now we can say that it's not so simple as just taking your expertise and applying it to a problem.
The problems which require an engineering solution are real world problems. Not laboratory problems, not theoretical problems. This is also what applied means: engineering solutions occur in real world applications.
Another way in which engineering problems are different is signalled by labelling engineering an art.
We can think of engineering as an art in three ways:
1. Engineering is creative. There is no engineering crank you can just turn, or an algorithm you follow. Solutions to engineering problems are not obvious, are not right in front of you.
2. Engineering is subjective. Differetn engineers will arrive at different solutions to the same problems. They will make different, personal choices. Every engineer has their own preferences, their own values.
3. Lastly, engineering is meaningful. It literally changes the world we live in --- the world we interact with, what it's possible for us to do, and how we do it.
The world we live in has been created by engineers. It reflects choices by engineers about what the world ought to be like, from the shape of the chair your sitting in, to the interface of your smart phone, the mileage of your car, the height of your ceiling, the traffic patterns you drive in, and on and on and on.
Engineering involves creative expertise and value judgments, just like art, and it informs the world, it changes the meaning of our lives.
Just like art, good engineering --- thoughtful, reflective, aware engineering --- can be taught, and it can be learned.
1.3. Ethics is expertise in normative decision making
We're trying to understand what engineering ethics is. In the 2nd part of this quad we defined engineering as an art for solving problems. In this part we're going to ask:
what is ethics?
Generally speaking, ethics is the study of the good. It attempts to answer questions of what is right, what is wrong; how should we live, and what is the good life? It considers, in various situations, or simply generally speaking, what we ought to do, or what ought we not to do.
So, studying ethics gives us expertise in the good or the right, and how to act in accordance with the good or the right. Ethics is expertise in a particular kind of decision making.
To understand that better it's useful to make a distinction between descriptive and normative claims.
Descriptive claims state what is the case. they are `is' claims
Claims about what the strength of a material is, for example, or the weight, or how a piece of equipment will behave in certain conditions, are descriptive claims. Descriptive claims are technical claims
But we can also make claims about what ought to be the case, what's right, or wrong, or best.
a part might have a certain strength --- that's a descriptive feature --- but whether that's the right strength or not, whether that's the strength it ought to have is a further question.
ought claims are normative claims. normative claims go beyond what is the case.
thinking about those questions, the normative questions, is a different kind of expertise from the technical expertise you're gaining in all of your other engineering classes.
There are many different kinds of ethics, many theories of ethics, and they can be grouped as kinds of theories. we'll look at few specific ones later in the course
but for now, we can say that we'll focus on a branch of ethics that is called normative ethics.
Normative ethics is ethics about actions. about what we ought to do, choices we ought to make.
having expertise in this area means we'll be better able to make good choices, but also better able to justify our choices: explain why we thought they were best.
1.4. Engineering problem-solving requires normative decision making
In part 2 of this quad we said that engineering was an art, that it required creativity and subjective choices. And we said that engineering problems are real world problems.
The thing about real world problems is that they do not have perfect solutions. An engineering problem will have many solutions, and all of them have flaws as well as strengths. Any solution is a kind of compromise. Choosing a solution is choosing a compromise: what to give up, what the right balance is.
For example, there are trade-offs like time vs budget, performance vs risk. There are facts about the budget, risk, length of a project these are descriptive claims, but whether those facts are acceptable, whether they represent the best combination of factors, requires a normative assessment. Which is to say, choosing a solution to an engineering problem is making a value judgment.
What you're making a judgment about are values. how much do you, or does your client, or the public care about a quick solution, as opposed to a cost effective one? How much time or money are they willing to put in in order to minimize the risk? How much risk is acceptable?
These are all questions about values, how much value is placed in different features, like safety or price, or aesthetics, or reliability. Deciding on a solution is deciding on one among a set of value judgements. When you solve an engineering problem you are making a normative decision. To repeat: choosing a solution to an engineering problem is making a normative choice; solving an engineering problem requires a normative choice.
So, since normative decision making is such a crucial part of engineering you have an obligation as an engineer to reflect on that part of your job; to understand your normative decisions and be able to justify them, just like you would any other choice as an engineer.
When we talk about ethics in the context of engineering ethics, what we mean is the expertise required to think through the normative choices you make as an engineer solving problems. This kind of ethics is therefore integral to engineering. You cannot do engineering without doing ethics. You have a responsibility to try to do it well.
2.1. Introduction
This quad addresses the question: what is problem solving? The answer it presents is: problem solving is making a question precise.
This is an important question since we've defined engineering as an art for solving problems, and we're unpacking that claim, along with my argument that normative decision making is integral to engineering. The argument in brief will be: engineering is problem solving of a particular type, and normative decision making is integral to solving problems of that type. Therefore, normative decision making is integral to engineering. To fill in the details of that story, an obvious question to ask is: what is problem-solving?
In this quad I'll first talk about what a problem is. I'll define a problem as a how question, and present a schematic of a problem. (You should also read about problems and problem solving in the course handbook.)
In that schematic we'll see that the problem already contains its solution, though the solution in its first firm is almost never precise enough. The solution isn't precise enough in that it doesn't give a reliable description of the steps it would take to actually make the solution happen.
Since the solution is in the question though, when we make the solution precise we are making the question precise, and vice versa.
Intuitively the idea is that solving a problem is mostly just figuring out exactly what the problem is; what needs to be done. What is the how question?
It's worth pointing out again the value of philosophy to engineering. Engineering is about problem-solving, problem-solving is about asking precise questions, and philosophy is the skill of asking clear and precise questions.
2.2 A problem is a how-question
We can't understand what problem-solving is, or what it means for a problem to be solved unless we have a clearer understanding of what a problem actually is.
So, take a moment to think about this question: what is a problem? Think about what makes something a problem, and also about what kind of thing that something is. Jot down a few ideas you associate with the concept problem.
You may have said things like: a problem is something undesirable, something you want to change. Or, a problem is maybe a flaw, a limitation, something to overcome.
It's clear that when we think of a problem we tend to think of it as something negative, something undesirable, which is why a problem is something which needs to be solved.
But this is pretty vague, especially the "something" part. What kind of thing is a problem? Is it a thing in the world? Is it a property of something in the world? Some way the world is?
If it is a fact about the world, what makes it negative? Facts aren't negative or positive, they just are. This is our descriptive / normative distinction again. [Problems are normative. States of affairs are descriptive.]
As an example, let's say you're asked to increase the efficiency of a particular process. The current efficiency is a descriptive fact. It's neither positive or negative on its own. It just is.
What makes the efficiency problematic is that it's not what we want (or what the client wants, or the senior engineer, or it doesn't meet some code or regulation.)
But it's not the state of affairs itself. It's that the state of affairs doesn't measure up in some way.
If you think about it, what the problem really is --- what it is that you have to solve --- is HOW to CHANGE the efficiency from what it is now, to some other, higher value.
When you've figure out how to do that, how to bring about that change, you will have solved the problem.
What this suggests is that the problem is actually that how question.
This is the definition we'll adopt. A problem is a how question: how to bring about a change in the world; how to change the current state of affairs to one which is better, preferred, more valued.
To go with this definition, we can represent a problem as a schematic.
[How: X --> X'?]
The X --> X' we call the transformation clause. That's the transformation you want to bring about. X is the current state of affairs; X' would be the improved state of affairs.
So, to return to our example, X could be the process and it's current efficiency. X' would be the new process with its improved efficiency.
Solving the problem then amounts to figuring out how to bring about that transformation.
2.3 A problem contains its solution
Have another look at the problem schematic
[How: X --> X' ?]
The problem is to bring about, in the world, the transformation X --> X'
If that can be done, then the problem is solved.
So the problem already points to it's solution, and the schematic already contains the solution. It is the transformation from X to X'. The transformation clause is a description of the solution.
But of course, as they say, the devil is in the details.
So, sure, if my problem is: How do I improve the efficiency of this process? an answer would be: Transform it from the efficiency it is now to something better.
Or
How do I improve my GPA? Answer: Transform it from what it is now to something better.
These are answers to the problem question, they are solutions to the problem, they're just not very satisfactory solutions. They don't tell us how to actually do what's asked. They don't provide the detailed steps one would have to carry out to accomplish the desired solution.
And this is how things go with problems. When a problem is presented to you it won't be given with all of the details. The person for whom you are solving the problem --- the person who is coming to you with a problem they need you to solve --- won't have the expertise (or the time) to give you all of the details. If a problem is presented to you fully spelled out then noone will need you to solve it.
Your job, as the problem solver is to recognize what's being asked for, and to figure out how to accomplish that. In particular, you need to recognize the objectives of solving the problem.
So this should remind you of what we said in quad 1 about alignment. When someone gives you a problem --- whether as a student, or an engineer, or any other context --- they're asking for a certain outcome.
The closer you get to bringing about that outcome, the better your solution is.
In the last part of this quad we'll talk about problem-solving as filling in the details: making the question precise by making the transformation clause precise.
2.4 A problem solution is a reliable prediction
So now we know that a problem is a how question. And solving the problem involves making that question more precise, figuring out precise steps to bring about the transformation. Solving the problem means making the description of the transformation more precise.
This is an interative, reflective process. To put it in terms of the schematic, you go back and forth between filling in the details of the Xs, and of the arrow. You need to understand:
· the process as it currently works, and why it has the efficiency that it does (that's the X)
· you need to think about what the new process might be like, what would have to be different to make it more efficient (that would the X')
· and then you should think about how to go about actually changing the process, to adapt it from what it is now to what it could be. (that's the arrow)
· but as you think through the arrow you'll probably realize you need more specifics about the process. How much of the tooling will need to be re-done? Can you use the same power supply?
These questions will mean you have to go back and refine your endpoints some more. Then you'll have more questions about the arrow, etc. etc..
This is what thinking through a problem solution is: you ask questions about answers to questions about answers to questions.
When does it all end? When do you have a solution? You can consider a problem solved when you have a reliable description of the steps to carry out.
You can't go on forever --- the transformation clause won't spell out every single step in minute detail. whoever carries out the solution will have to fill in some details on their own.
But the details left out shouldn't matter. Which means the person following your instructions, assuming they are reasonable and competent, can fill in the steps as they see fit and the solution will still succeed. It's more or less what we mean by "fool proof" --- except that, in this case, it is expert proof.
Your responsibility as an engineer won't be to come up with fool proof solutions. But you are responsible if a detail is left out and something goes wrong because of it.
3. Expertise is if-then knowledge
Top of Form
1. Introduction
In this quad we're going to talk about the idea that expertise is if-then knowledge. Now in one sense that's just how we're defining expertise. You could just memorize: expertise is if-then knowledge. And so it would follow from that definition that if one has expertise in a particular area, or a particular domain, then one has if-then knowledge in that particular area or domain.
But rather than just assert this definition, first we're going to see how we know, or why we would think of expertise as if-then knowledge. What do I mean by that definition? What does it mean to say that expertise is if-then knowledge.
That has to do with the role that expertise plays in problem-solving. In quad 2 of this unit we began to talk about how problems are how-questions, and that problem-solving means making that how-question precise. In particular, it's making the transformation clause more precise. The engineering expertise you have is your ability to make problems precise; to fill in the details of the transformation clause.
Expertise allows you to make a problem precise. gives you the tools to make a transformation clause precise by making the steps in the transformation precise.
Your precise solution will be a prediction about how things are going to go when certain steps are carried out. The knowledge it takes to make such predictions is if-then knowledge.
After that, we'll discuss what it means to say one has if-then knowledge in a particular domain. What is that if-then knowledge about? If-then knowledge is "in" a particular domain, because it is if-then knowledge about what we'll call entities and activities in that domain. The entities are the things, and their activities are how they behave under various circumstances, as well as how they interact with one another. Put simply, you need to know stuff about things to be able to solve a problem. And particular kinds of problems (electrical engineering problems vs. chemical engineering problems vs. biomedical) require knowledge about particular kinds of things.
It makes sense that expertise and problem-solving would be connected in this way. Which problems you can solve depends on the expertise you have. Engineering codes will always specify that a professional engineer has an obligation to only take on projects which are within their expertise.
And as a final point, notice that expertise determines what you can explain to others, and what can be explained to you by others; expertise determines the range of what you can understand, and what you can understand is a measure of your expertise.
When you're explaining something to someone else --- like your proposed solution to a problem --- you ought to think about their expertise if you want to be understood. When you're working in a team, which you will almost certainly do a lot as an engineer, the people on your team will have expertise different from you. Working together means explaining things to one another, understanding one another.
You will be better at that if you reflect on your expertise and the expertise of others.
Bottom of Form
3.2 Expertise allows you to make reliable predictions
The point I'm going to make in this part of the quad is that expertise allows you to make reliable predictions. This is the first step in connecting expertise with what we're calling if-then knowledge.
The link is going to be through the role which expertise plays in problem solving.
Problems are solved by applying your expertise, or by applying the combined expertise of a team.
A problem is solved, we said, once we've given enough detail to the transformation clause, once we've made the transformation clause precise enough.
So it must be that applying our expertise is what allows us to make a problem more precise; expertise allows us to give enough detail to the transformation clause such that it provides a solution to the problem.
Now, enough detail means that your solution provides: an understanding of the steps to be carried out, and the confidence that carrying out those steps will, reliably, result in the outcome you wanted. The steps as described in your solution will reliably result in the desired transformation taking place.
In other words, this means that a problem solution is also a prediction. A problem solution is a prediction that specific steps will lead to the predicted outcomes. By proposing a solution to a problem you are predicting that those steps will lead to that outcome.
And you are relying on your expertise to make that prediction.
So this tells us something more about what expertise is like. If we think a little more about what is needed to make a reliable prediction, we can learn a little bit more about what expertise must be like.
That's what we're going to do in part 3. We'll talk about what reliable prediction requires, at least when it comes to engineering and engineering problem solving.
3.3 Reliable prediction requires knowing how things respond to conditions
What does reliable prediction require? At least when it comes to engineering and engineering problem solving.
The reason for thinking about this question is that we know that expertise is what we use to make reliable predictions in the context of engineering problem solving. So it's expertise that's providing what we need to make reliable predictions. If we can figure out what that is, we will learn something more about what expertise is. And as we've already said¸ reflecting on expertise will make us better problem-solvers, and better collaborators and team members.
Problem solutions are predictions because they describe a set of steps to take which should bring about the transformation asked for in the original problem. So the solution is a commitment about what is going to happen as the result of those steps.
It is, in other words, a prediction about what is going to happen from those steps.
Those steps will involve tools, or apparatuses. They might involve chemicals or other materials, pieces of equipment, other kinds of technology, machines.
It's your expertise, your training, which tells you how these things are going to behave, how they ought to respond, what they will do when the steps are carried out.
What kinds of things we're talking about will depend on the kind of engineering you are doing. It will depend on the kind of engineering you can do, what expertise you have.
The important thing is that it is your expertise you are relying on in making your predictions about outcomes of actions. Your predictions are as reliable as your expertise is good.
And the more you know about how the relevant equipment, technology, materials etc. are going to behave, the better your expertise is.
Some of this will come from your university education, and from theory. Most of it, the best of it, will come from hands-on experience.
But what it is, wherever it comes from, is knowledge about how things will respond or behave under different conditions, or when used in certain ways.
That's the expertise you rely on in predicting your solution will work.
That's the expertise which makes your prediction a reliable one.
Top of Form
3.4 Knowing how things respond to conditions is if-then knowledge about entities and activities.
So, in the previous two parts we've established that it's your expertise you rely on in to give details to a problem solution; and it's your knowledge about how things will work or behave or respond that makes that proposed solution a reliable one.
Here, in part 4, we'll introduce a couple of new concepts in order to make talking about and thinking about expertise a little more convenient.
Again, the point of this, as always, is to give you things to think about so that you can be a reflective engineer. It's easy to say things like: "to be a better engineer you should think about what you're doing." But think about what exactly? And more importantly, think how? Having some ready concepts, and some ready questions, will make it easier for you to do your due diligence as an engineer. The right concepts will make it easier to reflect on what you're doing.
And just to be clear, you should know that, even if you start by pausing to think about concepts like expertise or transformation, it's not necessarily those concepts which will matter. The point is that by thinking at all, about something, about anything, you have a much much greater chance of noticing something else which does matter, something you might not have noticed. You have a much much greater chance of catching some mistake before it happens.
So, back to our topic. Expertise allows you to make reliable predictions, and its knowledge about how things will respond to conditions.
In part 3 of this quad, we went through a list of things you might use in solving an engineering problem: tools, apparatuses, chemicals or other materials, pieces of equipment, other kinds of technology, machines, etc.. We can sum these up with the term entities. Which is just a fancy word for things. Every domain of engineering, every domain of expertise, will have its own entities.
Those entities have characteristic behaviours and properties. Electrons have their charge; they have their mass; they respond to electric fields. We can calculate their trajectories from their charge, mass, velocity and the strength of the field.
The field is another entity. It has a direction and a strength.
So in addition to the entities and the properties we can know about them, there are also their behaviours, particularly their interactive ones. The field causes the electron to travel in a curving trajectory. The chemicals will react with one another; the catalyst will cause the rate of that reaction to increase.
The stuff that entities do, and the way they interact, we can sum up as activities.
So expertise is knowledge about the entities and activities of a domain. If you have expertise in biology, then what you'll know about are entities --- things --- like genes, or eukaryotes, or cephalopods. You will know about activities like, if a gene is subject to certain environmental stresses then it is more likely to mutate.
The more that you can say about the trajectories, the reactions, the causes, and the properties those activities involve; the more precise and detailed you can be about those activities, the greater your expertise is. The greater your understanding is.
You can say "react", or "makes it speed up"; or you can say "oxidizes by transferring electrons", or "introduces a ready supply of radicals needed for the second stage of the process".
The words you use matter. Expertise is being precise. The sentences you use matter.
And sentences are the subject of the last point of this quad.
At the end of the day what your expertise boils down to is the set of if-then claims you can make. Knowing how things will responsd to conditions --- which is what you need to make your problem-solving predictions --- knowing about entities and their activities, is if-then knowledge.
For example:
· IF I modify the process in ways X, Y, and Z THEN the efficiency will go up.
· if I change my study habits in the following ways then my grades will improve.
· If an electron travels through an electric field then its path will be deflected according to the right-hand rule.
If-then claims are predictions about what will happen in particular conditions. For this reason if-then statements are also called conditional statements, or conditionals for short.
We'll be talking alot about if-then throughout the remainder of the course. Anywhere you gain expertise, you are gaining if-then knowledge. Anywhere you apply expertise, you are applying if-then knowledge. You might not do it explicitly, but it's there in the details, in the background.
Bottom of Form
4. Problem solving and explanation use the same expertise
Top of Form
4.1. Introduction
Expertise provides the tools we need for solving problems.
Expertise is knowledge you can use to make predictions about what to expect under certain conditions, or what will happen when steps are carried out.
In this quad we're going to say a bit about what that knowledge is like, and explain how it makes us able to predict or explain. Expertise is knowing how things will behave, how different kinds of machinery, or tools, or materials will react, or interact, in different situations. Expertise is knowing what you can do with equipment, materials etc., and what you can't.
These things, and the stuff those things do, we will refer to in general as entities and activities. You'll be asked to think about and identify some of these for your ABET written assignment.
This same expertise makes it possible for you to understand explanations or solutions of others who have the same expertise --- which makes sense: you can only solve the problems you understand, and vice versa.
Part of what we're up to in this quad is thinking through this connection, trying to get clear on the details.
But it's more than just that.
It's a very useful thing to grasp that problem-solving and explanation / understanding use the same expertise. Because this can give you a test for your problem solution.
It goes like this. - You want to be a responible engineer, or you should ... one who's done their due diligence thinking through a problem solution, trying to anticipate problems, potential failures, oversights, and so on.
· You can reflect on your solution by trying to explain your solution. See if you understand it.
· If you can't explain it, you don't understand it. Trying to explain your solution will reveal to you how much you actually know about all of the steps in your solution, and all of the links in your reasoning and expertise.
· That's because, as we argue in this quad, solving and understanding rely on the same expertise.
This is a general point worth making about how we can use the philosophical analysis we're engaging in. It provides a source of questions and concepts for you to reflect on, to think through. It can be like a checklist, a routine you go through which requires you to pay attention to the important details, and increases the chance that you will notice something you would have otherwise missed.
Bottom of Form
4.2 Problem-solving requires prediction, understanding requires explanation
In this quad we're looking at the relation between predictions and explanations.
Predictions and explanations are essentially the same. Really, only the time of giving them differs.
Consider an event, like a colour change of a chemical solution. I can tell you a story about a chain of events which leads up to that colour change taking place.
If the story is given before the change takes place, then the story is a prediciton. A prediction is a story about what is going to happen.
If the story is given after the change takes place, then story is an explanation. An explanation is a story about what did happen.
But it would be the same story in each case.
In the remaining videos of this quad we'll explain how the two stories are the same. In what way are they the same?
Here the point is to connect problem solving with prediction, and understanding with explanation. In that way, if prediction and explanation are linked, then problem-solving and understanding will be linked.
Problem-solving is making a question precise. You fill in the details of the problem, you keep asking questions, until what you have is a description of the steps you need to take to bring about the desired transformation.
Explanation is making a story precise. A story about how things behave, respond, change. Telling such a story --- and understanding one --- depends on your if-then knowledge about the entities and acitivies involved in the events.
In sum: problem-solving is achieved by prediction; understanding is achieved by explanation.
4.3 Prediction / explanation require knowledge about entities / activities
This video will be short and quick.
The point we want to make is that prediction and explanation both require knowledge about entities and activities. But we've already laid most of the groundwork for that point in earlier videos.
In quad no. 3 of this unit we described how reliable problem solving requires if-then knowledge about entities and activities; that your expertise is if-then knowledge: if entity X is in situation Y then it will do Z.
And we just described, in part 2 of this quad, how problem solutions are predictions, and how stories which provide understanding are explanations.
Both predictions and explanations rely on, then, if-then knowledge about the entities and activities of a domain --- predictions and explanations depend on, just as we would expect, your expertise in that domain.
So it's the domain, the area of expertise needed for a problem or for understanding, which determines what entities and activities are important or relevant.
Bioengineering expertise is different from electical engineering expertise; aeronautical is different from industrial design. They're different because of the entities each kind of expert will know about, and how those entities will behave (their activities) under various circumstances.
The link between domain and entities and activities is what will allow us in the next part to say prediction and explanation use the same entities and activities. The link will allow us to complete the argument that is the explanation of the point of this quad.
4.4 Prediction / explanation require knowledge of same entities / activities
This video, too, will be short and sweet, having laid all of the groundwork we need.
We want to argue that prediction and explanation require knowledge of the same entities and activities. But we want to be precise, and clear in that argument.
We said that prediction and explanation both tell stories, but that one, prediction, tells the story before it takes place while the other, explanation, tells the story after.
To make a reliable prediction I need if-then knowledge about the entities and activities involved in that story. I need to know that the entities involved will reliably behave in the ways expected, given the relevant circumstances.
Similarly, to grasp an explanation I also need if-then knowledge about the entities and activities involved in that story. To understand and accept an explanation, I need to believe that the entities involved would reliably behave in the ways described, given the relevant circumstances.
But whether the story is told before or after, it is still the same entities and activities involved. It is still in the same domain of expertise. The things I can predict, and the explanations I can understand, turns on the expertise I possess.
It's this same link again: the problems I can solve are the problems I can understand. I can only reliably solve problems within the areas of my expertise. I can only fully understand explanations within the areas of my expertise.
5. Problem solutions are subject to technical and non-technical constraints
Top of Form
5.1 Introduction
Now that we've described something about what problem-solving is like, how we use expertise to arrive at a precise and reliable prediction, we're going to introduce more detail into this.
In this quad we're going to introduce the concept of a constraint.
In thinking through how to achieve a problem solution, thinking through what's possible, we're already applying one kind of constraint. Namely, constraints on what is possible. Your if-then expertise is knowledge about which activities the entities are capable of. It's knowledge about how things work in the world.
But, as we've said from the outset, with real world problems there is no perfect solution, and considering what's possible isn't enough. Other factors having to be taken into consideration. Factors like time, and budget, safety, the environment, aesthetics, ergonomics.
These are all a different kind of constraint. And you won't be able to satisfy them all.
Because you have to make choices about these constraints, because you have to evaluate them and weigh them against one another, for that reason that we said normative expertise, i.e. ethics, is integral to engineering.
So in this quad we're going to explore the nature of constraints. We'll see that there are two kinds: the technical and the non-technical. We'll see that problem solving requires recognizing both kinds of constraints, and doing one's best to satisfy them, though completely satisfying them all is never really going to be an option. Your technical expertise will allow you to construct a range of possible solutions; your normative expertise will allow you to select the most preferable from among those possibilities.
Bottom of Form
5.2 Technical constraints limit what is possible
There are two types of expertise, then. There is technical expertise, and there is non-technical expertise. Among the non-technical we'll aslo identify 4 more specific kinds, but that's for the next quad. Here I just want to talk about the technical constraints, their source, their nature.
Technical constraints are the ones you're most familiar with already. They're the ones you're learning about in most of your engineering classes.
Technical constraints have to do with physcial entities and activies, whether those are fundamental particles, biological organisms, electromagnetic waves, or the most sophisticated equipment. Technical constraints are constraints on how these things behave; what these things are capable of.
Knowledge of technical constraints is knowledge of the physical laws which govern the real world. They tell us how much weight something can bear, or how much something will weigh. How strong a reaction will be, how light a structure will be. What colour it will have, what texture.
Knowledge of technical constraints is knowledge about the descriptive facts in the world.
So the source of the technical constraints on a problem is nature itself; the world, the universe, reality.
You don't have a choice about satisfying or not satisfying a technical constraint. Not satisfying a technical constraint is not possible. It is literally impossible. If your solution depends on violating a law of nature you're in big trouble. Technical constraints can literally rule out solutions.
So you certaintly have an obligation to know what the technical constraints are so that you don't propose a solution that's going to fail.
This means that even here, in the most technical part of engineering, there is still normativity and ethics as a part of it. There is an ethical obligation on your part to be aware of, and reflective about, the technical constraints that apply to your problem.
5.3 Non-technical constraints limit what is preferable
Now let's talk about non-technical constraints.
Non-technical constraints are, in fact, usually the more important kind of constraint. Engineers solve problems in the real world, with real clients. This means that the kinds of considerations that non-technical constraints represent are what determines which problems get solved and how.
Possibilities are fine; theoretical solutions, elegant or clever solutions, dreamt up by clever engineers, are fine. But real solutions are ones someone has to pay for, someone has to take responsibility for, someone has to live with.
This points to the source of non-technical constraints. Their source isn't in nature, or the laws of physics or such, like they are for the technical constraints.
The source of non-technical constraints are the people just mentioned: the people who have to pay for the solution, implement it, take responsibility for it, live with it.
These people are stake-holders. Stakeholders in a problem are people (or groups or organizations) who will be affected by the solution chosen. Stakeholders have an interest --- have a stake --- in the problem and how it is solved.
So first we can divide constraints into two kinds: the technical, having a source in nature, and the non-technical, having a source in stakeholders.
But we can identify four more specific types of non-technical constraints. We use the mnemonic PEAS for the four types. They are the practical, the ethical, the aesthetic, and constraints of safety.
I'm not going to go through those in this lecture. They're described in the text and in the glossary. Examples are given there too.
What I will say, though, is how we should think about the non-technical constraints in relation to the problem schematic, and the transformation clause.
The possible transformations, the ones which are technically feasible, were the arrows between the X and X' of the transformation clause. There can be many different arrows; many possible solutions.
But the non-technical constraints eliminate some of those arrows. Or at least they impose a constraint on them. One arrow might be two expensive; the other too risky. No arrow is going to satisfy all stakeholders, or meet all the non-technical constraints. They'll satisfy them to degrees, more or less, but not completely or all together.
So in choosing a solution, in deciding on one of the arrows, you're making a choice about which constraints to emphasize. A solution represents preferences. You're choosing the most preferable solution from among all the possible ones.
And that, of course, is a value judgment. The expertise it takes to make those, defend those, justify those judgments is ethical, or normative, expertise
5.4 Best solution is most preferable of the possible
To wrap up this quad then, I just want to emphasize two points about the implications there are for engineering ethics because there are these two kinds of constraints.
The first point hearkens back to the master narrative again. There is no perfect solution. There may be many possible solutions, but none will meet all of the non-technical constraints. Each solution will satisfy the non-technical constraints only to a certain degree.
Some examples of what I mean are: You'll want to keep costs down, while maximizing performance or efficiency or power, lightest weight, greatest safety, minimal risk, timeliest turn around. Flashy new materials, versus tried and true methods. Savings for the client, but meeting obligations and responsibilities to the company, and to the profession of engineering.
So every solution represents a complicated and subtle weighing of all of these things of value. And value judgments are normative judgments. They are ethical decisions. You cannot do engineering without them.
Now that you know about all this, we come to the second point. You might not agree that any of that is really the job of the engineer, or that making these ``management'' decisions is an integral part of what one does as an engineer. You may still think that the non-technical stuff is not really your responsibility, or not really a core part of your responsibilities or duties as an engineer.
What you do need to recognize, though, is that even this --- the "that's not my job" position --- is a normative, ethical, position to take. It's taking a stand on what an engineer ought to care about; it's taking a stand on what their obligations are. If you take that position then you have an obligation to be sure it's the correct one, that you're not being negligent. That you are not shirking your duties as an engineer, or to the profession you're planning to become a member of. (Notice that this is an if-then statement, by the way. Knowing that if you take that position then you have an obligation to be right, is a little bit of expertise.)
So, denying that engineer's have a need for ethical expertise is not actually going to get you out of the need for ethical expertise. It's not going to get you out of having to do some normative work. You still have an obligation to be right about that. At best, it's just different normative work.
6. Choices about non-technical constraints are choices about people
Top of Form
6.1 Introduction
This is the 6th quad of the first unit. In this quad I'm going to explain the following claim:
``Choices about non-technical constraints are choices about people.''
In brief, the connection between the constraints and the people is that the source of non-technical constraints is in the stakeholders to a problem. A full explanation will also make clear what choices we're talking about. Just because the source of the constraints is people, does not automatically mean that choices about one are choices about the other.
As we explained in quad 5, when it comes to the solutions of real world problems, the transformations by which those solutions can be realized, none of the possible transformations will perfectly satisfy all of the non-technical constraints.
Choosing a solution, then, means weighing the relative values behind these constraints. And those values are the values held by the stakeholders.
Choosing a solution is making a choice about the concerns of those stakeholders, which ones you are going to treat as most important, which ones you'll try hardest to honour.
And so again, we can see how ethics is integral to engineering. This is another way to reinforce the master narrative of the course. Reasoning about values well, in a clear, reflective, and justifiable way, requires the expertise you gain by studying ethics.
Engineering is problem-solving; problem-solving requires reasoning about values, and that requires ethics.
Bottom of Form
6.2 Stakeholders are the sources of non-technical constraints
In lecture 5.2 we've already stated that the source of non-technical constraints are stakeholders. Stakeholders are those who have a stake in the solution. That is, they have an interest, or they could be impacted. They are the people who have to pay for the solution, or those who have to implement it, those who have to take responsibility for the outcome, and those who have to live with those outcomes.
Stakeholders may be invidiuals. They also may be groups of individuals, such as a community, or a business. Your family, for example, are stakeholders in what you do as an engineer. But let's be a little more precise about what we mean when we say that stakeholders are a source of non-technical constraints.
The technically possible problem-solutions are represented by the arrows in the trans- formation clause. The arrows point from the current state of affairs to some new state of affairs. The arrows represent ways of potentially bringing about the problem transformation.
But as such, they represent only descriptive information. They represent facts, and states, and steps, which will happen in the world. Even the start and end points are just that. The start point might be something we're not happy with. And the end point might be something we would prefer.
But the states that we're talking about, and the steps in between, are still just facts. What makes a problem a problem, and what makes a solution a solution, is how we feel about those facts. That's the normative side of problem-solving. There are values we attach to the states of affairs, and to the pathways between them.
All values, all valuing, have their source in people. It's people that look at a state of affairs, or some set of facts, and decide whether they are good or not. People make normative judgments.
Now, it's a reality that people make these judgments, and you as an engineer must be aware of them, take them in to account, and be responsive to them. But the non- technical realities are distinct from the technical side of things, even though it's usually the technical side which we think of as "proper" engineering. This would be a mistake.
6.3 One solution cannot satisfy the preferences of every stakeholder.
The kinds of things which make up non-technical constraints are usually incompatible with one another. Non-technical constraints usually compete with one another.
Making something very safe requires over-engineering, redundant or backup systems, the strongest materials, the most conservative designs.
But all of these cost money, they take longer to construct, they make things heavier, they may have a cost for performance.
Choices like these are in fact usually the reason you will have more than one possible problem solution available. It's because you'll have choices you can make about which materials to use, or how much of each material to use, what tests to perform along the way, what features to include or not include in a design.
All of these degrees of freedom mean that there are different pathways by which a transformation can be achieved.
But the differences in the features are also differences in the things which the stakeholders care about. Some stakeholders will put a high value on safety (some users of the product, for instance); some will put a high value on performance (specialists who have more experience and tend to be safer users of a product may want more performance).
So every solution represents a different combination of features. Stakeholders will value some of those features but not others. They will value them to different degrees. Many features are competing, just as the values placed on those features are competing. So no solution can have all of the features which will satisfy all of the preferences of all of the stakeholders.
The point of the next and last part of this quad will be obvious then: choosing a solution is choosing a set of features; and choosing that set of features is choosing whose set of preferences is most important.
6.4 Choosing a solution is choosing whose preferences to value.
Let's start with a simple analogy which might help. Imagine you're planning a roadtrip with two friends. You have different routes you can choose. One route is very scenic but takes a long time. The other route is quick but not very scenic --- it's mostly freeway and alot of traffic. One of your friends, it turns out, prefers a scenic route, but the other prefers just to get there sooner rather than later. You can't have both, and everyone can't be happy. But who gets to be happiest is going to be affected by your choice.
Choosing a problem solution is a lot like that.
As we've established, the source of non-technical constraints on a problem solution are the stakeholders in the problem and its solution. A non-technical constraint represents the preferences of that stakeholder. A solution will meet the preferences of a stakeholder only to a certain degree. No solution can meet all of the preferences of all of the stakeholders.
Different stakeholders will be more or less satisfied with any particular solution to a problem, depending on the features of the solution, the design choices, the steps taken. When you choose a solution your are choosing to satisfy those preferences in that way, to that degree.
You're placing a higher value on the constrainst you satisfy and lesser value on the ones you do not.
If you choose a solution with stronger materials and lots of redundant systems, over-engineered supports or capacities or operating margins, then you are placing a high value on safety. And your probably doing it at the cost of being more expensive, sacrificing performance, or time to achieve. Those are the things you are placing less value on. Those values are less important to you.
If a particular stakeholder values cost but you put less value on that non-technical constraint, then you are putting less value on that stakeholder.
7. Normative claims add information to descriptive claims
Top of Form
7.1 Introduction
We've already come across the distinction between descriptive versus normative claims. This came up in talking about why ethics is integral to engineering (the Master Narrative.) And it came up in talking about the difference between technical and non-technical constraints.
In both cases the idea was that there is a difference between what the facts are, and whether those facts are desirable or not, whether they are good or not. Whether a fact is a good thing is a matter of judgment. It is a matter of judging a thing to be good, and that will depend on what you value. Making a judgment about whether something is good or not is a normative judgment.
The word 'normative' is an adjective we use to describe claims, or feelings, or judgments which are about whether some is good or not. The word normative comes to us from the root norm, which in Latin originally meant a builder's square. (Not only is normativity integral to engineering, the word itself comes from engineering.) So a norm is a standard for judging something correct, or right ... maybe even literally right, as in right angle.
For any angle, there is a fact about the size of that angle. And there is likewise a descriptive claim which states the size of that angle.
But whether an angle is the right angle will depend on what the angle ought to be. It has to be compared with some standard. Maybe that standard is a literal right angle. Maybe there's some range that is good enough.
The point is that judging that a fact is what it ought to be is comparing that fact with some norm.
In decision making, engineering problem-solving, ethical reasoning, the standards or norms are going to be values. Those values might be your own; they might be the values of other stakeholders. They might be the values held by the profession of engineering itself.
We'll be talking a lot about values, and where to locate them, in the next unit on theories of normative ethics.
For now, in this quad, we just want to emphasize the point that normative claims are related to descriptive ones. In particular, a normative claim says something about facts, and so adds information to those facts.
This means facts, on their own, can never be enough to justify a normative claim about those facts. The extra information also has to be justified in some way.
That's what ethical theories are for. That's what normative expertise allows you to do.
Bottom of Form
7.2 Descriptive claims are is claims
Descriptive claims are is claims.
Although this looks like a typo, it isn't.
Descriptive claims are claims about what is the case. So they are "is" claims.
The contrast are normative claims, which state claims about what ought to be the case, as opposed to what is the case.
The general kinds of claims we're talking about are declarative sentences. We also call these propositions in philosophy. They state something which can be either true or false, or at least correct or incorrect.
Questions are not declarative sentences. How are you?'' is not the kind of sentence which can be either true or false, correct or incorrect. The same thing goes for what we call imperatives, or commands:Get out of here!'', ``Say hello for me." These are not sentences which are either true or false.
Examples of sentences which are declarative are: The load is 30MW. Eels are slimy. This wing profile generates 30% more lift.
These examples all happen to also be descriptive declarative sentences. They state facts. They make is claims. Nothing is said here about whether the load is good or bad, too high or too low. You might think eels are gross, you might think slimy is gross, but being slimy is compatible with many feelings. Some people might think slimy is cool. Slimy might be essential to the survival of the eel.
Descriptive claims simply state what is the case. What the facts are. What makes them true or false, correct or incorrect, are realities in the world. Descriptive claims may talk about future realities, as in problem solutions; they make talk about past ones, as in explanations.
Solutions and explanations, we will see, are actually chains of descriptive claims. They are chains linked together by if-then statements. So it's your if-then knowledge --- you're if-then expertise --- which allows you to make these chains of claims.
The claims of a descriptive prediction are correct if that's the way the world turns out. The claims of a descriptive explanation are correct if that's the way things actually went.
So to find out whether a particular descriptive claim is correct or not, we would have to gather some information about the way the world is (or was, or turns out to be.) When we say there is information contained in a claim this is what we mean. What a claim says about the world, if it turns out to be correct, is information about the world. The claim is asserting that information.
7.3 Normative claims are ought claims
Normative claims are ought claims.
Normative claims state claims about what ought to be the case, as opposed to descriptive claims which state what is the case.
Descriptive claims describe facts. Normative claims state value judgments about those facts. They state whether some state of affairs is good or bad, desirable or not desirable.
We call them ought claims because of the implication that, if something is bad, it ought not to be the case. Or, if we think something is good, then we think that's how things ought to be. (And in this course, when we say something ought or ought not to be the case, what we're really saying is that somebody ought to do something about it. Our ought claims are about actions specifically.)
Ought is just a general way of trying to capture all of the different normative feelings we have, such as our values and our preferences.
If you think hockey is a good sport then probably you think more people ought to watch hockey, or play hockey.
If you think broccoli is gross then you probably would agree that people ought to make you eat it less often.
It's that kind of connection we assume can be made between something you like or dislike, something you value or do not value, something you prefer or do not prefer, and some ought claim about an action.
In particular, we're going to be looking at ought claims which refer to actions: what people ought or ought not to do.
You ought to tell the truth. You ought to be professional. You ought to listen to more opera.
Normative expertise in engineering is really about deciding what we ought to do in various situations. Ought we to use this material? Ought we to choose this solution? Ought we to invest in research on this technology? Answers to these questions will be normative claims. We ought (or ought not) to use this material. We ought (or ought not) to choose this solution. We ought (or ought not) invest in research on this technology.
The correctness of these ought claims will depend in part on the facts. (They will depend on the correctness of the underlying descriptive claims.) But not only on the facts. Other kinds of information and theory are going to be needed to back up the correctness of these claims. That's what theories of ethics are about. The study of ethics provides the theories and the expertise to justify normative ought claims.
7.4 An ought-claim about a true is-claim can be false
So descriptive claims are is claims; normative claims are ought claims.
Normative claims state value judgments about descriptive claims.
You can give a descriptive claim about the color of some material, or its strength, or its durability. But whether it's an ugly color, whether the strength and durability are good enough, adequate, etc., these are normative claims. They assert something more about the facts, something more on top of the facts. They carry additional information.
The correctness of normative claims does depend on the facts. If you say a strut ought to be stronger, you had better be correct about what strength it actually is. Depend also means that if the facts change the correctness of normative claims will change.
But you also need to be correct about your other reasons: i.e. what the code says, what strength is needed to be safe, but also how safe is safe enough, and why? What's the right margin of safety? Normative claims also depend on this kind of information, which is information about preferences or values.
Codes exist to express and promote values of a profession, or of a society. These are values like safety, fairness, professionalism, obligations and responsibilities. Your choices as an engineer about solutions will reflect your values and preferences. You might be an extra cautious engineer, or you might prefer to focus on efficiency, cost-savings, and tight adherence to code minimums. You might prefer to use the latest and most innovative technologies, or be more conservative and rely on tried and true techniques.
These are all choices and values which are in addition to the facts and the details.
This is the relation we'll be stressing over and over again in the course. Engineering is only partly a matter of technicalities and details, materials and mathematics. There is a large part which depends on those details but also on values and preferences, on what is right and what is wrong. Having normative expertise is just as much a part of engineering as your technical expertise.
To sum up the main points of this quad: normative claims add information to descriptive claims. They claim things on top of the facts, or about the facts. Even if the facts remain the same, a different set of preferences, or a change in values about acceptable risk, appropriate costs, speed of delivery, can change the correctness of normative claims.
As an engineer you have an obligation to understand those dependencies, to think about them, and to justify your normative choices. These normative choices depend on the technical details. To understand and justify them therefore requires a knowledge of the technical details. An engineer, then, will be best able to make these claims and justify them. Such an engineer would also require normative expertise.
8. Expertise is like a part off the shelf
Top of Form
8.1 Introduction
In this quad we will explain this connection: expertise is like a part off the shelf.
To explain that connection in answer to a 3-sentence short answer question you would want to say something about what expertise is. You would also want to say something about what a ``part off the shelf'' is.
But the most important thing to explain in answering this question is the connection: in what sense is expertise like a part off the shelf? What do they have in common?
The quick answer is that they both demand the same responsibilities when we use them. When you use some part (a gear, a chip, a controller, a chemical) in a problem solution, something you design or build or just grab off the shelf, you have an obligation to be sure the part is actually going to work. How is it going to work? Do you understand the part well? What are its limitations? Under what sorts of conditions might it fail to work properly?
You need to know what range of application that part has. Is it actually reliable for the situation you plan to use it in? Being certain about this will usually require knowing something about how the part operates, what principles it relies on.
Similarly, when you rely on your expertise to solve a problem, you are plugging into a solution your if-then knowledge. That if-then knowledge is just like a part off of the shelf. It's a part you have available to use to create a solution to a problem.
But just like a part off of the shelf, you have an obligation to use it properly; to not use it outside of its reliable operating range or conditions.
This will be particularly important when it comes to normative expertise. These are if-then parts just like any other and they have a proper range of application. You need to know which kinds of normative claims you're relying on, and where they work best. Or where they do not work so well.
Bottom of Form
8.2 Solving problems requires applying your expertise.
When you solve a problem as an engineer you need to figure out the details of how to bring about some transformation. You are filling in the details of the transformation clause within a how-question.
And as we've also explained, those details are going to describe a series of steps to carry out so that the transformation is achieved. The solution is a prediction. Knowing that the series of steps you predict will work actually will work relies on your knowledge about entities and activities, how things will behave and respond, the way entities will act and interact. Your solution is a prediction that doing X and then Y, etc. is going to result in W and then Z, etc. happening.
You know this kind of stuff because it is the if-then knowledge of your expertise. Your knowledge, your expertise, is a huge set of claims and beliefs you have about the world. You have gained these (or will gain them), and you will continue to gain them, through your courses, through on the job training, through career experience.
As a useful exercise you can try to list some of the things you have expertise in. It might be knowledge about particular items that an engineer might use, like electronic components, testing equipment, materials, other devices or tools.
Your expertise might include if-then knowledege in mathematics or physics, about what integration will tell you (if I integrate this kind of function I will get ...), or differentiation, or solving some set of equations (Newton's equations of motion and how to use them.) How to use a Lagrangian to find the equations of motion for a system. How to calculate the enthalpy of a reaction. That sort of thing.
As another example, finding the determinant of a matrix might be a bit of expertise that you have. And if you really have it, if you really understand it, you'll be able to say things about how the determinant behaves under different circumstances. Knowing things about the properties of the determinant tells you things about the properties of the matrix. If the matrix changes, the determinant changes.
So in solving a problem as an engineer you are applying your if-then engineering expertise to that problem.
If-then knowledge is like a bunch of parts or tools which you have available.
Your expertise is a toolbox, if you like, full of useful items to help you construct (predict) a problem solution.
8.3 Expertise has a limited range of application.
The link we're unpacking in this quad is between your expertise and the analogue of a "part off of the shelf." In short, that link is that in each case you have a responsibility to use that expertise, or that part, properly. That means knowing when and where it will work properly, what it's limits are, etc..
That a part off of the shelf will have a limited range of application is obvious. But in order to make the link with our expetise, we need to be see how expertise also has a limited range of application. That's the aim of this part of the quad.
First point: expertise is if-then knowledge about entities and their activities. It's if-then because it's knowledge about how those entities will behave and interact under different conditions. (If-then sentences are also called conditional sentences. They are about the connections between conditions, states of affairs.)
Specifically, they have essentially this form: IF conditions are such and such THEN the entity is going to behave in so and so way.
Obviously this requires knowing the if-then stuff. But also you need to know what the conditions will be.
Your if-then knowledge only applies to certain conditions.
Your if-then knowledge is only true for a certain range of conditions.
Most of the expertise that you will be aware of, and which you're being trained in as an engineer, is technical if-then knowledge. It is if-then knowledge about entities and activities, about how things behave under various conditions. But the source of that behaviour is in nature, in physics, in biology or chemistry.
Throughout this course you will also be gaining non-technical expertise. These are if-then claims that are about values, whether it's about obligations or consequences or character. It's knowledge about when something is good or best. One source of non-technical if-then claims is in the stakeholders, just as the source of non-technical constraints is in stakeholders. This is where the values come from. (The other source are the theories of ethics which we will study.)
We also need to be sure to understand that non-technical expertise has a limited range of application. And of course it will. It will be limited by the values that apply, the codes of ethics which apply, the obligations, which theory of ethics your appealing to, and so on.
With non-technical expertise, it's still if-then knowledge about entities and activities, but these are different kinds of entities and activities. They include stakeholders and values and obligations and virtues and the like.
These details will be come clearer later on.
For now, the main point is that all if-then knowledge is limited to the range under which entities will behave in the ways we expect them to behave.
8.4 Engineers have an obligation to use a part properly.
So, in solving a problem as an engineer you are applying your if-then engineering expertise to that problem.
If-then knowledge is like a bunch of parts or tools which you have available. In that sense expertise is like parts off of the shelf. Your expertise is a tool-kit, if you like, full of useful parts to help you construct a problem solution.
But these are tools which are all in your head, though. Your responsibility to use them well includes knowing how well you know things, how secure and reliable your expertise is. How good is your toolkit?
Being sure about your toolkit means reflecting on what you know and how well you know it. And that's not an easy thing to do. One needs questions to ask, concepts to think about, and cases to compare with.
Which, of course, is what this course is about.
To sum up, the important link explained in this quad is that expertise is like a part off of the shelf because of the responsibility that both require.
9.1 Introduction
As explained in the text, the Grand Challenges --- capital G, captial C, Grand Challengs; the official, as designated by the NAE, Grand Challenges --- are a specific list of problems that ought to be addressed by engineers in the coming decades. This is according to the NAE.
We're interested in a more general character of these problems, or of problems like these. We can call these the small 'g', small 'c' grand challenges.
In this quad we're going to argue that these are problems unlike any ever faced by humanity. And because of that, the skills which it will take to solve them are going to be different.
Or, at least, those skills will be put to the test in unprecedented ways, in their scope and complexity, their integration. And the consequences of not solving these problems are potentially far worse than problems we have faced as a species.
The good news is that engineers, with the proper set of skills, have a very good chance of meeting these challenges.
So in this quad, we want to come to understand what makes these problems unique, what skills will be demanded because of it, and what solving these problems is going to look like, if only in a general way.
9.2 The grand challenges are global scale existential threats.
Examples of the grand challenges we're talking about are climate change, global security, energy and resource shortages, pollution, overcrowding.
Notice that it's the last of these challenges that's largely the source of the other problems (and others not explicitly listed.) In my lifetime the population of the planet has doubled. It will do so in your lifetimes, probably twice. Population growth is exponential.
And of that population, more and more are consuming first-world levels of the planets resources: fossil fuels, inhabitable or arable land, fresh water, clean air.
Competition for those resources is going to lead to conflicts. If not outright physical conflict, at least conflicts among values and interests, access and distribution.
There is no telling what the limits are to the consequences of not solving these problems, or the consequences of potential conflicts.
So this is the first point: these problems, if unsolved, have a significant chance of threatening the continued existence of our species. These problems are what we can call existential threats.
This is largely because of their scale. They are global scale problems.
They are global scale in their impact: world climate, world resources, world security.
But they are also global scale in a second sense. Everyone on the planet is a stakeholder in these problems, and in any solution proposed for these problems.
And this is the second point. Since stakeholders are the source of non-technical constraints, solving these problems is going to go far beyond just technical engineering. They cannot be solved without technical expertise and ingenuity. But, as technical problems go, technically possible solutions might not be hard to find.
What will be most difficult is finding those solutions which also manage to satisfy the non-technical constraints in a way which is fair, best, equitable, just, acceptable to as many of the stakeholders as possible.
Significant technical expertise is going to be required, but equally, if not more so, non-technical expertise will be required as well.
Top of Form
9.3 Global scale problem-solving is unprecedented.
The next claim, or premise, of the argument being made in this quad is that the grand challenges are unlike any in human history. To properly justify such a claim would require alot more time and details than we can afford.
On other other hand, the claim isn't implausible, if we accept the other features ascribed to the grand challenges: namely, that they pose an existential threat to our species, and that they require global scale solutions. There is very little else we can point to in history that has both of those features. The threat of nuclear war during the Cold War era posed an existential threat, but preventing it really came down to the actions of the governments and militairies of the two super-powers. The world wars, I and II, were very nearly global scale, in their effect and in the scope of their stakeholders, but never really presented an existential threat. (And now we have the global pandemic --- not quite existential, but very much global in scope.)
The other way to see the point is to consider the causes of these problems. We are at unprecedented levels of industrialization and population size. Therefore, any problems that result from those two factors will also be unprecedented. The kinds of problems we're talking about might have happened before --- pollution, overpopulation, environmental degradation, resource shortages --- but never at a global level. We simply haven't been capable of it before.
The important overall point is that the scale of these problems means that everyone on the planet is a stakeholder. Everyone on the planet is affected by these problems, and everyone on the planet will be affected by the solutions.
Since these problems are unprecedented, the type of problem-solver they require, and the skills those problem solvers will need, are also unprecedented.
In the next part of this quad we'll say a bit about what those skills are. This will set us up for the argument of the final quad in this unit, the one about the Engineering Advantage.
Bottom of Form
9.4 Solving global scale problems requires unique skills.
The point here is straightforward. The grand challenges are unique, unprecedented problems, because they are global scale. The scale is the reason unique skills are needed.
Global scale problems will present technical challenges. Even local solutions will have to take in to account world wide repercussions. This will impose severe technical constraints on which solutions will work. Mostly because the systems (the environment, world energy, world food supply) are large and complex. Understanding the technicalities, and identifying the technical constraints will require enormous teams of problem solvers.
The huge number of stakeholders also means that the non-technical constraints are hugely important, and probably also enormously complex. Acting in a way which emphasizes the values of one group is likely to cause other groups to react to protect their interests. Those actions will in turn interfere with the effectiveness of the original decisions. This will all be mediated by politics, economics, international law, local laws, social forces and trends. Understanding all of these entities, activities, and interactions will, again, require enormous teams of expert problem-solvers, with a range of expertises.
The uphsot is going to be that the kinds of problem-solvers needed, and the skills required, to address the grand challenges, are both narrow and collaborative.
The most effective problem solvers in coming generations will be those with a strong grasp of the technical possibilities available, who can also understand and communicate how the possibilities fit in with the non-technical constraints.
As we've said throughout the first unit, engineering problems always face a mix of technical and non-technical constraints. The grand challenges are just extreme examples of the kinds of problems engineers already have to solve.
This will be the point of the next quad: Engineers have an advantage in solving the grand challenges.
