Chevy Chase Snl No Math Homework


Steve Chenoweth's Home Page


Above - Open door policy in action, Jan 26, 2016. Steve awaits final of his 28 advisees for spring term, while editing this picture and considering summer academic engagements to mesh with sabbatical plans.


How will Steve's students' lives play out? What will they contribute? How can we faculty help them blossom?

What unplanned metaphors, for all that, pop into your head, as you gaze at this only slightly germane image?

The power of surprise similes Let's trace the history of Steve's Dayton back yard, using the 2006 snapshot at left, linking it analogically to his students and work at Rose-Hulman!

In the foreground, a magnolia that bloomed first, often getting frosted-out. Like students at Rose, the tree was wired to take chances, for the earlier opportunity to thrive. "I can graduate in 3 years if I overload!" Steve advises such calls.

Our younger daughter loved climbing this tree. Perching in it spurred her imagination; pre-school, she told herself stories there, shamelessly aloud. This year, she passed her prelims, in Slavic languages and literatures. Did you also have a favorite tree, from which to view the world in splendid isolation? Where is your crow's nest now?

The ash whose tall trunk is seen behind lost to the emerald ash borer in 2012 — it was old, shown full-sized on our 1939 plot plan, and it gave us majestic shade. In your career, you may say goodbye to good friends too often. Software engineers change groups, jobs and locations. Even if you don't, they will. Can you plan a social life around that?

Our whole lower-level grove, constantly evolving, shields the view of those nearby homes for half of each year. No grass cutting needed, as well! Time has told: Partial cover's good-enough seclusion without adding risk. It's an inner-city neighborhood, but we've had just one break-in, over 33 years. How's your sense of privacy and security, as a young adult? What is "good enough"?


Hot topics

How does this page point to other resources, as well as ways to use itself?

Standalone Online Graduate Courses: We now have two online courses we'd be happy to teach "anywhere" — Software Project Management and Software Architecture. Contact Steve for details!

MSSE Program: Link to Rose-Hulman's Masters of Science in Software Engineering (MSSE) program is here. And a sample course, his Software Design course, is here; it's typically taught winter term.

Service Learning: Steve's funnest involvement — Service Learning. Click here for the ppt presentation.

Creativity: For brainstorming methods Steve's used a lot, and how to try them out, see here!

Improving Student Learning: See some of the sections below, under Special Interests and Preferences. Like Teaching observation, Making change, and, of course, Trendy stuff.

Engineering project ethics: See the slide set, designed to stimulate discussion, here.

Architecture reviews: Another great way to learn more regarding the goodness of a design by getting more points of view about it. (Adds to our growing list, like Agile customer involvement, code reviews, interaction design studies, and DevOps.) See ppt intro here.

General Ideas to Share: Most of the content in on this page is intended to be informal thoughts on engineering education, which most readers will identify with. The mix of serious, whimsical, and biographical topics is intentional — in an essay tradition dating back to the 16th Century. The opening section on "Philosophy in motion?" sketches the rationale a bit more, as well as kicking business off with one sweeping proposal for Steve's students.

Possible research questions, that Steve's curious over, are marked with ??, so just search the page for that, to see if you share any of his special interests! There are like 40 to choose from.

Is this your project in action? It's the next to last attempt at manned powered flight, Oct 7, 1903. before the Wright brothers did it for real. Designed by academics, based on solid calculations and experimentation. What you see is the good part. They fished the pilot out of the Potomac River.25 Then again in December. The Smithsonian Institute had backed the project, and it gave them and the inventor, Samuel P Langley, a bad name. The Institute tried to rewrite history, declaring victory until 1942. Are egos involved in engineering, or what?

Like this image of the test flight, undergrad engineering projects only present enough to declare initial success. After all, you exercised the underlying principles. If the professor smiles, at this point, you earned an "A." Even senior design experiences tend toward prototypes. Our mutual growth path is to work beyond that, though it's harder on everybody. We should keep the current achievement claims modest, in the meantime, with expectations for that maturation.

Note: Throughout this web site, Steve uses images like the above, taken from the Internet. This is intended to fall under Sec 107 of US Copyright law, the "Fair Use" section. Steve's intent is specifically for "criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research," and he is part of a non-profit educaitonal organization. If you feel, nevertheless, that an image infringes on your copyright or other IP, please let Steve know, and he'll happily remove it! Steve recorded the links where the images came from, clickable in the captions for the images, as above.


Where to find him?

A history of Steve's Rose offices, with the final one being where he actually is...

Double change of venue! At left, this was his old office: F-220 (Top floor, back of Moench Hall by the chimney), where he lived from 2003 - 2016.

Now of historical interest, it had nice bright lights at the northern end of the long Moench hallway with the elephant mobile above the door and brain stimuli on the bulletin board next to the electronic one and before you get to the box of hinges? You're there. In the closer high window you see a reflection of the lights from our F-217 lab. In Steve's office were beaucoup kinds of goodies, contrasting with the hallway's plainitude.

Next location: Basically, Myers 240, first door on the left. See the images, below.

As he took the pictures, below, hew was moving in, as you can see in the first image, on the left.

You have to know where Myers is, and make it up to the second floor.

It doesn't really say, "Enter Here," as you might imagine. That's imaginary. Arrows are as "real" as things get on the Internet, from

The art work is likely unchanged, so people used that as a guide.

Usually, the gray door was unlocked.

When you walk in, it's the first door on the left, but, again, the handy red guidance won't be there, even though a white board would be a dandy place for it.

See you there!


Latest and greatest location, as he writes this now: Moench D215B, more or less across the hall from the Bio office. Steve marked a few highlights in the picture, below:

Office Hours: Stop by whenever his door is open and there's not a team meeting going on. Steve, of course, will not be there during his classes; or during our scheduled department meetings, or when working from his home in Dayton, etc. See the schedule by his door.

Or, using technology, try his email address or office phone number. Which probably are listed around where you clicked to get here, maybe?

Steve offers a gentleman's wager to Google, that its search is not yet smart enough to put the address of this home page together with his email address or phone number, unless the latter two appear directly on the home page itself. So far, since 2003, he thinks he's ahead. No spam that looks like it's using content from here. Your search algorithm would have to backup a link to find those missing access methods.

At right we see Google software, in the form of fairy tale inventor Charles Perrault, searching for The Sleeping Beauty on the Internet. This doodle was Google's logo on Jan 12, 2016.


And what else?

All the rest of this page is a giant draw to find common interests, items Steve might share with random those happening on it.51 You could be a student, professor, software engineer, or just a regular person!

Students are an outstandingly important reader of the stuff. They come into college very curious, hoping to discover a steady stream of substance they had no idea of, but which they might contribute to. If, instead, they find only a place where proper ideas are drilled into them, and we check for this on final exams, they will emerge less curious. Is that what we want? Steve believes if we present them also with ideas we know are half-baked, and we would appreciate their help in the baking, they will grow this instinctive curiosity.

