Engineering Philosophy

Citation: Louis L. Bucciarelli (2003) Engineering Philosophy.
Internet Archive Scholar (search for fulltext): Engineering Philosophy
Download: http://www.iospress.nl/loadtop/load.php?isbn=9789040723186
Tagged: Philosophy (RSS) engineering philosophy (RSS), engineering education (RSS)

Summary

This book is one engineer's (longwinded) attempt to develop a philosophy of engineering and engineering design, examining questions like "what is design?" and "how do engineers communicate?" and "what are we doing when we 'speak' in 'engineeringese'?"

Theoretical and Practical Relevance

This book is likely best consumed as a book on tape (or as if it were one); the author is an engineer who's tried to learn and bridge to the discipline of philosophy, and ends up walking in long, slow mental circles around the terrain he's trying to describe. (Deliberately, perhaps; this is certainly a "journey" rather than a "destination" book that forces engineers reading it to stay and linger in the unknown and the discomfort instead of giving a pat answer to describe what it is they do and how they think and immediately moving on.)

Quote, p 4: "Philosophy's aim is to clarify, to analyze, to probe and explore alternate ways of seeing, of speaking, and ultimately, of remaking the world."

Engineering is spoken of as a timeless thing, but exists within a chaos of very timely things.

"Engineers are pragmatic" sounds like an excuse used by engineers to dismiss things that don't fall within their mental model.

Footnote, p 8: "That's the whole point of being skilled; you don't stop... to reflect upon what you have just accomplished or where the next note on the keyboard lies. Engineers are skilled too in different ways, but they do stop and think, and rethink, and redo and rethink as they go about designing." (This reminded me of the Dreyfuss model of skill acquisition.)

Since most engineering projects are multidisciplinary, we run into the "tower of babel" problem -- when there are so many different frameworks and representations and tools and languages, how do we move forward? One approach is breaking the problem into independent subtasks, but that isn't a perfect solution. Oftentimes we model things as independent but they're actually not. Also, if you keep breaking subtasks into subtasks into subtasks, you can go down this reducto ad absurdum path of siloization. (But that's much easier than talking with each other, because that's messy and hard.)

Bucciarelli brings up the idea of failure as a social construct. This reminds me of when I was trained as a software QA engineer; one conversation that came up was the role of emotions in bug-finding. A bug is something "hard and technical," yet how do you know to identify something as a bug? Oftentimes, it's emotional -- this is wrong, this is frustrating, this makes me sad or tired or angry. Without those flags, it's not a bug, because a bug is something someone thinks is a problem.

Bucciarelli makes a point about decoupling information from knowledge that I didn't have much time to explore, but might make interesting reading later on.

Engineering is a language, in a way; drawing engineering diagrams, writing the sort of texts engineers write, and laying down the sort of math engineers use to describe the world is a sort of encoding that makes that dialogue less accessible to people who don't know it.

Bucciarelli makes the point that engineering knowledge is geared towards the future, not the past. I'm not sure what to make of this quite yet.