Missing mental screws

Peace of mind isn't at all superficial to technical work. It's the whole thing.

Whenever I read Zen and the Art of Motorcycle Maintenance, it makes me want to study philosophy so I can better understand and critically evaluate the thought structure Pirsig lays out (the Metaphysics of Quality school of thought). The same thing that drives me to track down Euclid after reading Flatland, or search for more background information on almost every sidenote from T.S. Eliot's The Wasteland. Letting things rest unquestioned has never been a talent of mine. I have to consciously put things down, step back, and say "I'm going to be okay not understanding evvvvvvvvvverything about this right now." Otherwise I'd just keep following random intellectual threads and tangents, and I would be happy but not content because I wouldn't actually focus enough to get something concrete done.

Sometimes I don't say "stop" in time. I want to call that time fully worthwhile, as it's time spent learning interesting things, but the truth is that it often gets in the way of me completing the things I actually have to get done. I want to do everything, and I also want to have free time to wander... well, everything else.

It's a tragic combination of a sense of responsibility towards the whole world that makes it very difficult for me not to commit to things, an optimistic "hey, we can do that, it's not too bad" underestimation habit, and a perfectionist streak that wants to go overboard on... if not eating or sleeping, the vast majority of other things I do. All three are fantastic qualities that have gotten me to a lot of great places, and the perfectionism-random-wandering in particular is part of what I think makes me want to be an academic (intellectual exploration, yay!) and also why I worry about my ability to be one; sitting down and concentrating on something is not what I'm good at, to put it mildly. I can get lost in what I'm doing, but haven't learned how to have that kind of focus on command - it tends to just happen, and tends to happen a lot with things that aren't work.

Sometimes I wish I could just not sign up for anything for a semester, start playing with random things, and let my professors know a month or two in "hey, I... inadvertently ended up being completely obsessed with fractal mathematics this term, can I retroactively put that on my transcript? Look, computer simulations I've written!"

It feels like the different parts of my brain are wild horses that I have to continually keep in check - but which keep on charging forward, pulling me onwards in this glorious chaotic rush. Barely contained. Life is kind of like that; your greatest strengths are also your greatest weaknesses. They're the tiny things that keep you from exploding into greatness. It's like having a machine with a couple screws loose, or stuck, or out...

Right now this screw is worth exactly the selling price of the whole motorcycle, because the motorcycle is actually valueless until you get the screw out. With this reevaluation of the screw comes a willingness to expand your knowledge of it. --Zen and the Art of Motorcycle Maintenance

Communication/Learning Analogy Visuals

I just wanted to toss up a visual representation or two. I tried putting them in the post, but the resolution was atrocious. Instead I put a simple scenario here and a more complex one with a couple of bits being transferred at the same time here. This is nothing brilliant but I'd made the pictures while explaining some of Meta to a friend and thought I might as well put them here. Enjoy!

Graphical description of systems problems

http://www.idiagram.com/CP/cpprocess.html

Mouse-over the text at the top right that says "kinds of problems" and you'll have another perspective on the "what is systems engineering?" debate. Also see Wicked Problems.

That is all.

Communications: the aftermath in Mel's brain

(Note to self: someday, write notes about the end of systems, and about diversity. Carrying on...)

In approximately 45 minutes, Raymond Yim managed to completely metastasize - and I use that word in a positive sense because it was a HAPPY MIND BLOWING VIRUS OF UNDERSTANDING - all six of our minds. We started laughing in recognition halfway through the lecture and couldn't stop. I think we're going to have to go back and explain to him why we were laughing. Hopefully it wasn't to confusing.

He managed to, without knowing it, touch on every single point, every single class, assignment, lecture, EVERYTHING - we had covered with three other professors in three separate modules during the first half of the semester. Everything. On top of it, I was laughing because last semester's Analog and Digital Communications stuff suddenly snapped into focus (not perfect clear focus, but it was definitely a large discontinuous jump towards better understanding) - and beside me, Chandra was scribbling notes down about how to apply this to her AHS capstone - and I can only guess at what the other four were thinking, but I'm going to be observing Marco and Andy tomorrow morning for my anthropology homework and will be doubling that up by observing their transactions from the standpoint of a peer-to-peer communication channel.

Some terms from Diversity, badly mangled

• epistemic privelege - a receiver that compensates for a lousy channel can appreciate "how much better" it is with a good one, and cope with a good channel.
• stereotype threat and lift - when transmitting to multiple receivers, you can have a scheme that selectively transmits to the antennaes you "think" will do better... so of course they will do better.
  