In academia, we are open to speak or write as citizens, unconstrained by institutional censorship or discipline. This position in the community imposes special obligations, such as considering our impact on likely listeners and readers. Since we are (supposedly) learned researchers and educators, the public may either get sucked into believing something because of that status, or else judge us all by one individual's personal thoughts. Steve saw this happen at Bell Labs, when a particular Nobel-Prize-winning former researcher expressed very public views which could be considered racist.

Steve intends his half-baked discussion, that follows, to be stimulating, yet he recognizes some readers may see one part or another as controversial, from their own perspective and experience. Steve is not speaking for the Institute he works for, or for his department, or for all professors. Having a home page at a school is a part of our historical and sweeping academic freedom. The Institute bravely provides a platform for us to discourse with diversity.

Toward this end of stimulating interchange, Steve made a lot of the page ad hoc, wandering the way we do when we are inquisitive in an opportunistic way. As you skip through it to see what's what, the main sections you'll see are these:

What's where?



Special interests and preferences


If you want to skip down to fun-looking sections, Steve provided some on-page links, at left.


For unplanned exploration, page through this page,

like a book, finding the little filaments.22


Here's a thread out on its own now —

Above — Advancing engineering requires debunking myths. And, aren't we all somewhere in the middle?? This image, making fun of flat earth believers, was from a site where the author argues against carbon dating, an engineering process most of us believe is valid.



Can I see it all at once?

Cloudy with a chance of students: Here's what Steve says on the above, in a simple word cloud. It gives you an idea of what is emphasized, in everything below, at a glance!

In the image beneath the words, an upperclassman saunters past Steve's door, and he gives him a glance, the way you do when you hear something, so as to figure it out, without actually trying to look directly at it. How did Steve know, then, that he was not a first year?

You can tell from this word list Steve pays most attention to the social side of what we software people do.

Steve cannot for the life of him tell you why the word cloud software thought "3" was important in the essays below. You figure it out! There are lots of course numbers referred to, with a 3 in them. Is that it?

Here Steve's playing the role of the "stupid user," who can't decipher what the system is doing for them when, apparently, the system's authors intended that to be a feature.

In the "And more" section, above, Steve discusses the stand-up desk he's working at.

Word clouds are only the beginning: In the "Coding avocation" section, he scans the world of coding we live in, from the perspective of veritable present-day philosophers. It's surprising how closely their deconstructions of authorship apply to writing software.





Can you please show the flow of it?

The whole page in 3 gulps: The concept map at right overviews how Steve thinks of his students' learning, as reflected on this web page. Here we see a nice group of Rose students showing their work at the 2016 Robot Art competition. How did they get here, and where are they going?

  1. On the left in the map: We rely on what they already ARE as people, as shown by the arrows connecting them at Rose back to their roots; and us, who represent Rose, gaining an understanding of that. This background is kind of a container we can draw upon, from their personal past. And,

  2. On the right: We need to attach them to their futures, too, and we need to be in sync with those futures. This one's kind of a cloud, on account of it's still forthcoming. So, there's more guesswork on it.

  3. In the middle: The students are perched upon us, Rose-Hulman, in their present which hooks it together for them. As shown, students may present themselves as these nondescript eggs to be hatched, though we know they aren't so simple. The present rules, because it's where we and they act, but it's also this combination of past and future, as the shape indicates — a container with cloudy edges. Whatever we are, the students are ready to "drop in" for a while, hoping to hatch.

The tricky part, for us, is having to be aware of so much of this, just to do what's right, for them and for the "stakeholders" in their lives, like society, the environment, and their employers. Doing what's right regarding the student requires surmising their background, but they are here to represent that to us. The cloud of their future, over there, is more invisible. We see the students a lot in the halls, not that looming mist.

We ought to dwell holistically with our students, and with our programs for them, matching what they are capable of, coming in from one side, with where they will end up going, on the other.

The two related pieces of that constant matching we do are these —

  • Changing the students, over four years, so they move from one side to the other, and
  • Changing the institution as the goals of that vary, a less routine task but equally important.

The first of these, the learning, is hard on our students, as we faculty observe when we deliver it to them.

The second piece puts a weight on us, since changing isn't easy for us, either. As you'll see, Steve believes we can be wise as to it only by seeing our role from many directions, not just the one correct direction. He further believes, as noted under "Philosophy in Motion?," below, that trade-offs among all the forces out there, in what we represent to students, are essential to dealing with the conflicts inherent in those directions.

Here we go!


Make an image of this whole page?

The whole page at a glance, just a little out-of-date — Search for what looks like it has a curious format or icon, by paging down till you see it. The progressive order is down each column first, then across:

Above — If you don't find any answers here, that's ok. At least consider some bracing questions. And laugh. The Zen part must've worked.

Too cryptic?


What looks good? See if you can page down to it...



Can you show how it relates to me?

Inferring meaning, bottom-up? How about the "Voyant" view of the page? In order of usage, the first non-trivial word in this whole document is "Students," as suggested in the Word Cloud, above. Steve uses it 431 times, more than he uses "Steve." Here's the plot of that usage, through the text, so you can perhaps find the parts most on students, by where the page slider is. Just taking a wild guess you might find that amusing...

Stylistically, Steve uses a lot of words (8461), but it's not that high in lexical density (26%), so Gunning-Fog says it's highly readable! The average word is only 4.75 letters long, and the average sentence is 17 words, with 1.3 commas. His favorite 4-word phrases here are "may or may not" and "of what we do." Look for them!

The phrase "Steve believes" outpaces "Steve thinks." It's enabling — "you can" happens 69 times here, and "you are" 71 times, while "you have to" only gets used 28 times.

It's all big views: "In contrast" and "in front of" each occur 11 times, "of this" 45 times and "of what" 33 times, "of us" 21 times, "of being" 13 times, "they are" 86 times.

All this may or may not be instructional.





Who is this guy?

Steve Chenoweth is an Associate Professor in the Department of Computer Science and Software Engineering at Rose-Hulman Institute of Technology. His principle areas of work, over the years, relate to the design of complex systems and also these systems' associated human concerns such as how to get the stakeholders in a large project to understand each another and the system being proposed.

& How's higher ed like a Persian rug?

His vocational interest is transformational change — making dense growth happen, even though it's complex and a bit unpredictable. Change requiring underlying fabric to vary as an enabler. Mainest center of study for that — higher ed itself. Say, immersive programs like Rose's HERE for first-year students. Rippling applications — Impossible junk, like the 14 Grand Challenges of Engineering.


Above right — Here's transformational change to ponder. Consider what hidden mechanisms would be required to make these finely-woven Persian rugs morph as shown... The change instrument would be even more entangled than the rugs, don't you think?20



Philosophy in motion?

Steve covers three intro topics here, for you to feel out where he's coming from. The first relates to his beliefs on what "engineering education" is. The second tries to justify faculty having less official-looking home pages, especially for student access. The third answers the question, "What's beyond the currently popular 'active listening' aim, as a way of understanding other people, students being one example?


Social learning in engineering education

Is there a secret social sauce?

