This week’s papers give me the feeling that the authors emphasized more on the uncertainty and ambiguity of engineering, rather than our usual sense of accuracy and rigorousness. However, our group agreed at the end of the discussion that accuracy and rigorousness are actually addressed in the papers and still are the base of engineering.
Jonassen et al. mainly talked about the differences of workplace engineering problems and in-class engineering problems. These differences are present in the structure, goal, standard, solving ways, team members of engineering problems. However, the differences do not present in theory base of design or the details of problem solving. Also, the accuracy and rigorousness can be seen from the argument. Theme 2 involves ill-structured problems including aggregates of well-structured problems.
Koen talked about the characteristics of an engineering problem: change, resources, best, and uncertainty. He also mentioned that uncertainty can be seen in the former three characteristics. However, for example, the curves in the “Sharpness vs. knob setting” and “Fidelity vs. knob setting” are not randomly drawn by an engineer. They are summarized using statistic methods. So, although making a decision in engineering designing is based on a lot of other criterion, evidence and theory base of engineering designing are accurate and rigorous.
Bucciarelli argued that engineers need to select from different theoretical framework to design or solve problems. However, these theoretical frameworks are well-defined. No one wants to drive a car that is designed not based on any theories or experimental data.
Showing posts with label Bucciarelli. Show all posts
Showing posts with label Bucciarelli. Show all posts
Sunday, October 4, 2009
Saturday, October 3, 2009
What is engineering? What is not engineering?
I agree with Noah that engineering should be defined more uniquely. When I need to strictly define the scope of X, I expect the definition to be so clear and unambiguous that everything in the world should either inside or outside X. No exception. So far, I don't think I can define engineering in this way.
"Is drawing engineering?" As raised by Sensen in class, I was also confused by such a question. But according to Koen's argument, engineering method is the strategy for causing the best change in a poorly understood situation within the available resources. Light changes. Fixed-size canvas. Artists try their best. The model may not pose the same all the time. Drawing shows all characteristics of engineering: change, resource, best and uncertainty. From my perspective, however, these four criteria serve as evidences rather than determinants to judge whether Y belongs to engineering. Koen may agree with me because he described these four words as characteristics of an engineering problem. Having Taken Bucciarelli's argument about social components of engineering, I am still not able to define engineering precisely. Do we really have such a definition?
Another question confusing me is that in Jonassen's paper, I lost connections between 12 themes and 6 implications for engineering educators. How can those 12 be matched to the 6 improvements?
"Is drawing engineering?" As raised by Sensen in class, I was also confused by such a question. But according to Koen's argument, engineering method is the strategy for causing the best change in a poorly understood situation within the available resources. Light changes. Fixed-size canvas. Artists try their best. The model may not pose the same all the time. Drawing shows all characteristics of engineering: change, resource, best and uncertainty. From my perspective, however, these four criteria serve as evidences rather than determinants to judge whether Y belongs to engineering. Koen may agree with me because he described these four words as characteristics of an engineering problem. Having Taken Bucciarelli's argument about social components of engineering, I am still not able to define engineering precisely. Do we really have such a definition?
Another question confusing me is that in Jonassen's paper, I lost connections between 12 themes and 6 implications for engineering educators. How can those 12 be matched to the 6 improvements?
Jonassen, Koen, and Bucciarelli
[This post belong to last week's reading: Jonassen et al., Koen, and Bucciarelli)
Jonassen, Strobel, and Lee
Ill-structured problems are those found in engineering workplace, as contrasted with the well-defined problems that engineering students find in classrooms. Seven main categories were defined from the qualitative analysis of the interviews with active engineers. Each category describes common problems, recommendations, or typical daily experiences engineers encounter in the workplace.
It's the first time I stumble into the concept of "ill-structured problems", so it is implied that classroom problems are "healthy-structured problems". As I would say, classroom problems are "organically-grown, gluten-free, and low-fat" with minor "bugs", compared to workplace problems.
If future engineers need to develop good team relationship skills, then, we should encourage them to take more practical psychology-type of seminars and workshops; in addition to encouraging them to be less isolated and more involved in team-work. One thing I used to hear of my classmates (including myself) was: "I prefer to work alone. Team work is so complex". Engineering schools should actively keep addressing that students' difficulty, to make the transition to workplace the smoothest possible.
The three articles stated that engineering problems are also composed of traditional "non-engineering factors"; such as empathy, motivation, good relationships, effective communication, collaboration, compassion, value of diversity, etc. (I added other items to the list). I remember that in the Software Engineering classes, professors barely taught about the "non-engineering issues". They focused in the traditional issues of complying to government agencies, laws and policies, privacy issues, how to organize the project based in a software development life-cycle model, keeping track of the budget, project phases, etc... As if engineers had only a "binary machine" in their minds, without a human component.
[...I'll cut here...]
///////////////////////////////////////////////////////
Jonassen, Strobel, and Lee
Ill-structured problems are those found in engineering workplace, as contrasted with the well-defined problems that engineering students find in classrooms. Seven main categories were defined from the qualitative analysis of the interviews with active engineers. Each category describes common problems, recommendations, or typical daily experiences engineers encounter in the workplace.
It's the first time I stumble into the concept of "ill-structured problems", so it is implied that classroom problems are "healthy-structured problems". As I would say, classroom problems are "organically-grown, gluten-free, and low-fat" with minor "bugs", compared to workplace problems.
If future engineers need to develop good team relationship skills, then, we should encourage them to take more practical psychology-type of seminars and workshops; in addition to encouraging them to be less isolated and more involved in team-work. One thing I used to hear of my classmates (including myself) was: "I prefer to work alone. Team work is so complex". Engineering schools should actively keep addressing that students' difficulty, to make the transition to workplace the smoothest possible.
The three articles stated that engineering problems are also composed of traditional "non-engineering factors"; such as empathy, motivation, good relationships, effective communication, collaboration, compassion, value of diversity, etc. (I added other items to the list). I remember that in the Software Engineering classes, professors barely taught about the "non-engineering issues". They focused in the traditional issues of complying to government agencies, laws and policies, privacy issues, how to organize the project based in a software development life-cycle model, keeping track of the budget, project phases, etc... As if engineers had only a "binary machine" in their minds, without a human component.
[...I'll cut here...]
//--//--//--//--//--//--//--//--//
Koen
I agree with Koen in his statement that "engineers cause change" (p.11) and that it's "not just any change, but the best change (...)" (p.10). However there are some things I would like to bring to surface here. I found somewhat disgusting the author's example of "the prince who wants the divorce of his daughter" as part of the examples of what is "correctly called an engineer because (...). Each wants to change, to modify, or to convert the world represented by one state into a world represented by a different one" (p. 10). Is this "engineer" taking in count the freedom and decision of the other human being? Just because you are changing from state A to state B, and you are taking in count the "best change within the available resources" (p. 10), that doesn't make you an engineer. You must have an ethical and benevolent component for humanity (or the other fellow being).
If we choose a real example instead of the prince example, Adolf Hitler wanted to change a whole society for what he thought it was the "best", following a certain race-hate theory; but we ought not consider that to be an "engineering act", because to be an engineer is not to be a creator of instability, malady, unfavorable causes to humanity (or to another individual).
[.. I'll cut here because if I keep going, I'll end-up writing more than what it's needed for this post...]
The other concept discussed by Koen was the idea of "the best", that is currently linked with the idea of what is optimum, within the engineering-mathematical level. In engineering, the optimum level is defined by calculus and mathematical formulas; however, for example, a computer with less optimization, defined in one society, may be defined as "optimum" in a society without the resources to acquire the "most advanced" technology (here I am sticking this to my context of Computer Eng.).
Bucciarelli
Of Bucciarelli's article, I wish to bring his emphasis in the importance to know the distinction between engineering and science. Both terms are used interchangeably. Scientists, as the author stated, work within a small, ordered, and well-defined context. The variables that an engineering problem have, come from different areas, away from the traditional perimeters of the technical-mathematics realm.
I did also like his explanation of failure as a "social construct" (p. 25). For an event to be labeled as a 'failure', the "beliefs, judgments, and claims of persons concerned with the event (...)" (p.25) construct it as such.
I agree with Koen in his statement that "engineers cause change" (p.11) and that it's "not just any change, but the best change (...)" (p.10). However there are some things I would like to bring to surface here. I found somewhat disgusting the author's example of "the prince who wants the divorce of his daughter" as part of the examples of what is "correctly called an engineer because (...). Each wants to change, to modify, or to convert the world represented by one state into a world represented by a different one" (p. 10). Is this "engineer" taking in count the freedom and decision of the other human being? Just because you are changing from state A to state B, and you are taking in count the "best change within the available resources" (p. 10), that doesn't make you an engineer. You must have an ethical and benevolent component for humanity (or the other fellow being).
If we choose a real example instead of the prince example, Adolf Hitler wanted to change a whole society for what he thought it was the "best", following a certain race-hate theory; but we ought not consider that to be an "engineering act", because to be an engineer is not to be a creator of instability, malady, unfavorable causes to humanity (or to another individual).
[.. I'll cut here because if I keep going, I'll end-up writing more than what it's needed for this post...]
The other concept discussed by Koen was the idea of "the best", that is currently linked with the idea of what is optimum, within the engineering-mathematical level. In engineering, the optimum level is defined by calculus and mathematical formulas; however, for example, a computer with less optimization, defined in one society, may be defined as "optimum" in a society without the resources to acquire the "most advanced" technology (here I am sticking this to my context of Computer Eng.).
//--//--//--//--//--//--//--//--//
Bucciarelli
Of Bucciarelli's article, I wish to bring his emphasis in the importance to know the distinction between engineering and science. Both terms are used interchangeably. Scientists, as the author stated, work within a small, ordered, and well-defined context. The variables that an engineering problem have, come from different areas, away from the traditional perimeters of the technical-mathematics realm.
I did also like his explanation of failure as a "social construct" (p. 25). For an event to be labeled as a 'failure', the "beliefs, judgments, and claims of persons concerned with the event (...)" (p.25) construct it as such.
Subscribe to:
Posts (Atom)
Posts