• admissions criteria and affirmative action - you're going to transmit a certain type of message at your college, you need to get the right kind of receivers so you maximize your throughput.
  
• class strata - incompatible communications schemes, like having an FM system trying to pick up an AM signal.
  

Some ideas from information fluency, similarly mangled

• Understanding the system of how people decode and deal with a diversity of sources is an information fluency skill. (Heck, that gets all of them.)
• Moving along the information-to-knowledge spectrum in the pedagogy domain could be facilitated by using engineering concepts to convey pedagogical techniques to engineers.

Definitely one of the most enlightening hours I've ever spent in a classroom. In fact, class excited me so much that I went to the library to read and type about communications because I was just so worked up about it and didn't want to lose momentum. Figured I'd be there for maybe 15 minutes before the steam ran out, would just be a little late to class. Nope. I was in there for three hours. I was learning stuff the entire time.

Okay, so I ended up roaming far, far away from communications (somewhere in the middle of fluid dynamics which turned into chemistry which turned into a dinnertime discussion about low-pass filters which - come to think of it, actually brought me back around into communications) but wow that was good. Once the walls between systems, diversity, information fluency, and communications crumbled, it was like no disciplinary walls existed whatsoever for an afternoon and I just ran around and learned stuff and it was... felt... so... good. Instead of jumping spasmodically between my projection spaces for various disciplines as I switched gears, one sort of morphed slowly into another so that I was understanding things the entire time. This. was. weird.

Alas, this feeling is very much not conducive towards getting homework done, which is what I have to do now. Nap first, though. Nap, then work, and then someday I can tackle the long list of things I now want to learn as a result of this afternoon. Ye gods.

MetaOlin's MetaLecture

Today's lecture was absolutely fantastic. I cannot remember when the last time I was so thoroughly happy/content/excited was -- incredible.

Ray's lecture was the first time that I thought Meta really lived up to it's promise. The idea of using different mental models is great, but our goal lies largely in the overlap between them. Systems was broad enough that we could fit other modules into it; however, the way that communications was presented allowed us to use it as a paradigm on the same level as our other modules that had incredible overlaps with them instead of as a framework that the other modules fit within. The part of the lecture I found most appealing was that it even ended up having significant overlap with itself. The lecture itself represented a great deal of what Ray was talking about -- it was truly a MetaLecture.

I'm really excited about keeping track of how I learn. All this semester I've been keeping track of the time I spend on each class, and I think adding how I'm spending time on learning (as well as how effective that time is at turning information into working knowledge) will be a great source of insight. So cool.

btw- this post gets to be MetaMetaMetaLecture (post,olin,lecture). Teehee!

The spiral on steroids

WOW. Raymond's lecture on communications networks and their application to the diverse Olin system completely blew my mind. The communications analogy to understanding the college is very well thought out and capable of being expanded, which will be highly motivating in the next two weeks as we talk more about it and look to create a useful deliverable. But the cool part of the lecture was the way it tied together EVERYTHING we had worked on in Meta this semester. I don't know how Raymond managed to do it, especially since he knew little about what we worked on in previous modules. Our original model of Olin as a complex system was very relevant in connecting student and professor nodes and modeling their information flow. The concept of diminishing returns with increased energy mirrored the focus of our deliverable on burnout. The idea of fading also connected to the diminishing returns of information (I) when there is little sleep (P). Our second module of diversity took a number of different views at why people do different things and learn differently based on physical characteristics and family background, as well as how people interact differently to shun or be overly inviting to these people. This can be easily applied to how people project different meanings of the same thing onto their own type of understanding. This diversity of people can also complicate teaching a group, and the 80-20 law may mean that only 20% of a lesson is useful for one person, but a different 20% may be useful for someone else. This is why a good prof will try to use lots of different ways to teach the same thing, hoping that everyone will understand it in at least one way. Then comes the information literacy minimodule, where we learn how people find information. This can also be applied to many parts of the information transfer and what "antennas" people use to learn.
This was lecture was one of the most amazing hours of my life. I was shaking with excitement when I walked out. Wow.

Quick Recap

So I wanted to get a post in before we started another module; we've already been through three and we only have Mel's thoughts here at the moment.