Around 1980, when Steve was working for NCR, he saw the rise of small software startups, competing with computer vendors to develop apps for their customers. The successful ones used a much different approach to building these apps. Instead of sending someone to go get a spec from the client, then spending a long time in a distant place building to that spec, these startups would setup shop right on the customer's premises, and work closely with them every day. Like, "Here's that screen to take orders — Give it a try!" And, because of where they were, if the client couldn't answer a question themselves, they'd go get the person who could. The triumph of this new competition, over the vendors, lay not in being technically better, but in being socially better.

To work closely with folks like that, you can't be an arrogant technologist. You probably have thought of that, already.

It's taken large, established organizations a long time to conclude that this way of building systems beats any way which preserves their current methods of operation. After all, those in charge were moved up due to success with those methods, not by being good at overturning them. The idea that social skills are equally important to technical skills also violates most engineers' rationale for being. They spent years valuing most the secret sauce of the hard sciences, and their application to engineering. It's just not "them," to admit the value of what they do lies elsewhere.

Left— It's easier to see flaws in someone else's domain; in this case the help desk crowd, a group who likely are supposed to be serving you, the reader. They may come off more like the cartoon. Whoever invented the help desk operation portrayed, did not consider the social repercussions of giving the workers a countervailing, closely watched goal to close tickets. On the other hand, Dilbert comes off as a prototypical, socially immature engineer, at the same time, based on his reaction.

Steve used to be a systems engineer, and this group was founded, by people like Arthur Hall, on understanding big pictures, like the social context within which our fabrications had to operate. Computer science, queerly, not so much, for a lot of reasons, but its application in the outside world has suffered for that. A sample cause — students enter college enthused over CS because of the possibility of creating what might be called Descartian figments, like computer games and virtual realities.50 I.e., replacing concern over utility with their inventions. The "value," to them, is along the lines of getting the coding right to produce an effect which they personally enjoy. These internally focused folks are then turned loose to hatch instruments with social impact, like Facebook, Twitter and Tinder, with predictably massive, unforseen impacts.

Software engineers do build systems that are entirely inward-facing, such as to make one machine talk to another machine, or a lower layer of software. Yet even these usually need some recognition of what humans will be doing in collaboration. In the current (as this is written) Communications of the ACM, Tom Limoncelli writes how IT automation, such as putting everything in "the cloud," cannot ignore deep understanding of the role of humans. If the systems become more and more self-controlling, the "leftover" role of the humans, when they fail, becomes harder and harder, until you reach the point where nobody understands what's going on and can act in time to fix deviations. It is much like the problem of having more and more self-flying airliners where, on rare occasions, the pilots must spring into action.

Both the users and the software teams themselves have deep social aspects which students need to have working knowledge of before we turn them loose. The historic academic trend preventing that is played out even today. A recently created software engineering program, at a school with a very strong engineering history, contains only 11 actual software courses, 30 courses in math, science and traditional engineering, and possibly 4 courses partly touching on the relationship of users and teams to software. The target employment for graduates is software development in the New York City area.

New momentum is being felt, toward including social learning in engineering education. This is seen in The engineer of 2020 : visions of engineering in the new century, where the Renaissance Engineer is portrayed as having a wider range of critical skills, including leadership, teamwork, communication, decision making, and working effectively in diverse cultural environments.

Left — The problem of being inward-facing is a fundamental issue. If CS folks almost inherently prefer to stare down at code, and so our departments are even more socially unaware than typical academic departments, then, wow, there's a big disconnect with the "real world" we send our students out into. By refusing to lift our own eyes off our screens, naturally, we can deny this needs attention. The image at left comes to mind, medieval scholars debating minutiae, like how many angels can dance on the head of a pin, while the Turks besieged Constantinople.

A step in the right direction is that most of the employers, of Rose alums at least, now have personnel policies which sound like, "We hire for technical skills, but promote for social skills." Yet even this is not due to that's what would work the best. The problem is more that they don't know how to test for social skills or fit in a potential new-hire. For technical skills they can look at a student's transcript, ask specific questions, and send them to the white board. However, Rose already benefits from turning out students with more social skills. In Steve's department, we teach teamwork and presentation skills throughout the curriculum, and students often take on multiple projects with outside clients.

There's plenty about teaming scattered on this page. Steve asks forgiveness that it isn't in one spot. Search for "teamwork" to find where it's woven-in.

It's a happening subject now, no question. As Steve writes this, a New York Times article describes recent teamwork studies at Google. Their Project Aristotle compared 100 of their teams. They were surprised: Psychological safety (see next paragraph), dependability, structure and clarity, personal meaning of work, and belief in the impact of the work were the important teamwork factors. On the other hand, the personality types and mix of skills didn't make any difference. Teams of friends and strangers did equally well.

Having agreed group norms, which overrode individual proclivities, did make a difference The group needed to supersede the individual. There had to be compromise. This is exemplified by everyone on the team speaking approximately the same amount. And those on the teams needed to be sensitive to the personal cues of others, skilled at intuiting the feelings of others, based on voice, expressions, and other non-verbal cues. If people continue acting like individuals and ignoring syncing-up with others, doomsday. The development of psychological safety on the team drove productivity.

Unfortunately, the kinds of developers hired by Google "became software engineers because they wanted to avoid talking about feelings in the first place." Those of us preparing them to work there have our work cut out for us.

The researchers also concluded that everyone needs to be free enough to share personal happs in their lives, discuss what is messy or sad, and not feel compelled to leave such things at home. "We can't just be focused on efficiency" and expect to be effective.

In colleges, we are still not as good as we should be. Consider this way of assessing that: What if the extent to which we systematically taught software skills were like the way we teach social skills? We would say it was disorganized and spotty.

At Rose, we do provide constant opportunities for interaction, between students and with faculty. So, it's a start.

It's possible our Millennial students are better at understanding everything falls within a social context, and more of them now come in as social relativists than absolutists. Steve's impressions of how they differ (from us profs, say) is in his section on "Post-modern students," quite a ways below. Yet they are still at the age where "the truth" has vast appeal, and hunkering down to ensure that is an option for them.

One way to improve social skills is for students to have more to talk about with us. This home page is designed to stimulate conversations, particularly with them. Which leads to the next topic.


Rationale for home pages like this...

Above — Here's Richard Feynman's famous poem acted out:

I wonder why. I wonder why.
I wonder why I wonder.
I wonder why I wonder why I wonder why I wonder.

You have to pull a special twisty maneuver to see yourself. Trust Steve that the final inside image nugget comes back around to right-side-up after four Feynman flips, the way the math predicts!

Steve's look is for Diwali, to demonstrate kinship with his Indian students who are far away from their home culture, and he turns himself 90° to help achieve that.

But, to get an alternate sense of the world, you have to bend your own way of seeing subjects, dropping safeguards you usually employ. Not easy. So, doing it multiple times helps you pull away.

More on making such essential compromises, in the very next section.

Explain where you're going here, Steve!?

Being born in a mirror, Steve loves self-referentials, and this wouldn't be any fun if it weren't auto-flexing, as shown at right.

