Saturday, October 3, 2009

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...]

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.).

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.