Systems
I learned a lot from this module. The idea of every complex thing being a system with stocks, flows, feedback and delay is simple and powerful. It feels like one of those ideas that has a huge number of levels of understanding one can reach about it (like, for example, a derivative). At a simple level it's Gill's ever-present bathtub analogy. But the water analogy can't handle the multitude of inputs involved in real-world systems like oil exploration or even something small like Olin. The other big lesson from this module was about working. All of us spent a huge amount of time coming up with a model that we felt could represent everything we wanted a simple model to represent about Olin. At the end of a grueling paper-writing process, I believe we came up with and had a basic understanding of a model that did just that; however, our ability to convey that knowledge was terrifically bad. We ended up having little time to write and even less time to edit; it was a disaster. Oh well. That'll teach us to keep on having our little thinking sessions instead of getting tangible work done.

Diversity
This module was really intellectually stimulating. Our discussions in class were fantastic. The readings were interesting and provided us with both the vocabulary and background to have intelligent discussion, but it was really the discussions that I found compelling. The only times I would leave the conference room were when I had class immediately afterwards. Reluctantly. There's something fantastically refreshing about hearing views that you do not normally have accessible. The most impressive views from my standpoint were our ladies'. Mel, Chandra and Zhenya pointed out a number of times when they felt they were treated differently because of their gender. There are societal expectations. They are rooted so deeply that I doubt a reasonably quick change is plausible; one experiment showed that when people were shown pictures of men and women and asked to estimate heights the males would show up as being taller than females of the same height. So much cool stuff! Anyways, the autobiographies and then our 'what if...' autobiographies were all incredibly interesting.

Information Literacy
The thing I got most out of this class was a single phrase. This is that information literacy is about "moving information along the spectrum to knowledge." This insight taps into the fact that we are rapidly reaching a state were information is nearly infinite. We, as mere humans, cannot possibly keep up with the increase in information generation. We must be adaptive and we must constantly learn.

Anyhow, I'm really excited about the upcoming communications module... after all Raymond already had some cool ideas in this realm even before we talked with him.

Side effects (Here Be Dragons) and the Hubble

In the olden days before satellite imagery overlaid with Google Maps, cartographers had a rough job. They were supposed to draw an accurate reference from sketchy, incomplete information. While they did the best they could, there were always unexplored areas they couldn't know about. Since blank areas on maps don't inspire confidence (or sales), they filled them in with lovely renderings of horrific sea creatures. "Here be dragons." Of course we haven't explored here, they said. We know it's dangerous.

This didn't particularly encourage future explorers to venture there, either. If the mapmakers said there were dragons, well - there were dragons. You weren't supposed to go outside the known boundaries; you'd fall off the edges of the world.

However, when you fall of the edges of your world, you usually fall into a new (and larger) one. Take that metaphor and spin it around into systems thinking today. Instead of here be dragons, we have the much subtler factors beyond our control or even unexplained side effects. Can't do anything about dragons; they're just there, and if something flies into their realm, best let it go. We've roamed outside the known boundaries of our field.

Much has been said about the need to de-silo the working world. The words "interdisciplinary collaboration" are usually followed by the buzzword "innovation" somewhere. Executive books and management tomes (even engineering management tomes) are sprinkled with vague aphorisms like "listen to customer feedback" and "have a clear chain of accountability." The case study of the Hubble telescope, while impressive and clearly written, has one major flaw. It has no stories. As Boris said, "I agree with everything [the Hubble case study] said, but it doesn't help me."

It's like saying here be dragons, followed by instructions to be cautious around dragons and avoid getting your ship sunk by dragons. What we need are more specific stories: "...and there was the one time we found this beast of a dragon, purple wings and scaly tales, who flew in from the sky to attack our boat... except Jorge discovered they were vulnerable along the underside of their wings..." If a purple dragon is ramming at your ship, you want to know how people have gotten rid of them in the past, not that you "should avoid purple dragons."

Then there's dragon practice. As Andy said, "the more you can build complex projects that don't matter, the better. Maybe when you run a million-dollar project, then you won't mess up." (He was referring primarily to POE class, which is notorious as a learning experience in systems project failure - individual parts will work, but the whole will not.)

Me? I think the Hubble did a reasonable job of recognizing their dragons post-mortem. I'm impressed the Hubble worked in the first place. Precision parts and pre-internet distributed design? No matter how you slice it, that's a tall order, and they managed to pull it off.

What's the system of systems?

Part of the discipline of systems engineering is quantifying the inherently unquantifiable. By abstracting the fuzzy messiness, you turn it into non-fuzzy clean-ness (or so you hope), but you also drop a lot of information in the process. That's why Brian says that all models are false. They are. I tried making a model of the information flow between profs, NINJAs, and students for the ECS class. It was terrible. I thought I could describe the basic interactions, but I ended up going "but I can't put that in if I put that in!" until I conceded that Brian was right.