On home web sites, why do we have to guess what academics stand for, in more general terms, based on bread crumbs like the titles of research papers in their CV's, or maybe a couple identifying topic areas? Shouldn't these public sites be places for open discussion, like interests, values, directions, and possible research explorations? Who they are as people, who happen to be faculty?

The historical systems for academic knowledge exchange could be described as broken. For three decades we've been hearing that half the papers written are never read by anybody, schools no longer try to stock bound volumes of all that, and most papers now lie behind publisher boundaries you have to pay to cross. At many schools, faculty are compensated to travel to only a very small number of conferences a year, to improve on those peer interactions. In the current (as Steve writes) Communications of the ACM, Collberg and Proebsting write how non-repeatable most computer systems research is, partly caused by the authors never guessing anyone would want to do that. Their image, at left, decries the problem.

The system we use rewards us primarily for churning out these papers, not for making our ideas useful to colleagues or students. It is a transaction-based system, honed for efficiency. We read each other's, primarily, to create the background section in our own contribution. How often do the papers start a lasting conversation, other than with the purpose of writing that next monograph? We can cite a few seminal papers; this is known as anecdotal eveidence.

Yet we continue to rely on our publication system as a measure of progress and of the academic worth of faculty, as a means for graduate student training, and as the supposedly most informing way to learn each other's directions and results. What we need in addition, if not instead, is easier ways than that to have "water cooler" conversations crossing academic boundaries.

If we look at the learning our students do, over their careers, most of it is informal and involves making connections. Many software firms set up their own education systems, so that those good at teaching and at foraging for new technologies, say, can pass expertise along efficiently to the rest. Steve came out of organizations like that, and was one of the teachers there. Our role, as its predecessor, for each of our budding engineers, should build in this direction. Having our own informal channels, which students and faculty can participate in across borders, just makes good sense.

With any luck, this page has enough on it that it will score some "hits" — like, folks trying to discover who else is interested in evidence-based teaching could find that out regarding Steve. It's a lot cheaper than going to a conference on it. Even more, Steve's students can scan through this, to see "what makes Steve tick," so they have a broader view of who they're working with in class. Like, "Oh, he wants me to be learning this stuff deeply, in preparation for industry, not just get an A."

The web has become our reliable source of knowledge, but it lies in billions of pieces, like a puzzle. How do you know what others mean when they say a curious word out there? It would be nice to have more general points of reference. A home page is a chance to give everyone else that grounding, about yourself. Steve feels this is at least as good as Facebook, whose main reason for existence is to sell you stuff. And he says that as an audio ad blares at him when he accesses his own Facebook page, on top of the visuals.

Steve studies and teaches machine learning. It's not going to solve those issues of tying complexities together for us. The classic example is finding terrorists out of Big Data. Any set of analysis criteria, which might find half of them in the US, is also likely to list, oh, 100,000 non-terrorists, for the FBI to go investigate. It's a well-known side-effect. Even more serious when you consider how possible targets for drone strikes are decided. In general, the false-positive problem is initiated in the deciding of whose value system carves-out the categories in the first place. It's founded in the difficulty of knowing, boxed-in by who we are. Say, whom should we surveil more, to cut down on mass shootings in schools?

  1. Gun owners, in that you have to get a gun to do it? Or,
  2. Those with mental health problems, because it's likely you have to be off-kilter to do it?

Dollars to donuts, no gun owner in the US would pick group # 1, and for good reason — most are law-abiding. Probably no college student would pick # 2, since 25% have a diagnosable illness, which is a lot of students to be monitoring, and 40% of those don't seek help, anyway, making them hard to spot. Might you need roughly one undercover officer for every dozen students, altering the whole feel of a college education? How about the easier, if inhumane, resolution, of dismissing those who have been abused by other students, because they are historically most likely to go off the deep end. (This one's a Jonathan Swift style Modest Proposal, solving the problem in the most awful way.) Sue Klebold, mother of one of the 1999 Columbine High School murderers, wrote a book recently, recounting why she had no idea there was anything wrong with her son.36

So long as no group is willing or able to step out of their particular box, we'll continue as we are. Data might suggest new directions to us, if we're alert to notice it, but we'll want to do a lot of thinking along with that, connecting any new dots. Having more exchanges of fresh ideas is as important as k-means.

Steve's using this topic to build up for the next one; perhaps you can tell.

"What does this mean?" ain't easy. An aspect of Steve's interests is broadening that exploration, beyond our current frames of reference. Thus the dress for the "fesitval of lights," celebrating knowledge over ignorance.

So, if you are in a position where you spew bits of knowledge all the time, like Steve does in his classes, why not have one spot where everyone can go find out what he, at least, believes that means?

And, here goes!


The need to go beyond listening

How might I approach the new ideas I encounter?

This is an exciting era, don't you think? The software and associated technologies we are inventing are throwing us together, folks from the world over, in new and unpredictable ways. We are encountering folks who are much different from us, much closer in proximity than used to be the case. Among the issues that causes — We can't be right regarding the entire set of absolutes we were brought up to believe, and "they" also be right on every one of the ones they were brought up to believe. That hurts. We were not prepared, by our separate social institutions, for such constant togetherness. Yet we have begun to invent solutions.

Buried in Steve's musings on what he's been doing and what he's interested in, you'll see a variety of angles taken. He wishes this rubs off, as you read. We have the ability to step back, or we can be trained to step back, to try for new perspectives. We also can explore coexisting well, by working on that together. This teamwork, and this in-and-out-of-focus skill, are effective for messy social problems. And, lo and behold!, for big technical ones, as well. Which commonly have an important, underlying people aspect.

Left — This imagined building is part of a marketing campaign by SpicyH for a Thai company, It Works, who make the fingerprint-reading device shown, lower right, and associated software. Is it a good idea for a legitimate building design? Maybe. Meantime, it certainly provides the semi-conscious implication that the device could make your building more secure. The fact it is so peculiar inspires curiosity in ad viewers. And the images of this fictional edifice have created a buzz about what's possible in architecture. Would it be too unhinged to build? Ask Longaberger.

In social and technical realms alike, the idea of retreating, to try a new angle, solely for creativity's sake, tends to violate sacred or well-accepted principles. This roof will surely leak! Is the inside indeed connected? Questions, an oblique method of attack, will fly at you.

Steve understands there is no simple solution to the world's problems, with or without high tech. Yielding, from where we each drew a line in the sand, and moving to see that from each other's positions, and sharing in the effort to resolve the differences, as if we were coordinated — that sounds like a general opportunity. On occasion, it will neutralize conflicts, when nothing else does?

Now, any of us could find a summary dismissal of this idea, along the lines of, "That will never work with ISIS, will it?"35 Or, "How do you negotiate-away the drug epidemic? You have to stand on principles!" Or, "The key to building what's new and daring is extreme amounts of effort by a top person!" And it's true that any game plan, like mine, works better in some places than others. However, listening to alternative ideas is how we ended up with the majestic Golden Gate Bridge, longest in the world when built, instead of the originally-planned strangeness. Analysis dominated by one renowned expert is how we got the Tacoma Narrows Bridge, seen in action in the famous image at right.4 Collaboration among disagreeing parties, who at least share a common goal, is a basic, powerful tool. It's not just at idea discovery time. As Rose-Hulman's Bill Kline says in his current Innovation slide set, the execution of an innovative design requires a "team of unlike minded members from all operating groups."

A part of Steve's thinking preference is seeing knots from unrelated directions. It's an architectural quirk, one that used to be refuted by almost everyone else, in favor of having the right viewpoint. Say, writing on the subject of himself in third person to gain perspective — who else would do such a thing?26 In order to let this be a fun and different home page, he did it as if Rose were journaling his experiences at Rose.

6.8 Million Americans are on drugs, and half a million are in prison for it. El Chapo's not happy about how matters are going, but none of the rest of us are, either. The drug wars we've fought, based on cherished principles, haven't worked too well. Nor has leaving the problem up to experts to solve for us, using that set morality. Reexamining where we drew a line in the sand, in regard to good and evil, could be useful.34

In the last row of his last table of chit-chat, Steve returns to the question of when this idea of giving-up, to gain agreement, works. Which you might agree with!

How come? Why would anyone in academia include obviously debatable subjects on their home page?

Our goal with students is to engage their heartfelt interests and grow those. Faculty should be doing the same with each other. The Web enables extending hallway chat to everyone, if we'll just do it. The contrary view, of having home pages mostly as keys to official trappings, like curriculum vitae and lists of papers, feels like it undercuts this blazing opportunity.

If more of us take an informal approach, of course it opens the possibility, as well, that people will latch onto each other's preliminary notion of good, go off and run with it, in all likelihood without giving credit. Indeed, by the point where they develop the thoughts into something more bullet-proof, they may have forgotten how the original mess evolved. We see this on engineering projects, too. Those who are on the project at the end take the credit. Strauss did it with the Golden Gate Bridge, discussed above.

But, maybe that's ok. As discussed in the prior section, our system, of giving credit just to listed authors, and counting papers to decide tenure, isn't anything to write home about. The more important goal is advancing the underlying science and the skills of our students.

There is a huge advantage in getting others to "own" ideas. These then become an internal motivation for the people, spreading your (hopefully good) ideas. If they can claim your idea, or modify it to suit, all the better. Steve loves it when students come in describing ideas they've just thought of, like it sprang out of nowhere, and he recognizses it as a concept they heard from him, a while before. Don't sidetrack them with an authorship correction — they are on a roll!

So, this is a shotgun approach, to throw intriguing ideas out there for colleagues and students. Let them decide what feels like it could have value, go iron out the kinks, and enjoy that. It's invigorating, not honed for eloquence.

Left — Please keep in mind that the concepts suggested here are intentionally fragile. You could do them in, just reading one, thinking of a reason it's wrong, saying "Nope!", and going on to the next one.

The graph here is a Synectics favorite, though, as you see, Francis Bacon also approves. Bacon goes on to say that new ideas "trouble by their inconformity," and so we tend to dismiss them prematurely, ignoring their utility.

The Synectics method suggests a less harsh attack on the novel. First get a lot of ideas out there, which vary in different dimensions. They predictably are "Bad" in the sense just described. Then try to nudge them over the "Threshold of Acceptability," one at a time.

How would you do that nudging?? For each, first think of some good or intriguing aspects for it, so that Bacon's "utility" is in your head. Then list just a few of the issues it has — the main ones.

Now for that nudging: Brainstorm ways you just might whittle away at the biggest one of those issues. Develop an action plan, for who would do what, to start whittling. You now have a method for making the provocative be more acceptable.

Nice work!


Steve once got a personal lecture from a visiting pastor, after Steve had noted, during a church service, that miracles seem only to be visible to believers. The pastor's point was that "the Truth" was defined to be what was in the Bible; science and observations were fallible, and were expected to fall in line with this. Not long after, an NPR story on science in the Muslim world included an assurance by an Imam that scientific truth was to be accepted, so long as the truth of the Quran came first. This seemed to be a shade more liberal. Yet it was much easier to predict that the two religious positions would be the source of perpetual conflict, than it was to imagine how those following these lines of thinking could compromise so as to live more closely together.

Will just mixing in a purposefully neutral environment take care of it, like when we work together at places like Rose? In his famous "Solitude Trilogy" for CBC radio, pianist Glenn Gould used stereo sound to play admonitions from a Mennonite pastor in one channel, and young adults describing in the other their college experiences. The problem of their being exposed to a broader base was not, as the pastor had warned, that they'd encounter lots of evil people headed for Hell. Instead, it was that they'd discover folks with varying religions, or no religion at all, were equally good.

As long as schools of thought with a long record of conflict insist on unquestioned allegiance, how will we break out of that pattern? Send them to university?? Feel free to apply the brainstorming methods described above, and start a dialog!



Expository style

Can I just dabble in it?

Right-brain thinkers — whatever that means — tend to ramble. One aspect of a holistic perspective is wandering through the view, looking for nothing, but finding a good deal to be beguiled by. Like the landscape behind Galloping Gertie there, which has the illusion of being far closer than the better part of a mile it really is. Are some of the trees there visibly blowing in the wind? Or, why colorized green? Maybe to punch-up the money loss? The insurance agent had made off with the premium. What do you do with a bridge that falls? (Steve believes they just left most of it lying in the water.)

Above — Gestalt is required for synthesis, what designers do. And also for discovering what doesn't belong with the rest, in the analysis of complex objects. Why exactly can't the cloud exist here? Couldn't it have floated in, when the window was open? Couldn't the light be from the right angle, to give it that combination of opacities?

College students' educational history tells them that apparati they can assemble, from parts which work, also are likely to be good. They love bottom-up agendas, like the "greedy algorithm."

The more complex the system, the less likely such plans are to pay off. For example, with software made up of many pieces, if one gets upgraded, the odds are pretty high some other part relying on it will now fail.

Having only dealt with simple systems, so as to make their lessons direct and to the point, students are unprepared for this aspect of their careers.

Did you consider that it might be smoke, not a cloud, and perhaps we should be calling 911 and running for it about now?

And, we Gestalters tend to write that way. So, in the sections below, all kinds of content are mixed in one document, according to very general themes since, to us, the thoughts overlap. You may have to search for topics of interest to you.

One possible use for this — read until you see or think of what's interesting to go do! Like, oh, how to insert your own em dashes in html? Or, in that Santa song, what's the line before "Dash away! Dash away! Dash away all"?18 Steve shouldn't be disappointed if you quit after this paragraph.

Among other things, the next part is a FIFO history — If you're looking for recent, scroll down a bit in the section.



How come?

Ethics: It's no mistake that Steve shares with the rest of Rose's faculty the desire to inspire and transform students. In a liberal arts school, this could be the main goal of undergraduate education. Students come to an engineering school like Rose hoping for this gain, as well. Yet, in engineering, we feel that a larger part of a student’s undergraduate education has to be dictated, not chosen for enjoyment, versus what they would get in a liberal arts degree. Some Rose majors have no free electives. Students are, after all, being prepared for a specific role. If they are to be an ME, we’d not let them choose to skip dynamics, based on their personal preferences. Insisting on social preparation is the same argument as these technical mandates. And punting this part of their education, to the places where they will work, to avoid doing it ourselves, is not reasonable if we want to ensure it gets done.