So I asked him what the system of systems was, since systems engineering is itself an engineering system, fulfilling the standards (by one route of defining it) by being complex, large-scale, interdisciplinary, and an open system. The recursive meta-ness elicited groans from Chris. We tossed around ideas for a while, landing on George's definition of systems engineering as an inherently dynamic discipline because it grouped previously complex technologies into simple systems.

For instance, the making of steel... becomes part of the system of a ball bearing... which can be used on the shaft of a car... that gets sensors bolted on to run the DARPA grand challenge. Each advance in technology depends on the previous generation's technology becoming "common" enough to be used as a component. It's almost fractal-like complexity with boxes within boxes within boxes, only spiraling outwards and forward in time. At this, Chandra got to the board and drew this diagram, which USAF Maj. Dan Ward had presented to the seniors last week. It's called the Simplicity Cycle, and it describes product development.




The oversimplified version is that projects start simplistic (R1) with very little information, balloon up into complexity (R2), and then either blow up into complicatedness (R3) or find ways to turn that complexity into a new, richer kind of simpleness. Systems engineering, Chandra said, does exactly that; turn complex things into simple ones. And they're aided by the flow of time, which tends to push things from simple (R4) to simplistically obvious (R1), allowing engineers to use them as subcomponents in new and more complicated (but eventually simple) things.

At this point, someone (Boris, I think) said "It's like UOCD!" And indeed it is. If you flatten out the path that goes from R1 to R2 to R4, you get this, which is pretty funky.

RC planes vs Air traffic control

Brian had us do two quickie systems exercises. First we had to find a motor for an RC plane, then we had to design an air traffic control (ATC) system, and we got 5 minutes for each round. "You won't finish," he said. We didn't. But we learned a few things.

First, there are a range of systems engineering problems. The RC plane involved a lot of physical constraints (due to the laws of thermodynamics, electromagnetism, and that sort of stuff). It was easy to quantitize and optimize even if we had to make decisions about tradeoffs between the electrical, mechanical, and thermal systems. The ATC wasn't was fuzzier, "designer-y", and harder to defend our answers because there wasn't an universal understanding of what was "good." In fact, one of the main characteristics of systems that I'm finding is that the "right answer" is very dependent on your definition of the problem, moreso than other fields I've experienced.

Secondly, it was amusing to compare different approaches to the same problem (we worked in pairs). For instance, Chris and Andy drew diagrams for the RC plane problem that reminded me of the minimax theorem and linear optimization in game theory (...er, among other things). Very pictorial, more holistic and simultaneously mathematical.



In contrast, Marco and I went to the board and started listing out criteria for the ATC. We would have gone on to do a flowchart of decisions if we hadn't run out of time. More sequential and linear, broken into subcomponents, in written format, and... almost programmatic.


The RC plane, Brian said, was more characteristic of traditional engineering education. Mm, math, optimize. The ATC was more Olin-ish, although we still do a lot of RC plane stuff. "And the ATC was more exciting," Boris pointed out, "because it has the potential to save lots of lives, whereas a toy plane..." However, even as the world moves towards systems problems, engineering education still remains behind to work on traditional engineering ones.

That's okay. After all, you need to learn addition before you get into ring theory or Gauss-Jacobi sums. We're always going to need the RC plane optimizers, but now we need the ATC ones too.

Last semester's responses: What is systems engineering?

I read the other papers (just beacuse) and tried to summarize them as best I could. If any of the paper authors are reading this post, I apologize for the butchery... it's hard to summarize an emerging field in a 3-page-paper, and even worse to squeeze it into 1-2 sentences.

Zach Brock: As a new discipline, it's hard to tell what systems engineering is; is there a "calculus" that systems engineers can be taught, or is it a collection of skills you're inherently good or bad at?

Luis Diego Cabezas: Systems engineers are the ones working on the project at the highest level of abstraction. We've traditionally taken "systems engineers" from other engineering disciplines, but we need to start training systems engineers in their own discipline from the start.

Cathy Murphie: Systems engineering is a black box; you don't know what goes on inside it, but what comes out of it is a solution that balances processes and people to satisfy both external (design requirements, environmental factors) and internal (inexperienced project team members, too-small budgets, short schedules) constraints. The toolbox of a systems engineer is lifelong learning.

Mark Penner: Systems engineering uses a top-down perspective to focus on the interfaces between components in order to make the whole more efficient.