Steve came to Rose straight from industry, with the idea of starting a software engineering program here. Like ME, SE is related to using the right processes to get the right results, on top of the underlying technical principles. Those processes heavily involve interactions with a team and with management. Engineering decisions need to be made, including compromises. In case you didn't realize, engineers are supposed to rise above the profit motive and act properly on behalf of the mortals affected by their decisions. They need to be professional, a notch up on Kohlberg's stages of moral development. Learning such social lessons may or may not appeal to students while they are being taught, but they need to wrestle with tough social issues regardless. One of Steve's business experiences went as follows:

  • Customer (at their world headquarters in NYC): So the first release of the product will have this feature? [Looks at Steve, the designer.]
  • Steve: No, it won't. [The feature would not be possible to develop, first-out. Customer looks at sales manager down the table.]
  • Sales manager: Yes, it will. [Customer looks back at Steve.]
  • Steve: No, it won't.
  • Sales manager: Yes, it will. [He looks at Steve now, who wonders how long his employment will continue.]

Right — The most common vocational image that visiting high school students and their parents have, of what they would do with a career in CS, is write code for video games, kind of in isolation like the experience playing them. This is a Far Side cartoon from Psychology Today.23

Students need to prepare for such events! They are unlikely to enter Rose wanting to be a part of these social sides of programming, or even knowing they occur regularly.

Targeted learning: The Langley Aerodrome metaphor under Hot Topics, above, is typical of Steve's underlying thinking on higher education. In the software industry, half the code is error handling or error prevention, stuff you add just to harden the system. Yet durability is not even touched upon in most college software programs. The goal for undergraduate students is to produce a series of progressively more sophisticated toys which work once at the end of the term. When Mark Ardis, Don Bagert and Steve initiated the Software Engineering major, we changed that situation in the department's capstone program. Starting in 2004-5, our senior project had three terms versus two, and the last of those terms was specifically to harden the product, while an audience greater than just one client tried to use it. We wanted this experience to be a true test of a student's preparation for a software job.

The reason such sizable mistakes can fall into CS curricula may be that academia doesn't understand how success happens in the fast-moving world of software development. See the Carnegie Mellon model, under "Ok, design mostly?" below. We believe good ideas emerge from research in universities, and are then bestowed upon industry via our students and through patents and technology transfer partnerships. That's a little bit true. Do we believe it just on the grounds we were trained so long to be academics, or because CS departments largely evolved out of math departments, or the theory is simply what we relish and excel at? Few of our students will end up in our careers, and a career in the constantly changing software development field is not the same.

In engineering, more often, we academics pull practices already used in industry, and we perfect them. Like, "A great amount of CPU time is being spent in searching and sorting. How could they be doing that even faster?" The honestly new IP, say, "MapReduce" or "Micro-architectures" or "Simian army" or "Extreme programming" or "Cloud computing" are more likely to be originated in practice. You could complain, "Extreme programming isn't new anymore!" That being the case, how have we hardened it through research, since Kent Beck invented it 20 years ago? Why are the 12 practices still debated, without a solid underlying set of studies?? We don't yet know when pair programming works better! Few of us academics even use it. Extreme programming is still new to us.

Our mistaken bias the other way is enough for us to discount the teaching, to undergraduate students, of whole topics from industry that don't feel like they have enough theory to be worthy, or which we ourselves don't get very well, due to our lack of business experience. We picture our students "getting all that once they are out there," graduating with just a base in theory. To some extent industry accepts this deal, seeing as they are so hungry for talent, but it is not advantageous for either them or the students.

Steve's goal has been to match students to industry, so that they are prepared for the careers they intend to pursue. In addition to our rationalist bias, we also don't know enough as to what they do as alumni. We see a lot of what high school students are like, coming into our educational system, because we have them in front of us constantly. We see incredibly less of the finished products, and we don't get the same level of feedback, at all, about their success. Steve addresses this problem in more depth, in his section on Evidence-Based Teaching. We need more information on their outcomes.

Appropriate learning roles: That same section discusses the related pros and cons of our considering students to be customers. In several ways, they are not like industrial customers or even consumers. Those customers believe they know the required utility of a product and make buying decisions based on that. Even iPhone users shopping the half million apps out there feel intuitively the need they are looking to fulfill. Students, in contrast, are being taught the utility. Customers pay for goods themselves. Students' parents often pay. At state schools, the public chips in. Most customers of big-ticket items are entirely grown up. Students gain reasoning skills while in college. Students who don't cut it are washed out. Few companies would dismiss their customers for failure to meet standards. As ASEE President Joe Rencis puts it, "Students are both the customer and the product" in education, with attributes of each.

Fixing our own processes: Sophisticated products are a bit messier. In the world of Agile software, we have discovered customer advice is imperfect enough that we cannot dependably ask them, up front, to say what they want in a complex product. Either they can't say it well enough or the developers don't get it. The outcome they need to evaluate is still evolving, and thus judgments are unreliable. They'll know it when they see it in use for a while. In educational developments, we still make the mistake of employing the old "waterfall" development model, based on some starting interpretation of the needs, and waiting until first delivery to verify that. And our undergraduate programs have unchecked ways of evaluating processes; they assume that first year students, say, can click-off boxes evaluating the quality of their learning against some far future need. Why do we use such things to decide academic careers??

To the extent students are customers, we can learn from existing business models of customer relationships. Most companies try to maintain a loyal customer base forever; it's harder to attract new customers. Every plan is made to continue getting current customers' business for add-on and replacement products and services. Customers of software businesses may use a key product indefinitely, providing the vendor with a constant stream of feedback. Steve can see how, for an undergraduate school, the repeat-sale situation is different: Once they are gone, we want to try to keep track of them, whether we have more educational services to sell or not. The need remains, to get high quality, long-term data about the value of what we do provide.

So, Steve came from the world our students are heading into, and he's motivated to match his students to that world, improving aspects which will help make them successful. Steve's section "Students → Realties of Software Engineering," below, amplifies on this position, complete with another plane crash. His teaching philosophy, toward that end, is sketched in the very next section here.

Above, left — Jean-François Millet's "The Gleaners," 1857, considered to be a great example from the Realist movement in painting. If we want students to know what their work will be like, why would we be happy with anything less than the best possible realism they can handle? Steve supposes that's true even if they end up discovering, like here, it's not glamorous. Maintenance work, which we do a lot of in software, is kind of like gleaning the grain remnants from a field!

Starting at Rose, a while before now...

Describe the path through time!?

Steve applied for the job in 2002, proposing a variant teaching philosophy, just slightly edited here. When his older daughter read it, she felt a better name than Professor, for the job he wanted, was Suggester. Steve has proposed, to his department, that we adopt that title, since means change so fast in the software world. Professing anything, as if it were absolute, just sets you up to be wrong. Key aspects of Steve's field, which you will see referred to below:

  1. No single right answers.
  2. One has to be able to turn off traditional "critical thinking," i.e., analytical thinking, to do synthesis well.
  3. Despite the fact coding is a linear flow, you can't make it do what it should, by just thinking linearly at it.
  4. You can't use fake problems with pat answers, in a class, and prepare students for the software world.
  5. Teamwork is essential, because no one person knows everything, or can do everything, to solve hard problems.
  6. Students need to prepare for failure by experiencing it in class. Thus, they can't be expected to get almost everything.

And, Rose-Hulman bought it. So, here he is! An Associate Suggester.

Next are some classes Steve enjoyed teaching, right off:

Fall term 2003-4 he team-taught CSSE 371 — Software Requirements, with Don Bagert.

On a roll: Fall term 2004-5 he did this again, with Mark Ardis. Kept going on requirements, teaching it in 2008-9 and in 2012-13 with Sriram Mohan. In 2013-14 Chandan Rupakheti and he did it. In 2015-16 four of us each ran one section. The course's RHIT catalog description is: Basic concepts and principles of software requirements engineering, its tools and techniques, and methods for modeling software systems. Topics include requirements elicitation, prototyping, functional and non-functional requirements, object-oriented techniques, and requirements tracking.

Here we see a happy "Team 8" from one section of the 2003-4 course, Tyler, Ben, George and Derek, presenting their requirements for a system to help ensure student graduation. They may be smiling also in part since there in fact was no "Team 8" in this class, but they posed as it successfully.

As noted in a similar picture, below, the teams were obtaining and managing information for a real system to be developed. Ten years later, we succeeded in creating a worthy version of that, as a student project. It allows students to do "what if" planning concerning majors, courses, and graduation dates. One result is that a higher percentage are able to build models which let them graduate early.

With graduates: One of these guys went to Stanford after Rose. Another participated in a start-up — talk about orgs who need requirements! And, Steve's taught a graduate version of this course in Indianapolis on three occasions, to software professionals.

Is there a difference? Juniors fresh from math class want to know why clients don't just tell them the correct requirements to begin with. The requirements course is a challenge for many of these students, because it comes on top of their taking many a career of courses where their own analytical thinking always wins the day. While requirements are indeed analyzed in solving problems in CSSE 371, they are largely not analyzed mathematically, but more in terms of the needs of others, like users and paying customers. It's a new focus, which requires a change of thinking modes! To the grad students, the idea of making any kind of dent in this nebulosity problem has tremendous value.



Few CS departments have an undergrad course in requirements, and for even fewer is it required. Come to think of it, not many other engineering fields dedicate a course to it for BS students. Yet, "getting it right the first time" is cited by a very large number of alums as one of their biggest problems.


There are other anomalies that look like program / career mismatches. Perhaps half of most software projects' effort goes into testing. Reducing that interval could be a huge win for the industry. Yet what programs have just one required QA or testing course, to teach the latest and greatest tricks??


Right - Famous Steve Skelton Loose Nuts cartoon on requirements, so old that some of the programmers are using coding pads. When Steve asked him for permission to use it, in 2002, he couldn't even remember doing it!

Watch out — AI: Winter term 2003-4 he taught CSSE 413 — Artificial Intelligence; he taught this again fall term 2004-5 and 2005-6, and will be in fall 2006-7. Steve used Russell & Norvig's book and targets the learning so as to be useful for students who are going directly out into the workforce as well as for students headed to grad school.

Here are Eric, Matt, Richard and Guy, from the winning team in the checkers tournament which also was featured in the 2003-4 course. Each year we change the game, with the course assistant getting to have a major say in the structure of the new game.

The final project in 2003-4 was to create an intelligent web search program, a pragmatic application of various skills learned throughout the course. In the succeeding years we have let teams of students pick their own final project — a breathtaking alternative.

Three of these four students ended up working at Microsoft.

Left - AI has turned out to be super-important after all! In the decade since this class, machine learning has taken off as integral to big data, and reverse engineering the brain is one of the 14 Grand Challenges for Engineering.

Artificial Intelligence!

Steve added lotsa teamwork into this course, a feature that's still a major ingredient. For his first try at that, see the last green block of discussion, way below.

Blobs take over: In 2004-5, Steve's assistant Clint Weis did a fabulous interface for a "Blobs" variant program, and it enabled both an in-class and a Rose-open Blobs tournament.

Here's Steve trying to beat one of Clint's "default" players in a game. Against the class's minimax players, humans didn't fare so well.

As a final activity the class AI teams picked their own project — these varied, from neural nets solving practical problems, to text analysis from knowledge bases, graphical games, and learning systems.

Specializing in variety!

Did you branch out?

If you read his additional teaching practices, below, Steve would love to know what endeavors you liked hearing about the best:

Project Management: Winter term 2003-4 he also taught advanced topics in project management to one grad student and as a volunteer seminar, primarily for students who already were working in software development. Later, he taught full classes of this subject. Many undergrads want to be coders, so it's a big step up for them to consider learning skills so as to move "to the dark side," management. Some do, though. One of our grads began her career as a project manager at Rockwell Collins.

In software, the nature of the PM position has mutated, from someone representing management, whose role was to inspire the developers and keep them "moving forward." Now, the first-level position is like a "scrum master" who is fully a part of the team and shares responsibilities with the rest. There also are process people whose job is more technical than in the old days, like whoever has to keep a "continuous delivery" system running. So, we teach that stuff.

Software Architecture: Spring term 2003-4 he taught CSSE 374, — Software Architecture and Design (now Software Design), a course like CSSE 371 in methodology which he developed. Way cool results especially for students with software development work experience, one of the few courses where undergrad SE majors genuinely get to architect a significant system. So much fun that, for 2004-5 this will be 2 courses. In 2004-5 Steve taught this again, with the enhancement of additional material on software patterns. He also taught a second term of this subject which also included interaction design. More of that second course in 2005-6 — great fun! And a challenge for students, on the grounds that some have not had related work history yet, and most won't be put in charge of designing systems in industry until a few years into their careers. Steve's now taught software design and/or architecture most years he's been at Rose.

Steve presented how the architecture course is designed as part of a workshop at CSSE&T in March 2004, and again at a seminar at SEI in August, 2004. Which led to regular involvements at both these places. For the 2014 CSEE&T conference, Steve's on the program committee; he and his wife are going to Austria!

Fundamentals: Steve also taught a section of CSSE 120 in spring 2003-4, the intro to software development course, and again in spring term 2004-5. He has regularly taught "core sequence" software development courses "on demand," whenever we needed someone fast to cover these. These include CSSE 132, 220, 221, and 230. "We" being his department. Some of these happenings are detailed later.

Launching high school students: Summer 2004 Steve taught a session of Rose-Hulman'sCatapult program for high school students. Three weeks of fun, and many of the 16 went from not knowing Java or programming at all to being able to code surprisingly sophisticated systems.