Mike Siripong: The "universal" toolbox of systems is organizational management; gannt charts, system diagrams, etc because specific technical tools vary wildly from system to system. Systems engineers have a big picture perspective that lets them lead projects, especially in interdisciplinary debugging.

Matt Tesch: Systems engineers allow their teammates to specialize in their fields by taking over the "big picture" problems and facilitating communication and interfacing between specialty groups when appropriate.

Dan Rice: Systems engineering is the coordination of all the components of a system, and its "calculus" is high-level thinking; feedback loops, mathematical models, and other tools that will mature along with the field. Since systems engineers need to see the big picture, it makes sense to let them roam outside the traditional hierarchy so they have the freedom to do that, and for them to have "people skills" so they can work with many different groups at once.

Lee Edwards: Systems engineering is the interdisciplinary study of interactions of two or more technical components in order to solve human problems.

George Jemmott: The engineering of modern technical systems

We were asked to read at least one of the papers on "What is systems engineering?" written by the students in last semester's Systems class and give a brief summary and commentary. This is my take on George Jemmott's, which I mostly agree with.

Systems engineering is not fuzzy, nor is it all "people skills," nor is it management. It's engineering.

Since systems are complex arrangements of subsystems, all technologically assisted actions constitute systems. Since the subsystems will change as technologies and the cultures they exist within progress, the exact technical definition of a system can't be pinned down to specific disciplines, tools, or even mental models to some extent.

Systems engineering involves understanding, creating, maintaining, and otherwise working with these evolving complex technical systems. You can understand a system when you understand its subcomponents, either through prior direct experience or rapid learning facilitated by indirect experience, so systems engineers typically have plenty of years logged in a variety of different things.

Systems Engineering Start

This is a blog for my notes on the MetaOlin independent study that six of us are doing in Fall 2006. We will be looking at Olin from a bunch of different perspectives, our first module being Systems Engineering (for the "10k feet up" view, as Brian Bingham said). Brian gave us some readings to kick things off.

Robert W. Lucky, Bozos on the Bus (IEEE Spectrum, 1996)

One sentence summary: We're blindly wandering in the dark and have no idea of what's coming ahead... but neither does anyone else, and this levels the playing field.

Question: Is the advantage in the new world system (whatever the heck that means) and the creation of new systems (products, etc.) skewed towards the young? Since young people tend to be much more used to "being bozos" on account of not knowing enough to be much of anything else, we're apt to adapt better to a world where everyone's thrown into bozo-hood, much like being blind during a nighttime power outage. I have a hard time believing this; experience and the wisdom of years is usually transferrable to different situations.

Daniel Hastings, The Future of Engineering Systems: Development of Engineering Leaders

Summary: Systems are all around us - education, healthcare, government, etc. These systems are becoming increasingly technologically enabled (telecommunications, the internet...), but most engineers haven't learned how to work with systems of this magnitude that also interact with nontechnical, more sociological things. Since there are many possible views of the same complex system, Systems engineers have to be able to synthesize many different perspectives at once.

Systems engineering typically focuses on things with the following properties

• Technologically enabled - there are components that require solid engineering backgrounds.
  
• Large scale & complex - wide-reaching, far-ranging, and plenty of parts.
  
• Dynamic uncertainty - things should be changing in this system, and it should not be strictly predictable (fairly easy to get this when the system is large scale and complex).
  
• Interaction with nontechnical factors - there are people in the world, and we need to account for them.
  
• Emergent behavior - the whole is greater than the sum of its parts; some things will come out that you never predicted.
  

I was particularly fascinated by the paper's insistence that we need more rigor and mathematics and quantitative modeling!!! in systems education. It's almost as if they're trying to make sure that systems engineering is a "real" discipline, not a "fuzzy, soft thing" that "real engineers" will dismiss as hand-wavy.

This reminds me of a conversation I had with MIT anthropology professor Dr. Susan Silbey about "engineer's arrogance," which is what UOCD at Olin tries to cure. We assume that since we know about technology, and we're people, that we can make technology for people without learning about them. We don't need humanities! We just know what to make.

Anyhow, as much as I love math, I hope that systems doesn't get sucked into the "if it isn't quantitative, it isn't real engineering" trap. There are many ways to solve a problem, and numbers are only one.

The other part that I was struck by was the repeated echoes of "this discipline is not mature." That's exciting. As Lucky's paper put it, we're all bozos on this bus. Bill Strachan from IBM told me that systems engineering right now is around the same place that computer science was a generation ago - it's drawing on all these other disciplines, but it's more than the sum of their parts... in other words, systems engineering is in itself a system. It fits all the above criteria, after all.