At right, here's the original picture one team did to kick off their genetic fish growth experiment in Java. Later they collaboratively created a 3800 line graphical "Settlers of Catan"-type system.

One team of two created their own instant messaging system with file transfer, and by the end of the session other teams were using it to send messages. This entrepreneurial pair won second prize overall at the concluding Catapult expo and were ready to take orders for their software!

He taught Catapult again in 2005, and also in summer of 2006, then 2008, 2009, 2011, 2012, 2013 and 2014. Quite a few of these high school students end up coming to Rose. Steve's now seen his former students at their jobs in industry!



At left we see a 2013 team brainstorming their problem, to invent ways to help scaffold high schoolers as they practice geometry problems. In the process, they invented a new software development tool, attaching user stories, on the PostIt notes you see, to their preexisting story boards!



Ok, design, mostly?

Did you focus, at the same time?

All kinds of software architecture: Winter 2004-5 Steve ran labs for the Database courses (CSSE333) taught by Salman Azhar. Salman left to be a program director at University of San Francisco, and then returned to industry. Now teaching at Duke.

Arch and more arch: Steve taught the new, expanded version of Software Architecture and Design (CSSE374) which became the first half of a 2-course sequence. He used Bass's book for the architecture and David Budgen's book for the design, adding more material on patterns as noted — also regarding customer relations, and so forth — you can imagine... he expects — the software architecture world seems divided into those who understand the critical nature of the architect's role as a leader, the rest stuck on technical issues of design-in-the-large. One suspects most of the latter have never actually been software architects on a project being judged by outsiders. Just Steve's opinion; he could be wrong. In 2008-9 we switched to Craig Larman's book, so as to make 374 an OO design course.

He invented and taught CSSE 377, now 477, the second course in software design/architecture, which includes lots of Interaction Design as well as regular old design for the usual reasons. What are those reasons, anyway? He combines the pure coolness, like increasing cohesion and enabling reuse, with the pragmatic, like how to choose tools, how to design what others can detail, and how to architect so that geographically dispersed groups can implement simultaneously.

In 2014-15, Steve and Chandan did a CSEE&T paper summarizing their experiences teaching the architecture part over 10 years. Steve delivered it in Florence as a whammy; instead of lecturing, asking the others there to share their own involvement. Pretty rich stuff.

Left — This image is from a systems architecture course Steve did at Lucent, then described in his presentation applying for work at Rose. He's used it in the software architecture courses he's taught here since.

The concept, from Shaw and Garlan's book, attributed by them to Carnegie Mellon generally, is that there is a progressive maturity to our design ideas, starting with maestros who look like they solved a new problem magically (the "ad hoc" solutions at left), progressing clockwise through folkloric water cooler socialization, to writing records down, and lastly creating testable models and doing experiments on those. It's provisional the whole way, with research last, not first. In the final step, we push the boundaries again, darn near falling off the design cliff until some fresh magician rescues us with a new, flighty idea.

Perhaps most bewitching, about this cycle, is that all of us tend to get stuck at a certain spot in it, and don't want to operate in any other way. Steve's worked with some of those magicians, who weren't particularly social in explaining their novel solutions. He's known, as well, plenty of engineers who wanted to stick with oral traditions, never writing anything down but code. These days, they can even justify that — it's "agile." The folks who codify processes are another clan. And, of course, the real CS scientists think they did the most important work, too. But we're intrinsically each just one piece of this growth cycle, each finding the needle in Monet's haystack in their own way.

Right — The right half of Steve's righteous software architecture class, fall, 2010. The teams of students used a system they had previously built, for six architectural experiments. Each was designed to test what worked and didn't work, to improve a particular quality attribute (QA). For example, the first challenge was, "Make it run twice as fast." The lab notes for each experiment captured their process and results. You can see they were very serious over it.

Most newly graduated software engineers will not be building major systems from scratch. But, they may have a chance to improve some QA like this, and use the knowledge gained from the class.

Dr. Bohner sits in the back row, left. We eagle-eye each other's classes regularly, for the reasons you can imagine.

And more DB: The database warm-up proved valuable when Steve co-taught 3 sections of the database course with Curt Clifton, during the 2005-6 year. This also involved a collaboration with Rose-Hulman Ventures, who thereafter hired some of the students. Curt's now moved on to developing cool software for Apple products with Omni Group.

Teamwork: In spring 2005-6 Steve taught the innovative Teamwork and Robotics course with David Mutchler

In 1977, after a few underwhelming months as the first new guy in Saturday Night Live’s then-brief history, a 26-year-old Bill Murray reached out to home viewers with the emotional equivalent of a Kickstarter campaign. The audience expected the Not Ready for Prime Time Players to be funny, and in everyday life, Murray claims above, he was. It just wasn’t coming together in front of the cameras yet.

It didn’t help that he was replacing audience favorite, Chevy Chase.

He was also an unknown quantity in the eyes of the writers. Rather than entrust their precious material to a guy who’d yet to prove himself, they saved their plum assignments for the likes of  John Belushi  and Dan Aykroyd.

Murray was relegated to the sort of pallid supporting roles that require no particular talent---“the second cop, the second FBI agent, the guy holding the mop…” is how he described them to Howard Stern in an interview last week. It's a story that's also recounted in the book, Live From New York: The Complete, Uncensored History of Saturday Night Live as Told by Its Stars, Writers, and Guests.

Back in ’77, he wisely chose not to blame the material.

Instead he curried favor with references to his late father, his hard working mom, and his nine siblings, one of whom was a nun. (Another had polio, but he left that out. Apparently, some things are sacred.)

Later in his career, he'd become celebrated for his smirking insincerity, but his direct appeal, as producer Lorne Michaels dubbed it, had none of that.

He wasn’t looking for viewers to write in on his behalf, just an assurance that they'd root for him (and his large, fatherless Catholic family) during his tenure at Rockefeller Plaza (“New York City, New York 10020”).

It’s doubtful whether a similar gambit would’ve paid off for Garrett Morris or Laraine Newman. Comedy, like life, is not fair.

Now that he's rich and famous, he advises people who dream of similar glories to check if the first part alone won't be sufficient to cover the bulk of their fantasies.

But we, the public, need Bill Murray to be famous, too, in order to crash our parties, and help us understand Shakespeare, and read poetry to construction workers.

Turns out he's not the only one to reap long term medicinal benefits from those two “tablespoons of humility” he swallowed live on air, all those years ago.

Related Content:

Bill Murray Sings the Poetry of Bob Dylan: Shelter From the Storm

Bill Murray Gives a Delightful Dramatic Reading of Twain’s Huckleberry Finn (1996)

Watch Bill Murray Perform a Satirical Anti-Technology Rant (1982)

Ayun Halliday is the creator of The Mermaid's Legs, a trauma-filled Hans Christian Andersen reboot debuting in the shadow of Rockefeller Center in less than two weeks. See it! And follow her @AyunHalliday

One thought on “Chevy Chase Snl No Math Homework

Leave a Reply

Your email address will not be published. Required fields are marked *