Steve Chenoweth's Home Page
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"?
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!
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 about 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 about 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 action?" sketches the rationale a bit more, as well as kicking things off with one sweeping proposal for Steve's students.
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.
Office: F-220 (Top floor, back of Moench Hall by the chimney). See the office with the 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 are all kinds of goodies, contrasting with the hallway's plainitude.
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.
All the rest of this page is a giant draw to find common interests, things Steve might share with random people happening on it. 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 things 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.
Toward that end, Steve made a lot of the page ad hoc, wandering the way we do when we are inquisitive about things. As you skip through it to see what's what, the main sections you'll see are these:
If you want to skip down to fun-looking sections, I provided some on-page links, at left.
For real exploration, page through this page,
like a book, finding the little filaments.22
Here's a thread all 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 people believe is valid.
Cloudy with a chance of students: Here's what Steve says about all 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, probably, 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 real present-day philosophers. It's surprising how closely their deconstructions of authorship apply to writing software.
The whole page in 3 gulps: The concept map at right overviews how Steve thinks of things, 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?
The tricky part, for us, is having to be aware of so much of all this, just to do what's right, for them and for all the "stakeholders" in their lives, like society, the environment, and their employers. Doing what's right about the student requires sumising all 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 —
The first of these, the learning, is hard on our students, as we faculty all observe when we deliver it to them.
The second piece puts a weight on us, because changing isn't easy for us, either. As you'll see, Steve believes we can be wise about it only by seeing our role from many directions, not just the one correct direction. He further believes, as noted under "Philosophy in Action," 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!
The whole page at a glance — search for something that 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:
What looks good? See if you can page down to it...
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 195 times, more than he uses "Steve." Here's the plot of that usage, through the text, so you can perhaps find the parts most about students, by where the page slider is. Just taking a wild guess you might find that amusing...
Stylistically, Steve uses a lot of words (5763), but it's not all that high in lexical density (26%), so Gunning-Fog says it's highly readable! His favorite 4-word phrases here are "may or may not" and "of what we do." Look for them!
All this may or may not be instructional.
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 people concerns such as how to get the stakeholders in a large project to understand each another and the system being proposed.
His vocational interest is transformational change — making big things happen, even though they are 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 stuff, 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
This is an exciting era, don't you think? The software and associated technologies we are inventing are throwing us all together, folks from the world over, in new and unpredictable ways. We are encountering people 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 about every one of the ones they were brought up to believe. That hurts. We were not prepared, by our own cultures, 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 hopes 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 real 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 crazy 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?" Or, "The real key to building anything 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 things 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 about his experiences at Rose.
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 real 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 stuff, like curriculum vitae and lists of papers, feels like it undercuts this blazing opportunity.
If more people take an informal approach, of course it opens the possibility, as well, that people will latch onto each other's preliminary notion of something good, go off and run with it, probably without giving credit. Indeed, by the point where they develop the thoughts into something more bullet-proof, they may have forgotten how the original thing evolved. We see this on engineering projects, too. The people who are on the project at the end take all the credit. Strauss did it with the Golden Gate Bridge, discussed above.
But, maybe that's ok. 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.
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.
Left — Please keep in mind that the concepts suggested here are intentionally fragile. You could do them all 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 probably all 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 things about 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 something provocative be more acceptable.
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? What do you do with a bridge that falls? (Steve believes they just left most of it lying in the water.)
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 because, to us, the thoughts overlap. You may have to search for topics of interest to you.
One possible use for all this — read until you see or think of something 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.
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 all 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 all about 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 people 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 about higher education. In the software industry, half the code is error handling or error prevention, something 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 sizeable mistakes can fall into CS curricula may be that academia doesn't understand how things work 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 because 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 really new stuff, 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, because 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 about 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 about 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 all 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.
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 reliably 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 thing they need to evaluate is still evolving, and thus all 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 unrealistic ways of evaluating processes; they assume that first year students, say, can check 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 about customer relationships. Most companies try to maintain a loyal customer base forever, because 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 things which will help make them successful. Steve's section "Students → Realites of Software Engineering," below, amplifies on this position, complete with another plane crash. His teaching philosophy, toward that end, is sketched in the 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 all glamorous. Maintenance work, which we do a lot of in software, is kind of like gleaning the grain remnants from a field!
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 Suggestor. Steve has proposed, to his department, that we all adopt that title, since things 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:
And, Rose-Hulman bought it. So, here he is! An Associate Suggestor.
Next are some classes Steve enjoyed teaching, right off:
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 because there really 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 people 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 other people, 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 stuff?
Right - Famous Steve Skelton Loose Nuts cartoon about requirements, so old that some of the programmers are using coding pads. When I 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 — an 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.
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.
If you read about 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 reperesenting 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 all 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 realistic 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 grouds 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's Catapult 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!
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 hopes — 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 stuff, like increasing cohesion and enabling reuse, with the pragmatic, like how to choose tools, how to design something which other people 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 all 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 people who look like they solved a new problem magically (the "ad hoc" solutions at left), progressing clockwise through folkloric water cooler socialization, to writing things 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 people 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 all the work, too. But we're really 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 about 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 all 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 this
service learning course, 34 students helped high school and middle school
Botball teams create competing robots from Legos. The Rose teams also built
their own Beyond Botball entries, and as pairs wrote a paper on an area of
interest in robotics. Steve and David wrote a paper on this class, as a
work-in-progress, presented at an ASEE conference in far-away
Senior project: Steve taught the BS capstone course to some teams each year he's been at Rose. This year he has multiple sections (currently 12 teams). It's exciting to see what the students you've had for other things along the way can do just before they graduate. This is our students' transition to industry, where they are almost on their own! Some of our required courses have a zero correlation with success in this capstone. Hmm. In the past Steve also managed senior design projects for our students in our Robotics program.
Left — Here's a senior project being demo'ed at our winter term Expo, 2010-11. It was done for Roche Diagnostics. The project allowed managers to have real-time manufacturing statistics available on various devices.
Sabbatical: During the 2009-10 school year, Steve was Visiting Academic Administrator for the EPICS Program at Purdue. This was a step toward getting an EPICS-type program going at Rose-Hulman. It was great fun managing 90 projects for 30 teams with different non-profit clients!
Masters of Science in Software Engineering program: Steve's taught most of the courses in this program, as well as teaching engineering management students about requirements and helping get a number of those students through their theses. He had fun in all of these, and a link to one of his MSSE courses is given above.
Right — Graduate software design class, fall, 2010, at Beckman-Coulter in Indianapolis. This is a much different learning environment, because the students are all working professionals. Every week's topic includes how this design practice would plug-and-play in their current development activity. The entire class gave push-back on "test first," because all their systems involved hardware, legacy systems, or other such complications, making for delayed test opportunities and outcomes.
But not really — here's a bunch-o'-other-courses & gigs!
Steve did those, too, and enjoyed them! Think chocolate cake. He sits in on almost the whole term of someone else's class, almost every term, to absorb both the material and their teaching style. And he's taught all the CSSE courses which are prerequisites and follow-ups for the ones he usually teaches.
Some prototypicals he got a charge out of:
Steve's educational history supporting these interests includes a Ph.D.
in Computer Science and Engineering as well as an MBA from Wright State University in
So, how do you get undergrads ready for a career doing such stuff? You have to pick the lessons, because it's really a whole lifetime of learning.
Left — AT&T's Columbus Works was one of the wower places Steve worked. We made "operations systems" which ran networks. And we did everything from scratch — had our own version of Unix, one of the first to include transaction processing. The software people had offices in the front of this building. The very large rear part was the factory. They used to bring cold rolled steel in one door, and ship completed telephone switches out another.2
One fun project Steve did: In NCR's retail marketing division, in the 1980's, Steve invented new business practices which could seduce our major retail customers to back entirely different kinds of products. For example, grocery stores then were losing business to fast food chains, as more families had two working parents. "How to make cooking both more efficient and more fun" could have slowed that trend.
The futuristic solution he proposed, called "Computerized Home Dining," impacted food stores in indirect ways. It centered around a PC for the kitchen that guided the food preparer more surely and swiftly as they cooked interesting meals. Which could cause them to buy more groceries, and more high-end ingredients, specifically. It could also have meant automated grocery ordering, as the home chef, building an upcoming dinner menu, clicked items needed for a recipe, which they were out of. The PC was tied to a laser disc to show cooking activities for the chef to follow — a pre-World Wide Web solution.
Right — Nowadays, lots of people use such expanded cooking guides, but the suppliers of those have yet to make them a ready resource. At the site where this image was, Steve found complaints about the quality and variability of the instructions.
Another fun project Steve did: Patent for parallel processing
using competing algorithms — Assigned
to NCR, 1997. Works like this picture:
Different computers try to solve the same problem in varying ways at the same time. When one gets the solution, Great! — It might be the quitting point for everybody. (Some of the time chunks represented by the dashed arrows can be avoided, assuming you could not predict the shortest running algorithm to begin with.)
Yet another: In the late 1980's Steve consolidated the general trend for building software-based products, defining it as "Adaptive Business Systems." His proposal, to NCR's Corporate R&D, was to build modular models with clean interfaces, such that a given model could be replaced by real hardware or software, as these were constructed. But, the model defined the testing, so that the system tests were there when each peace finished unit testing. You could tell right away if you'd blown the model. Indeed, the model would work as a demo-able product, and might even be a first-out product.
It was just a concept, and the corporation figured they'd have to start over with development to implement it. Yet it represented a desirable direction, if and when it could be done. This proposal alone, Steve thought, probably got him a job in the Corporate R&D division. Ten years later, at Lucent, he was able to see piecemeal model replacement in action, as software defined switches grew to be a mix of hardware and software, to provide the needed performance.
These days, we have something like this in action on many software projects, with Continuous Integration and Continuous Delivery. At the start, we may be lacking the model to plug-and-play into, but we work around that. The idea of integrating and testing new pieces as they are done, tested against something reliable, is very powerful. As shown at left, the small changes to enahance and analyze provide a loop which can be completed very fast. "Release" of course is not done every day — you don't want to vary the user interface without notice, for instance. Maybe, where needed as a fix for Agile, opening with a replaceable model is next?
Relevance: When Steve arrived at Rose-Hulman, he learned that Chauncey Rose had planned the school “for the intellectual and practical education of young men.” From the beginning, faculty included engineers with vocational experience, as well as academics. This is appropriate for us today, as well. Engineering is not the same as science. We would like to use first principles as much as possible, but the project must be delivered to the customer on Thursday, not wait for more research to happen some day. The job has to meet requirements for which scientific underpinnings may or may not be available. Engineers combine these principles with best practices, heuristics, and their own judgment, ethics and aesthetics, to create a product meeting the needs. Having experience wrestling with those situations, for at least some percentage of faculty, ensures that both aspects of engineering, the scientific and the pragmatic, are taught to our students. Steve was happy to be able to help build our resident base of expertise in the direction of real-world experience.
Besides being a mixture of science and non-science, there is a second dimension in which the academic world differs from engineering businesses. This is the temperament of being more exposed to market forces. For example, software engineers work on projects whose fortunes come and go. They either volunteer to move onto things that look more promising, or are forced to do so. As shown in the famous New Yorker cartoon, at right, the world of turbulent change is much different from their crisp and stable college experience, and from ours as faculty.
In theory, we protect our young students from those harsh realities, but doing so too much is also a dissservice — if we dump them out there without due preparation. The latest flavor of this "reality check" is our effort to increase students' "entrepreneurial mindset." Inventing, pivoting, and killing new ideas and businesses is about as rough-and-touble as it comes, short of being in a war zone. Most new inventions, of either sort, begin with vast hopes and don't last long. It benefits our students to have profs who've undergone that themselves, and who are willing to demonstrate it in action.
This isn't exactly "what Steve does in his spare time" since a lot of it, as you'll see, is related to work.
I think this activity provides useful, contrasting information about classrooms, to the usual student performance measurements, like grades, or to student-provided feedback like course evaluations. I like doing it. I sit in the back and take lots of notes, so the real teacher can see, afterwards, what all was going on as they tried to get students to understand something new.
If you want me to come try it in your class, just let me know!
We did this kind of thing at AT&T. It was enlightening to have someone playing a role akin to the reviewers we use for the articles we publish, but being that expert for our teaching.
AT&T indeed has a grand tradition of observational science, going back to the "Hawthorne Studies" of the early 1900's, which Harvard Business School got involved in. Here are relay assembly workers, around 1930, trying to keep their mind on their work, while Elton Mayo & Co. watch their responses to varied lighting conditions.
As noted in the final section on teaching, above, Steve regularly sits in on close to a whole class someone else is doing here, inside the department or not, so as to learn from that and also have other standards of comparison.
And, who knows?, you might cotton to the same growth preferences? —
Steve enjoys mismatched sorts of people's attempts to be practical or profound. As Shawn noted once, you can't just watch Fox news, or MSNBC, and expect to know more than verisimilitude. Trying to understand what discrepant folk say, from where they stand, is such a challenge. Here's a variety for your consideration:
|The image is a photograph of African villagers in front of a hut. This post card was sent by Pablo Picasso to Salvador Dali. Dali believed that the photo was of a Picasso face (you have to turn your head counterclockwise 90 degrees to see that — ouch). He showed the picture to Andre Breton, the leader of the Surrealist movement, who thought it was a picture of the Marquis de Sade, the notorious, who interested him. Dali rationalized that the individual’s mind gives an image the desired characteristics. He used the image as a model for his 1935 painting, Paranoiac Visage, which includes a like illusion.1|
Feel free to join-in such explorations. The goal is not to explain away these quotes, from your own position. That would be too easy!
As a practitioner of group creativity methods, Steve recommends Synectics, Ned Herrmann and the Creative Problem Solving Institute as fruitful resources. These methods fit well with critical team activities on software projects.
Just lately He's gotten into Idea Keg, which he loves. You grow thinking around a metaphor, then return to relate it to the problem you are working on. It's a cool flavor of "excurting," a word he invented at Synectics.
The link to Steve's favorite brainstorming methods is at the top of this document, under Hot Topics. There's no reason we didn't just duplicate it here, is there?
Left — Peculiarly, the problem does exist, of people being too engrained in a real software development work environment. It's the opposite of what our undergraduate students face. The over-experienced view creates issues when they need to build something new. Here are systems architects in Steve's class at Lucent Technologies, circa 1998, doing a Rube Goldberg exercise to break out of their mindsets.
Need: M L King's "courage, compassion and creativity" are for Steve a pragmatic combination with which to make things syncopate that need syncopation. Other people like this combo, too — for example Judith V Jordan's ideas about how to make vulnerable social groups less so. In computer science we need to be working on such topics like crazy! Say, we keep driving the women out of the profession (fewer in it now than 30 years ago), and we seem not to know why, while also not trying much that's new. (See graph in the table, toward the bottom.) Reminiscent of how the majority used to feel with respect to race relations, when we were unwilling to admit the inequities could possibly relate to our own actions, yet no one had the guts to try anything more drastic. To get effective engineering teams on which divergent views are equally valued, we're going to have to give up a lot — like patriarchal organizations.
The most rewarding, and trecherous, distortions are transformational ones. They involve shifts in beliefs, needs and values. The leaders of such revolutions tend to act as visionary, moral agents seeking converts. Shared leadership and very well organized, dedicated teams are tools used to pull off such difficult, institutional elevations.
What about turning our engineering students into shift agents? We can provide skills and experience at leadership and teamwork. We can coach them to be trustworthy and purposeful, to look for the unique contributions each individual can make, and the of handling problems at the lowest possible level in flat organizations. But, as Bass and Avolio say, there is a constant interplay between leadership and culture — each affects the other.
What are your odds, in a hierarchy? We used to play with this concept at NCR, which had a good-sized pile going until Jerre Stead flew in. If you had to get 5 levels of managers' approvals for a project, going up, and 5 levels of actually implementing it coming back down, and you had a 50-50 chance at each level just because it was a new idea, they were playing the "telephone game," and the proposal could sit forever in anyone's in-box, then overall your odds were 1 in 1024.
Inadvertant change: To accompany the wider influence of today's engineering, especially software products, we are discovering that too many of those building the products and services still adhere to the outdated view that they are only responsible for profits, not for any adverse consequences bound to those. This historical convenience can no longer be taken to be ethical. They need to engage in systems thinking, about what they are up to, using a broad brush on an expansive canvas. Engineering students should engage, as well, in the inverse of pushing ideas out into the world. Namely, absorbing more of what's going on around them — the receiving end.
Sowing the seeds: Being a part of our MACH effort (see above) is an expression of this. Academics are in an enviable position of promoting tampering, technical and social, of staying ahead of the industries they serve, and of leading their society intellectually. Our role is not just to reflect the values of all the groups we serve, though they surely have the right to critique us when we don't do that. The Stanford 2025 brainstorm proposes that the university weave in and out of a student's life at critical points, providing longitudinal support for their careers. This is a forward-thinking initiative, for a new relationship with students' employers. Will those employers like that, or will the rebel? In any case, change is always upsetting; it causes friction in fresh ways; and it has unreliable results.
Right— The Selma-to-Montgomery March, 1965. Would we have had a transformation of US segregation laws, if people had talked but nobody actually protested? In the South, whites felt such actions to be strongly antisocial.
Being a flux capacitor: Rocking the boat is also part and parcel of academia, whether or not it is successful in causing technical or social innovation. This is why we have shared governance and secure jobs. We take a chance that having our diverse ideas heard is almost always better than covering our ears. Even hopeless causes or senseless verbal attacks on cherished ideas have a place here. That strength-through-multiformity has been a part of universities forever; it mimics natural selection in a way. We grow by having more than one gene set.
Some of what Steve does plays in that domain of social innovation. It is an inventive process with communal repercussions, to help our students achieve new kinds of growth.
When Steve switched from industry to academia, he considered both engineering and liberal arts schools. The place for serious engineering is in the world, after all, so both make sense. Lately, the STEAM idea has taken off: Adding Arts to STEM as the curriculum for engineers. This makes great sense to Steve! We would love to be designing unique and beautiful bridges that look like Calatrava did them. We also recognize, as scientists, that designs based solely on common practice are likely to be optimal only in cost, and this because they can be created and effected based on the most well-worn expectations for the way that goes. Not all that enriching.
Some definitions of engineering don't include the artistic part, but others do. like,"The creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, …," from "Canons of Ethics for Engineers." Engineers' Council for Professional Development, 1947.
STEM endeavors like product design naturally involve art, whether or not appearance is the primary purpose. Coming from the other side, use of new technologies and techniques can advace the cause of art. And, artists cognizant of engineering practices have a larger playground to work in.
Steve believes the same arguments can be made for literature, and for the combination of art and literature. As in, this web page. Which is about engineering and its students. And, analogously, from history and the behavioral sciences. Engineering already does history, in the sense of Henry Petroski's books, the most famous of which duplicates my Tacoma Narrows picture on its cover. All the similar horror stories from software hinge on social interaction issues, like lying about progress. Why would they do that?
Throw the L in for Literature, and you can make METALS, among other anagrams. Add history, you get HAMLETS. Add psychology for THE PSALM. Performing arts, anyone? Add dance for PATHS MELD.
Now, the goals of the STEAM movement is to put more K-12 emphasis and money behind Art as well as the STEM fields. And to add art and design to STEM research. And to influence employers to hire people with more artistic qualities on top of technical ones, so that everything we build has greater social value. Turn the ticky-tacky USA into France, perhaps, where dinner isn't dinner just because of the nutrients, and we begrudgingly chow down. Why not move beyond Learning from Las Vegas?
What do we want the artifacts of the 21st Century to look like? And how will they be integrated into our culture? It's worth watering down the drive for better STEM education, to do it with the ingredients we'll want to live with.
Above, right — To symbolize the linkages, Steve sits in his dining room, in front of an oil he co-painted, which shows a modest engineering structure, a wide-mesh lattice, being used to hold-up flowers. Without the flowers, you've got nothing here.
The painting was a two-person effort, a process rarely used in these arts, but common in engineering.
Steve's holding the world in his hand, executive squeeze ball version, courtesy of the NSF Directorate for Engineering, the kind of folks we need backing STEAM, or METALS, or HAMLETS, or THE PSALM, or PATHS MELD. He believes US government could favor making our infrastrcture culturally advancing as well as non-crumbly. One sign shown, that they are "in," letting Steve wear the Hope diamond around the house, as a sign of good faith. In this dreamed partial solution, our doler of prime funding for science and engineering was willing to give something of value to include the arts, so long as the value pool it came from was another government department, and didn't create the feared mission creep.
Daniel Kahneman's ideas on the irrationality of things we think we do rationally — pretty intriguing. E.g., his "experiencing self" versus the "remembering self," who don't seem to know much about each other! This theory has direct application to the things Steve does. How about, we teach heavily experiential classes in software engineering, then expect to measure our success by what students remember, on an exam, or on a course evaluation?
Software projects themselves have problems with these two selves; that helps explain, say, our persistent inability to estimate how long the next project will take. How can engineers underguess the time and difficulty of projects, over and over? Kahneman's answer — they remember them wrong, over and over.
Left — Steve introduces the next activity in a junior software engineering course, fall, 2008 — how to evaluate results of an interaction design study. We use a scaffolding system which begins with us as the role model. Expected flow in such studio classes — See by example how to solve it first, and try it first as someone goes around to help, during the class. Then do it for real in individual homework and group projects. An exam perhaps acts as a final knowledge swell.
What can the students do when it's time for that term project or exam? Probably the things they did when they were exerting the most effort — this will be what's most in play for them, as the new experience reminds them of specific prior experiences.
Asking the same students to evaluate the learning process — this causes a whole alternate set of neurons to fire, and, in Kahneman's view, it would be difficult to make this reliable, because it is categorically different from the thinking they did to accomplish the work. For example, things will stand out like homework, where students pushed themselves maximally. So you might hear, "I could have learned this on my own," and it is a good sign. Or the very recent fact that their project demo failed, leading to, "I didn't learn anything," but because they tried very hard, they indeed learned a lot.
It's the growth area for schools like Rose. How else can we reach our alums to give "lifelong learning," for one thing? Even for undergrads, we need to rethink the right mix of pedagogy and self-taught ("autogogy"?). Steve did a lot of self-instruction courses for NCR, and it worked pretty well if there was sufficient motivation on the student's part. B F Skinner was our hero.
The perfect hybrid model for our future, Steve thinks, is students moving to industry as soon as possible, looking through their work to us, as shown, when they need our help, and getting it instantly. For software developers, the most obvious competition is not Kahn Academy but StackOverflow. It's free, it's direct, it's crowd sourced, and it's comprehensive.
As he writes this, Steve had a dream last night of riding a bike on an errand, using a Garmin-like system for navigation to find a destination out in the country. In the dream, he ended up not at the right location, and the guidance had conked out, so he realized he also could not get back home. This is the irritating regular predicament of software developers, living out Sartre's characterization of how we are aware of the world — it nauseates us and we react. In our profession, something is wrong with the system, and you have to fix it. Or, you have to build onto it in an unknown way to get it to handle a new customer request. At some point in each development, your ability to rely on specific guidance, such as Stack Overflow might give, runs out, and you are on your own.
Left - The moment in a project when you wake up to the fact nothing looks familiar and you don't know what to do next. You already have invested a lot in this ride, but you suddenly have no idea if you are close to a solution. You would like to turn to someone else for easy guidance, but they also seem confused. Just having bull-headed confidence to keep going in the same direction may not help.
I think students have been taught that they shouldn't get into this predicatment, and that the smart people they listen to for advice somehow magically avoid it. This is not so; we just hate to admit it. If you have a Nobel prize, it turns out it's ok to tell that this is just how life is. See Feynman's video.
This, I think is where we would like our distance learner, above, to call his old professors, and describe the problem that's really got him, as best he can. If we can provide general guidance, to help him work his way out of the specific situation, then that affirms our message and he regains his confidence by remaining the prime mover.
So, how do we build such connections to our alums, to improve the quality of the groundwork we provide, so it solves their hardest problems later on? And, even more, we're able to continue being helpful?
Steve should preface this discussion by noting that his department is one of the finest around, as measured by who hires our grads and how well they do in those places. And Rose is #1 in undergraduate engineering schools. He works for a mighty good operation and appreciates that.
We like the fact our engineering is based on science. What about the teaching itself? Can we learn from studying it more systematically? Does the delivery of value to students need a similar depth of underpinnings? If so, why aren't we doing that already?
We live within a social structure, in each of our institutions, and within higher ed in general. As Edgar Schein says, such a culture has "A pattern of shared basic assumptions learned by a group as it solved its problems of external adaptation and internal integration ... a product of joint learning." The artifacts, espoused beliefs and values, and those assumptions, are taken for granted as part of the deal. Successful organizations have this mutual reality; they thus have trouble perceiving problems in any other way, like improving on things which aren't built into their culture to improve. Steve worked for industry leaders who almost went out of business because they were great at what ended up becoming an attackable position, and couldn't believe trouble was coming.
Since we don't try to explore, deeply and objectively, each aspect of how our own business of higher education is done, it's a reasonable guess that there is room for improvement — by somebody! Evidence-based teaching is an attempt to approach this by testing every possible assumption, in a careful and ongoing manner, to uncover what causes effective learning to occur, and what doesn't. Steve supposes that we don't necessarily already know every bit of this, "just because," like Steve's own expressed opinion at the start of this discussion, we think we do, using reasons already buried in our culture.
It's easiest to divert here, to find fault with people we don't actually identify with. Could we get a quorum of faculty at teaching schools, say, to conclude the worst teaching offenders in higher ed are at research schools, due to their having the most status to protect, with the least opportunity to reflect on deficiencies? They are busier with the research. Don't some profs there feel that, if you are a good researcher, you probably can rely on your instincts to enlighten students, as well? Excuse me, researchers — There are no research studies supporting that, and isn't it just a little bit self-serving? You are not innately better people. You have to expend energy and resources to make that research-to-teaching link work. See Prince, et al., 2007.
Yet — maybe we have no right to critique them. Isn't the above paragraph pulled from our own assumptions? Where are actual studies showing we faculty at teaching schools are more effective than they are? So as not to have researchers feel picked on, Steve thinks it's fair to say that we teaching-school profs could brainstorm sizeable evidence holes in what we ourselves do and what we value. Or, beyond that, what we all do in teaching, regardless of our school's points of emphasis. Chew on these colorful research questions:
Above, right — Rose commencement procession in action. Every couple years we ask them for information on their lives afterwards, and some return for events like Homecoming. Yet this is surely not the same as the ongoing flow of information we have about the students who arrived from high school. Is what we need, instead, perhaps something like the persistent contact proposed in Stanford 2025?
Above, right — Rose is known for providing rigorous engineering training, and this includes making it as close as we can to real life. Here, another team in Steve's first Rose class does the "final exam" on software requirements, a presentation describing their results in apprehending those and developing a prototype. Do they look concerned? Their real client was in the room, asking questions. If Steve moved more in the direction of treating students as customers, would he put them through that, at the start of their junior year?
Steve has a lot to learn from this movement, too. He loves to lecture, but there's no proof that produces learning, either. It works if you tie it to students practicing. But then, they might have learned just from the latter, too, as you went around answering questions, studio style.
Looking at our college teaching from a variety of such contradistinct directions, and doing serious studies on these topics, is going to be refreshing, Steve says!
There is no evidence, BTW, that changing font color improves reading comprehension. But, have there been any studies? It's like highlighting, but done by the author. Who thinks it's all good stuff, naturally. What's your view? Worse, or just unfamiliar?
Steve loves being ahead of trends, as you can tell reading about his past history. Here's a new one to latch onto...
The need: To be effective, Steve's students must understand people who are not like them. Different looks, different values, live in different places, eat different food. Trading in this commodity is not optional; if you choose a software job, the reality will be built-in, over your career. Customers, coworkers, investors, competitors, hackers, and all the other affecting parties will be diverse, and they will need to be understood. Ethnocentrism won't cut it, in the job they are about to undertake.
Why it persists: Steve's thought about this ignorance of outside realities, which feels peculiarly endemic to coders. Maybe you have, too. "Agile" is an attempt to overcome that by having a customer representative essentially in-your-face constantly, and evaluating progress vs a releasable product, at frequent intervals. It's a start. What else do we need — maybe a video of the customer's people using their existing system, playing in front of you, like the panoply of images at a sports bar, as you build the replacement? More on Agile, farther down.
The fix: Today the bar for involvement, to understand stakeholders of engineering projects, is ethnographic studies. These embrace a careful, active learning about people and cultures, exploring their situation and interactions, as if you were one of them.
And why it comes slowly: It is normal for every cohesive academic department to be its own "in group" with an esprit de corps and natural defenses against the outside; and for them to feel that their topics of study are special, in ways that other disciplines lack. After all, they coalesced over sharing a strong interest. The traditional core of computer science has been the theoretical part, and feelings of kinship revolve around that treasure. Resistance would be expected, to valuing equally the much less technical users of the products produced from our theory, valuing people who are in many ways not like us. If we graded them on knowledge, like we grade our own students, they would get F's. Shouldn't our sapience, about what they need, prevail?
Right — Typical ethnographic study in action by Interaction Designers. De Angeli, et al (2004) making an affinity diagram out of individual points recorded, while observing Indian ATM usage.
This is the real test — whether that is women, racial and sexual minorities, "foreigners," or "stupid users." The ones most ignored, who actually make up a significant audience for software products, would be most profitable for students to know more about. Furthermore, studying those felt to be least like the student base, itself, would be a proper learning stretch — truly testing if they could empathize with and be taught by people they might not like.
State of the art: Trying to learn the life of others who have reduced status, as we see them, is very challenging! The studies are time-consuming and require someone to be flexible enough, in Milton Bennett's terms, to identify with a target group. Alice Goffman's recent book On the Run: Fugitive Life in an American City is a perfect example from sociology. She studied and lived with black, low-level drug dealers in Philadelphia. She is currently a visiting faculty at the Institute for Advanced Study.
Above — Want to do a longitudinal study here? This is the area where Goffman did hers. Someone has to be willing to sacrifice their normal environment, for a good long while, to accomplish something likely to benefit everyone, and also likely to change you, the person most involved.
When Steve worked for NCR's retail division, he trained with new department store clerks, and then observed them in action, so as to try writing systems for them which would be categorically simpler to use. No one had done that before. Even this amount of effort, away from regular work, had to be explained in a special way.
In our patriarchal organizations, we are assumed to be paid for already knowing how to do the right thing. Everything should be crisp, like standing at attention. With engineering projects involving novelty, that pretense is patently false — there is a large amount of risk. Being paid to do things over again is worse than being paid to learn, ahead of time, what you don't know but could know.
Liking lessers rubs off: To proponents of ethnographic studies, a part of the critique they get is based on the "courtesy stigma" problem. The person studying a stigmatized group tends to get the same treatment the group does, from their "betters." You see this effect when anyone in a social group opts-downward or otherwise becomes associated with lower status.
Are we already doing it? How well does software development pursue serious studies of the main stakeholders? One could argue that Agile doesn't quite do this — Agile conveniently, if profitably, focuses on the client, the one who pays. Aren't they often another stuffed shirt, hoping to push a new way of doing things onto the system's users? Now, there is this extra step you can do in Agile, one that many groups do, of keeping a larger circle of stakeholders involved as you develop. This is shown in the figure, above, of Extreme Programming in action. User stories essentially come from outside, under the control of the customer representative. User involvement between users and the team primarily comes from reactions to acceptance tests. Greater value would accrue from having developers who are and feel tuned-in directly to those other people.
Looking at some of these Agile processes with hindsight, they dealt with the perpetual problem, of insufficient customer contact, by convincing at least one customer representative to dedicate a lot more time to the project as it is being developed. As the Mountain Goat Software site describes this for Scrum:
Above - See discussion in the next blue block, below.
With Scrum, this representative, again, typically has generated user stories off-site, likely involving their users directly. But they often were left to explain these snippets to the developers, and to detail them as needed, or as creativity drove things. Dealing with real users directly was left, again, as part of the process of verifying the regular output of the system. The developers showed it to the product owner, who may or may not show it to a significant number of real users, until the product is first released. Adding more user verification is often done, as noted, but it's outside the Scrum process and likely out of view of the developers. There's still translation going on, between two different worlds.
Wait, there's more growth to be had...
Meantime, here's an ethnic interlude, an instance of a student being thrust onto the world stage, in a culture clash, having to defend her design:
In 1979, the Vietnam war memorial, now on the Mall in Washington, DC, was designed by Maya Lin, then a 21-year-old architecture undergraduate. Her unorthodox, simple style won out over 1,400 competitors. It immediately came under fire, because it clearly symbolized the loss America suffered in that war. It's an open wound in the ground, with the names of the deceased soldiers inscribed on its walls.
Many veterans, politicians, critics, and the general public read its refusal to explicitly glorify the war or frame the listed soldiers' sacrifice in heroic terms as an ideological statement, proof of Lin's — and the memorial's — anti-war position. Ronald Reagan's Secretary of the Interior, James Watt, was openly against it.
Opponents of the design also voiced objection because of Lin's Chinese ethnicity, because of her being female, and because of her lack of professional experience. The young architect had to go to Washington to defend her work in a public forum.
This rapid growing up she faced was unusual, but it did happen. Maya Lin didn't have to do an ethnographic study; the study came to her. If you were one of her professors, what would you have advised her to consider, and how would you have recommended she respond, in those circumstances?
The structure has since become an important pilgrimage site for relatives and friends of American military casualties in Vietnam. What you see pictured is a common occurrence there. In one single act, Maya Lin redefined, perhaps for all time, what a war memorial is.
So, someone like a Product Owner might be a true advocate for users, or not, but the developers' link to user knowledge was indirect. If you go back and review Ward Cuniingham's video, about why he invented the term "technical debt," it was because his group of developers, talking with clients, made assumptions about the real use and needs, which they later had to work around.15 As he says in the video, he is never in favor of making bad design decisions on purpose, even to get the product out fast. Technical debt is largely unintentional — the inverse of "YAGNI" — you don't know you're going to need it.
Above right, in the prior column — Twenty years ago, at AT&T, we knew the issues of relying on one client representative explaining requirements to the development team. They only asked for the "Swiss cheese" in the middle, ignoring the rest that's in the large, surrounding Real Problem Space. Many of these missing needs, they expect to get anyway, for one reason or another. Clients often assume the developers have more familiarity with their world than is the case — a great argument for ethnographic studies. Or, they wish this to be so. Or, they just get tired of writing things down.
As noted in the image, there also is a historical bias toward talking about specific features, versus quality attributes. The client may assume the system will be "lightning fast" and "never crash," without ever discussing these topics. What gets built then is this evolving system (the gray blob), which slowly incorporates all the unspoken or unclear features and attributes, largely from feedback in the form of trouble tickets and change requests, up to the point of what's pragmatic or economical to build.
OA&M was the telecom term for what it takes to help keep the system running — things we now might try to manage more carefully with a cooperative DevOps effort. They tended to be left unspecified so much that we considered them non-functional attributes, versus features. Studies of systems we built showed they could represent half the development work.
Impact: In sociology and anthropology, deep studies have been influential in changing minds about what Western people think of minorities and people from far away. In Steve's generation, many of us read The Children of Sanchez: Autobiography of a Mexican Family, by Oscar Lewis, which told the daily lives of members of this family, in their own words. Studying stakeholders very deeply could have a large impact on software developers.
The need to go all-out: You can't exactly dabble in ethnography. Taking on timid directions, to emulate and study, obviously is avoiding the problem of dealing realistically with difference. Which is, Steve thinks, a problem for computer science. For example, he has asked his teams to go visit non-profit clients of senior projects, in their natural surroundings, to understand what is valuable to them in their daily lives, which could lead to different decisions about what the students build. Getting them to do this is like pulling teeth. This absorption-of-values is soft learning, and it might be distracting; it doesn't fit their pressurized world of only doing what it takes to get a grade. While they do senior projects with more intrinsic umph, the request is still outside their normal boundaries. Is the solution to make them do that extra work?
Above, right — Ethnic garb in action: This is a well-decorated, traditional tunic, punctuated with a Ganesha pendant, both immediately identifiable by everyone at Rose who is of South Asian heritage. The occasion was one of our career fairs, and rain was expected, so Steve considered, while still at his apartment here, and mostly for fun, how the garb would come off as he walked to and from the fair under his umbrella. An Indian student he'd not met before said, "Nice kurta," as the student came in the entrance to find a job.
More serious, on that occasion, was the question of reactions he would see from the people there to employ Rose students. Got some thumbs-up, and some looks of astonishment. This is what Steve would describe as a "non-timid direction," in ethnographic studies. A direction where you feel the "courtesy stigma."
Gains: Negotiating directly with a client, as is done in Agile processes, has improved the position of software engineers in their organizations — they have more power and prestige. For example, if a project is late, no longer is this a call for management to crack down on them. It is assumed, on the contrary, to mean that the original estimates must have been wrong. If, in addition, developers knew the needs of other stakeholders, especially users, as well as or better than the client, they would be in the best position to argue for the best solution. We see the latter in software companies, such as SAP, who know as much or more about "the business" as the customers they serve.
For our students, trying ethnographic work might be a rude shock at first. Some, after all, came wanting to write things like games, which appear to give you almost full control over the whole product. Your own imagination and coding skills cause the app to arise. However, that is not the world of software development most need to learn about.
Right — Setting-up students in situations outside school, in someone else's environment, could be even more stressful than what they undergo in their routine classes. Suppose the people they are supposed to observe don't cooperate, but their grade depends on completing the study? Intrinsic motivation turns to mush.
For college students, stigma, or fear of stigma, is this regular companion anyway. For example, one in four has a diagnosable mental illness, 40% of those do not seek help, and 80% feel overwhelmed by their responsibilities. We all stretch to be compassionate, but many factors work against connecting with students in trouble, including feeling inadequate to help and the constant pressure of our own work. "The system" we perpetuate here rewards high achievement, increased intellectual sophistication and ever-growing self-reliance; students thrive on achieving these goals. Conversely, missfiring on them puts you down, including professors giving you bad grades to make it official! It's your fault. If that isn't stigmatizing, what is?
Steve thinks it will take time to learn how to pull off this broader social interaction, generating the desired impact on our students. We want to do it, and we want it to be a maturing experience. How do we know who's ready for it? In our department at Rose, we've already experimented with giving students large, multi-team projects having outside clients their junior year, then pulled back for various reasons. You want to be on the forefront of preparing them for industry, but it is tricky business.
You will find interesting results, if you study a minority group, say, or a class of people not so good at software skills, hard enough and long enough that you identify with them. You might cringe, for example, whenever someone says, "The problem lies between the keyboard and the chair," and laughs. Or, you might feel dread when a colleague observes that students from a different culture tend to cheat on exams, instead of nodding as if that were based on solid statistics.14 You might even come to question, for the first time, why you are living in the suburbs.
So, Steve believes the challenge is out there, to generate people for industry who can do this work. Which means confronting them, while they are still students, with the need to do it, so as to understand others they need to understand. His start on this is to represent outside groups himself, challenging his students to analyze why he would do that, and challenging them to think like someone else, too.
Universities grew out of guilds in the Middle Ages. The guilds were there to solidify the position of local tradesmen, with elements of unions and secret societies, among other things. Many of our current operating philosophies, like academic freedom, go way back into this tradition. However, these traditions also tend to perpetuate our methods of operation as being de facto correct, without further investigation. Maybe that idea is at least worth revisiting, especially if there are alternatives waiting in the wings.
Here are some other choices now! They all fall under the general category of making "how" we do things more obvious to various parties, such as our students and the companies who hire them:
Model your customers, to connect with them. This does not mean change everything wholesale. It does suggest that, if we have processes that are like our customers' processes, and organizations like our customers' organizations, and adopt best practices like our customers' best practices, then they are much more likely to find us and our products interesting. We speak their language, using "operational definitions."
Steve supposes this model asks the question, "Who are our customers?" He thinks it would be a mistake, in this context, to say that is our students. Our real goal isn't just to attract students, no matter what becomes of them. Modeling incoming students more seems a bit crazy, too. Our larger role is to put them into roles of technical responsibility in society. Which makes society and the hiring companies our customer. In a fundamental way, we sell students as a product, into industries where they serve society as scientists and engineers. Students come here, and their parents send them here, increasingly, because we can do that.
If students are a product, why are they paying us, you ask? The student ends up as the major beneficiary of their education, including getting paid directly by the companies who hire them.
So, what if our default model, for processes, organizations, and best practices, was, "How do our customers, the hiring companies, do this?" There may be a good reason not to do things that way. But, this seems in general to be a more valide default position than, "We have to do it that way because that's how they did it at University of Bologna in 1088."
Around 1990, the idea of modeling customers became popular in the business world, because it created intuitive links with them. Customers didn't need to ask what to call organizations they wanted to get in touch with at a supplier, or what they did, because the terminology and function was the same as in their company. Today, this notion has grown with Supply Chain Management (SCM) to become Business Process Integration. It involves "collaborative work between buyers and suppliers, joint product development, common systems, and shared information."
Left - An example, from Forrester, of business-centered integration with outside stakeholders. What people in your organization do, and how they interact, is all tied to what these other parties do, and how, and it's all supported by underlying business systems.
For us, an example of this integration would be that our customers have a distributed database of possible candidates for positions in their technical organizations. This includes Rose students and alums, and current listings of their skills can be matched to these jobs. Making that work well takes an SCM approach.
An instance with more ripples is to model customers' business practices, in the teaching we do. If they are all about "lean" and "agile" types of engineering, wouldn't they love to know that students already are a part of such organizations in college? That would mean using a sharp knife to cut back on hoops you have to go through to get things done, say. And being able to show you found the most cost-effective way to deliver quality.
At Steve's January, 2016 "lightning talk," he proposed that new course developments include showing how steps had been taken to find existing materials elsewhere, or sharing the work with other institutions, before accepting that we had to do it all ourselves.
Show students you model your customers: If we wish to teach our students best practices by demonstrating them, then "transparency" means including these in our academic activities. Our modeling of technical expertise is at the heart of students' believing they should grow in these areas. If we don't model the social skills we want them to have, what message does that send?
Steve's example of choice is teamwork. We want our students to leave Rose showing exemplary teamwork. It's an advantage that they get more understanding and practice at that here. However, we do not usually demonstrate our doing it in our own work. If courses were developed collaboratively, it may all have been done out of the sight of students. How many courses are team-taught? One might even conclude that we are less good at this skill than we ask our students to become. Why is teamwork not a priority over getting individual credit for academic work?
Right - Team teaching in the MBA program, at the University of Houston-Downtown: "Each course in each of the eight corporate driven concentrations/graduate certificates will be team taught. Along with one of our excellent College of Business professors, you will find a seasoned expert from the corporate community to team teach the entire class. Both of these talented professionals will be in the classroom for the entire class for each of the class meetings. Since the class is flipped, the lecture material will have previously been provided by the College of Business faculty member for each class. This allows the entire class meeting time to be devoted to ensuring the members of the class understand the application of the material."
Going agile at Rose: Steve's next extension of best industry practices to our college environment is to make course development "agile," like the software development our students do. How is this different? One big change is that, with agile course development, you would never wait to show the results to a customer until the thing is done. That's out of the question. Instead, you show each piece of it, at regular intervals, to some sampling of customers, as well as getting their advice just prior to doing an iteration.
In other words, students would get to peek under the covers regularly, and advise us on how to build the next course for them. This is beyond typical "problem based learning." Knowing the problem at least some students want to solve precedes building the course.
Steve's first attempt at this was doing a course in Software Project Management, for which he enlisted working professionals as advisers, during the development. In the first iteration, which was done live at Raytheon, students selected topics for the rest of the course in the first class session, with fine-tuning at each succeeding session. Beyond this, after each class, students went to their colleagues to ask their opinions of the lesson, and returned to share that information the next week.
The followup version was online. Here, remote advisers were enlisted. Got some good feedback. Need to work on making that even more effective. For both undergrads and grads, there is a question of getting their attention often enough. This also is true in software development, regarding keeping the customer in the loop. Steve has some strategies in mind, to help this along.
In industry, the traditional course development model we use is called ADDIE, which stands for analysis, design, development, implementation, and evaluation. Sound familiar? But this model is analogous to the Waterfall engineering model, which is fading in popularity, especially for software. There already are initiatives about switching to something leaner.
Here's an example, from "Bottom-Line Performance." Note the cycles of verification, with the client, as the course is being developed. Note also the name of the company, which derives from the commonly accepted high standard for proving that industrial training is effective — namely, "Can you prove it affects the bottom line?"
Steve's always willing to work on novel and risky projects; knowing how to cut those risks early — he hopes! All the tough stuff Six Sigma saved for later! This feels like why we have tenure. Let Steve know what you need help with!
Left — Vern Law, a pitcher for the Pittsburgh Pirates, circa 1960 when he won the Cy Young award. Law famously played through injuries, and was known for saying, "Experience is a hard teacher because she gives the test first, the lesson afterward."
Strikingly, we now do that to students, to determine the true gap between what they know and what they need to know, tuning the lesson.
And, in the software world, this is now how we build systems. Our code inevitably fails the test, the first try.
Throwing the high hard one — Steve opened this home page with the Langley Aerodrome taking a big drink, and noting that academic engineering projects tend to be suspiciously crisp and limited to what's just been taught. Like Vern Law, he tries to pitch his best stuff every time, and seeing what undergrads are capable of — that's definitely in the mix. But, how do you do that? How do you make academic actitities more realistically complex without coming up empty? Here's stuff Steve's tried, all of which he still believes have (has?) promise:
More tips follow in the next section...
Computer Science undergraduate curricula are almost fully founded on the premise that we can teach a foundation of theory, to make students as prepared as they can be for work in the software industry. Or, this is what's by far most important. Or, if a wider view is taught, it's for someone outside the department to do. Still today, you can't get more practical papers and workshops into the annual US conference on CS education — Steve's tried and gotten a reaction like, "If you could show how this industry-related topic could be worked into existing CS curricula without disturbing anything, we might give it another look..." The real job students need to be prepared for is officially off the radar.
At odds with this convention is the fact 43% of current engineering jobs in the US are now in software, which wouldn't be the case unless a huge amount of the work were integral to larger concerns.10 A small percentage of the software industry work is just "about software itself" — like if you're fixing a compiler. The rest of the software engineers are building apps for smart phone users to do something outside the CS world, or the software layer for a device other engineers are building, or web pages in an IT organization, etc. And, most of these people will switch jobs frequently in their careers, moving from one vocational area to another, and from one knowledge base to another as they do that. Some will work for software consulting companies, where they will change to serving a different client with a new set of requirements, on a regular basis.
The real theme our students need to be ready for is sudden variance in what they are trying to accomplish, and how. Every new project they start, for every new customer, will serve-up a giant dose of novelty. It's like you come into work every day, to a plateful of Christmas crackers, a layer of undecidability Alan Turing never anticipated.
The inherent empiricism of software development work is at loggerheads with a school discipline which emerged from the math department, and values only rationalism.
Our pedagogies to go with, founded on Vygotsky's "zone of proximal development," favor only slowly creeping away from fundamentals, creating a student mindset that everything new will be quickly made familiar. In their careers, this won't be so. In our curricula, we ooze from data structures outward, slowly but surely. Anything far afield is not to be trusted, by us or by our students. Both sides are timid over jumping into the new. Which is the major psychological event software developers need to be good at. When is your last observation of a professor intentionally put a problem on the board, which he didn't know how to solve?
Right — Here's our Depression-era model of how to build courses and curricula. The goal is to get to what's "out of reach" eventually, if it's in the scope of what should be taught. However, inching along, always staying in the safer areas, tends to have a Zeno's paradox effect, with everyone focused on what we "almost already know." It creates unrealistic expectations, and a false sense of security, studying an industry which, in reality, is always lunging into the unknown.
Steve believes it's time to rethink this formulation, of what an undergrad CS exposure should be like. He tries to cast students into the unfathomed directly, like fresh sailors into the deep water, so that they learn to survive there. Steve's office, appearance, and this web site are three examples of that.
Left — Plane crash # 2 for this web page: 1918 metaphor for the most common test result with industrial software, unlike student projects, which are preset with a level of difficulty to let most be successful before the project is due.
Connecting to something completely different...
The image is from an article concerning dictionary compilers (people). The author was in fact lamenting the practice of making current usage the standard for acceptance of words. The word "aerodrome" had just been dropped from a dictionary he liked, using that criterion. Sounds like Zeno's incremental cousin, maybe, another way to creep curriculum growth?
Software architecture is uncommonly wrenching since we "live with" designs as long as possible; total redesigns happen infrequently enough that a team forgets how nebulous the experience is. In the Agile world, it's almost obligatory to start coding as soon as possible, and downplay the need for in-depth design first. This speed-to-show-code bent works for things that are just slightly differential, or for school-sized projects, but not at all for majorly new projects. To convert your product to a service, glossing-over the design issues, and uttering "YAGNI" at every turn, leads only to redesign. Once again, we practice at developing the wrong set of hunches and expectations.
Now, you may be thinking, this predictable, incremental, comfortable learning is what our students expect, coming to Rose from high school. In the same way, it is not what they will be faced with in a competitive industry. Over their time with us, they need to be shifted, hard, toward the expected learning model of their next world.
What is the right rate for nudging baby birds out of the nest? A nice, slow transition over four years would be nice, in a way, wouldn't it? Yet there also is the problem that most of our students can't get industry-related summer internships for after their freshman year, and some for after their sophomore year. A part of that is because of the technical classes they do / don't have under their belts. But another factor is their "perceived maturity," by the hiring organizations. To the extent this is internal, brain maturation, we may not be able to speed it up. But, to the extent it is controllable factors, like learning to accommodate open-ended problems because we challenge them with these problems, let's help it along!
Role hopping: You cannot know what is ethical or just, to someone else, until you walk a mile in their shoes. After doing so, you may still disagree with them, but at least you know more about why they believe and act the way they do. Now, you can think of situations where you would not even pretend to see it their way. For instance, someone with greater power who is taking advantage of it. However, Steve feels that, the more we can try empathy, the more perspective we have in making engineering decisions. Working hard to understand people with less power than you, or less than their adversaries, has the aura of things we should not ignore. Even striving to get an equal, who is just different, makes sense.
It is hard to for us to see issues from an opposing perspective, when both sides have spent time building-up arguments against each other. We see this phenomenon most clearly in politics, or where money is at stake. A challenge to Steve's students would be to find a hot topic that you feel passionately about, then take the other side, honestly and sincerely, in an open debate. We have done such things at Rose.
A short presentation: In the slide set on ethics in this directory, which you can click on via the link in the opening section of this web page, some examples are presented as discussion material. The slides are intended primarily for software engineers and their project managers, particularly for people making the transition from one to the other. Things look different if you are officially responsible for the actions of a group. Many engineers don't understand that viewpoint. It is worth trying — for one thing, with flatter organizations, more team accountability is in play, at the expense of finger pointing.
A great instance of an ethical choice, for an experienced engineer on a team, is whether to spend extra time and effort helping new team members, or whether to spend that getting the job done yourself. Sometimes the choice unfortunately comes down to whether or not you like the new people. Here's a new engineering team checking out a fresh feature. If you were the person on the end, would you feel included?
Bases for the codes of ethics: The slides also get at underlying values, those responsible for our official codes of ethics and such. Like IEEE and ACM. One of these generalities is that engineering is inherently altruistic, that we are there to do things for a larger group of people who cannot do that themselves, and they are the main party to whom we bear responsibilities, not just our employers. Another "metaethical" point, discussed in the slides, is whether decisions should, at the very core, be based on emotion or reason. Famous philosophers have come down on both sides of that.
Living in a business world: For engineers, as professionals, a confrontation to your moral fabric comes when your company takes a one-sided point of view, on a public issue, which is clearly motivated by profits. Or, as the company would put it, an unjustified attack on its very existence. Suppose you worked for a coal producer, say. Would you dare to speak out in favor of international agreements to cut back on emissions? Such questions may require you to go back to a metaethical point you believe in, to decide what to do. To whom is your real obligation, and what sacrifice is that worth?
Self-diagnosis: Steve's favorite ethical topic is "blind spots." These are places where we have always assumed we know the right thing to do, that decisions in these areas are just like others we know must be right; but actually we produce results that we wouldn't want, acting on those righteous hunches. Or, we get unexpected resistance to our judgment call, in this particular case.
The instance described in the slides is "gender considerations." Men in engineering tend to go with clear-cut rules for everything, believing that the rules stand above any one person's individual opinions or actions, or situational variables. It has never occurred to us that women in engineering might not believe quite the same way. Women may be more likely to step outside the rigid form of a rule set, allowing them to act more caringly within a given context. The fact men think much of what we do in engineering falls within a right-or-wrong context is, itself, a masculine way of approaching engineering. It's possible that men and women engineers, generally, tend to have blind spots in somewhat different ways.
Pointing the finger at someone else, regarding blind spots, is a dicey business. They may be aware of your blind spots, too, or feel provoked to come up with one. A greater personal challenge is to listen to their side, or to do an internal analysis of your own side, looking for imperfections and how to fix those. If you are a person in the US in Steve's age group who wants smaller government, do you dare to open with asking that Social Security be reduced first, the hand-out that you benefit from? If you want more government services, do you dare ask that your own taxes be raised first?
On engineering teams, Steve saw blind spots all the time. Part of his job in industry was to evaluate the likely success of projects, prior to the time they had spent most of the money. Teams very much get into a habit of "group think" after they've been in motion for a while. They can be like technical Branch Davidians, or badly out-gunned armies, sharing very specific beliefs about how things are, and how they will end up, which almost no one on the outside would agree with. (Of course, sometimes the most internally synchronized groups are right and everyone else is wrong.) In recent times, the ethics has been questioned strongly, of continuing to do a project death march without regularly stepping back to get outside verification. In software development, the Agile message is all about constant revalidation of the effort.
Left — There is advice out there about psychological blindspots. This article was intended for leaders who might base their next actions on past successes, believing their hunches will guide them correctly the next time, without double-checking those.
Current experiments, of how people act, have shown that our shared wisdom about ethics may need more study. Duke University's Dan Ariely found that college students often cheat, given the opportunity, if they know they won't be caught. But most only cheat up to the point that they can still feel good about themselves. There has to be some saving grace. They were much more likely to cheat, for example, if they saw someone they identified with doing it first. And, reminding them of ethical obligations before an exam did prevent cheating. Steve believes such variables in behavior are not just true for college students — more likely for all of us. And, in particular, such things surely are true of practicing engineers. If we each started the work day reciting the IEEE Code, probably we would occasionally make a different decision.
Did you mean to do that? Stretching the realm of ethics even farther, we can consider people's "intent," in the same way the law does — or not. Did the engineer mean to cause something to happen, or was it an oversight? In a law suit, this is the difference between tort and negligence, when someone has gotten hurt. If you knew the ignition locks would break, with likely bad consequences, and you built the cars with them anyway, that's a tort. As a guide for personal behavior, however, this difference is more subtle. If you saw a system artifact that had a defect on it, noticed it at the time, but forgot about it, should you feel guilty of something? You didn't really intend to put out a defective product, or did you? In software development, we all have passing thoughts about what could happen, and we dismiss a great many, as we switch to working on something else. In analyzing projects with a review team, Steve very often found that an issue, brought up by one of the reviewers, would get a response from the development team like, "Oh, right, we did talk about that at the time, but never did anything about it." So, there are many levels of consciousness of issues, including group memories of those, which vary all over the place. Somewhere in that fuzzy mangle of ideas, the question of "intent" may come up!
Are you sure? If you start reading about the unconscious mind, like Freud or Jung, such matters could drive you crazy. Stuff goes through our heads without our knowing it, and influences our behavior, occasionally bubbling to the surface enough that we become aware of it. A specimen here is how, when one of your parents accuses you of something, or even hints at it, you tend to believe, suddenly, you must be accountable for that. The same thing happens if, say, a high enough level executive in an organization allocates blame. At some level, thoughts along the lines they are suggesting might have occured to you. Or, they might be planting these thoughts as you listen, deja vu like. It is impossible to know, because of the intense dynamics of the situation, and the way different trains of thought come and go for us. If this is how we really are, with only some control of what we do and what we remember of that at any given time, how do you exercise a clean personal code of ethics?
So, ethics is an area Steve explores regularly. You can't exactly call it "fun," because the stakes are so high.
Programming in Java. Like life, Java can be self-referential and so lovable — incorporating as it does such artifacts as good old loops, recursion in general, and inner classes operating on the things defining them. Decent for searching, like puzzle solving. Biggest recent improvement is the ability to pass methods like objects. The AI people wanted this in Java from the beginning.
Favorite used to be Lisp, but then it slid out of fashion on a banana peel of right parentheses. Care for a lambda joke? Question: "Who had the best argument for the lambda expression?" Answer: "Don't know — the whole thing was anonymous!" Ok, that was an awful "funcall." Don't "evaluate" it.
Before that, Steve thrived on assembler, long ago when you had to. It was thrilling to create commands, stick them in place in front of you, and then fall into them, like a somersault, for the machine to execute.
Right - x86 assembler in action. This function divides an unsigned char by 61, faster than if you used the machine's divide command. A couple comments to that effect would be nice, huh. The stuff shown would still run on a PC. See here for a short intro to the language.
What are we doing, really, when we code? What blows Steve's mind about modern programming tools like Java, is that they are places where we define new language, continuously, extending what has meaning in our universe. Like, a new OO class you invent is really a fresh semantic entity, which you can now use. This makes us coders all "authors," of code versus "writers" or "scriptors," in the sense of some postmodern philosphy. But most of them objected to giving an author credit for real creation, because what we all do is as well based on the world we live in. Recall that OO intentionally is this — the original goal was modeling parts of the real world conceptually, in code. Our works are so a product of our time and culture. And the meaning changes as those factors advance. This web site's HTML could be critiqued for not using Flash, interactions with the reader like links to Twitter, and other new tools, say. More so as time goes on.
We also face the problem cited by Derrida, that the full meaning of what we do is deferred, depending on what happens in the machine, for us, and, usually, how humans react to that. Final outcomes typically are a surprise to us because they include faults and "user errors" we didn't foresee. Our "reader" who reinterprets a text, is that "user" of our systems. They are even more removed than readers of books or viewers of paintings; they don't even digest our code, as such, but react to what the system, that does read it, shows them.
To link our acts to philosophy even more, most of our software has very blurred authorship, making it almost impossible to infer intent and motives — we have to rely on just the text of the code itself, Barthes-like, in any later analysis. Some code is even crowd-sourced. You can't ask, the way you can for the single-authored painting my daughter posed with, at left, "I wonder what he meant by that?"
Barthes emphasized how reading texts is a disjointed experience because they all have incongruities, interruptions, and breaks. Now consider what the source code for Microsoft Word, started in 1981, must look like by now. Like, what code fires when you back-space? It can't be simple. If Word just inserted something automatically, it takes that out instead of undoing what the user just did. But it didn't used to do that, so there might be some hacks they keep living with. One of our department's alums maintains that code, and has described, to current students, these issues in trying to recapture the intent as he makes fixes and changes.
In his 1969 essay, "What is an Author?" Foucault raised the question of a work having validity because of who it is attributed to, disagreeing with Barthes' position that this doesn't make a lot of difference. In scientific publications, we rely heavily on the identity of the author, in inferring value. In music they do the same thing: If Mozart wrote it, an orchestra will play it, and they will try hard to play it well. Isn't it peculiar that, for code, which has to be written so correctly to run correctly, we aren't as fussy about the identity of the coder? Whatever the reason for it, is it the same underlying reasoning which causes software, largely, to reject the notion of certifying individuals as worthy to code? Like, other engineers have FE and PE exams, and licenses. IEEE does have certification programs for software engineers, but few employers demand them.
Above, left — Too Close for comfort? Steve's older daughter poses in front of Chuck Close art work at the Boston Museum of Fine Arts. The whole painting, broken into a fine grid, is a portrait of Paul Cadmus, who also was a painter. On the right, Steve gives his daughter herself, deconstructed, to study, on the left. Which is appropriate because she is a deconstructionist by trade. In particular, providing new ways of looking at Renaissance texts. In the image, she investigates her own meaning, from an external perspective, resulting in new value from each element, as it is pulled from the whole, akin to inspecting the parts forming the painting's background.
The idea of deconstruction is not just a closer analysis in the usual ways, but understanding how ideas were intended to be interpreted, and how they are or could be interpreted and related in an alternate frame of reference, including looking at underlying assumptions and finding unavoidable contradictions. As an example, our ideas of hot and cold are supposed to be simplified temperature opposites. But in practice they are interdependent judgment calls, relative to the situation. They are often invoked to mean, instead, "too hot" or "too cold," as in more than regular hot or cold, conflicting with their own pure meaning. As part of a social greeting assessing the weather, they are surrogates for demonstrating agreement about our world view, and much more. Other languages have varying terms for gradations like "cool" and "warm." There is no absolute meaning for this contrast. But you have to be exposed to other cultures to know that, and the usages also vary over time. In mid-fall, freezing temperatures would feel cold. At the end of winter, you might describe them as a warming sign of spring and push back the hood of your parka. The possibilities for meaning are open, at any moment, in the play of differences and relationships one perceives. The point is tha, as in the image at right, t we want hot and cold to be absolute, contending opposites to choose from, and thus have undeniable clarity in our communications with others, as if we were speaking from on high, but they aren't that way.
Like others, Foucault brought up the issue that writing is a way of immortalizing yourself. Steve feels this cause also transfers to writing code. You move on to the next project, but what you did on a successful one could live a long time beyond when you worked on it. Code slinging is a way for us to amplify and extend our effect on the world. You see this in the way people are proud of, and protective of, programs they wrote.
It is curious to read these Post-Modern essays, considering software as an example of the "texts" they discuss, as you capture the intent of the philosophers' own "texts."
These literally deliver the goods as a paradigm you can start a project with, then design with, then use to verify that the resulting system meets the requirements. And preserve as business knowledge everyone can comprehend, for the next system. See for example Alistair Cockburn's doc describing how to accomplish this. We did things like use cases in the 1970's, but we made the mistake of trying to grasp them in complete detail the first try. Use cases are closer to an artifact you can write both integration and acceptance tests from, in comparison to user stories. Indeed, maybe they are indistinguishable from a decent test plan?
Steve was once asked to evolve the C-code for a system that semi-automated this end-to-end flow-through from requirements to test cases. Then he heard it was Kernhigan's code, and pictured how intricate that C was likely to be!
It's odd how process tools like use cases become trusted, then distrusted as development process styles morph. See the picture, below, of Steve's students ten years ago, still not sure on the subject of this new-fangled tool. Now it's peaked, then fallen to # 2 in popularity. The way Steve employed them in industry was close to optimal, finding knowledge experts who actually could say a preferred sequence for things to be done, as well as the nugget of what had to be done, when they knew this from a business or technical process vantage point. Like, he got the master of network diagnostics at Lucent to explain how the analysis should flow for a new node to go in that system. The current idea, that you shouldn't write this down first in English, for them to verify, but only in code to show them, though trendy, may not always be best. Steve had to take days on the expert's clock to capture the info just described, because nobody had done it in English before; it just existed in other machines, written in other languages. There was no shared IP.
Gotta agree it makes sense to go for user stories first. But, especially if you want to be a player in a particular "business" or type of system, it also makes sense to have a sharable version of the most specific set of real business rules. You can easily write and rewrite MVC "controllers," for instance. You can more quickly educate the new people. And, if this is just a one-use job, still, why have the client or user tell one team member how things need to work in detail, and you try to keep that in your head, later expressing what you remember in code. Only a part of that will be visible to them in demos? How do they know "you got it"? How do you know you bagged the complete exception handling you and they discussed? In the one-time-use case, you don't care about returning to maintain the document. In the multi-use case, keeping the docs up-to-date adds value.
Cockburn's intro to textual use cases is great starting point.
Above, right — Every representation of requirements has some advantages over every other one. This UML-style image of the use cases, for a part of a system, clearly depicts how they relate, something you won't get as well from a set of text descriptions, of either use cases or user stories.
1. Steve uses exploratory syntax and other druthers in his personal writing, which doesn't convert him to a poet. You can wonder how close he comes, doing something technical, with this verbal example to model?
Engineering: Why would pattern tomfoolery add value —
In the great engineering tradition,
Open poetry is an example of his style experiments.
Too bad you won't have a chance to see that!
Poetry: Free verse isn't that far off, he claims.
You want the intense awareness, the mindfullness, or, is there just one "l" in that?
Here's a peerless example, so you can contrast with Steve's debris at left:
A Noiseless Patient Spider
And you O my soul where you stand,
2. Chomsky did nice work on formal grammars, but his idea of a universal grammar drives Steve crazy, so sometimes he journals not using those rules, on purpose, or for Noam apparent reason. After all, the difference between writers and authors is the latter's willingness to invent language. Chomsky's about what's proper and what's not, so he can build evidence that language mechanisms are innate. "Who do you think Jack will kiss first?" is grammatical, while "Who so you think will kiss Jill first?" isn't. So you think?, Chomsky? Can't you make heads or tails out of this? Holy rationality... Or a ration of it.
What th! Quite a few of Steve's sentences on this page don't have a noun phrase, or don't have a verb phrase. Don't have to. Many, he thinks. Claiming that's a matter of linguistic competence is up there with, oh, his critiquing colleagues for inelegant use of subjunctive mood. What's wrong with, "Man the bit sandwich the." If we understand it? Are the new structures, being invented world over for texting, following Chomsky-esque rules? Not IMHO. With oral speech, people might go a long while talking, without ever attempting a proper sentence. Without ever. And we get it.
Steve writes to pull unplanned meaning out later. Can't you do that careful being!
He crawled out the input slot to Searle's Chinese Room a some time ago. Clarity has its place. So do gods made out of language. He could draw you a picture. Ok, he will. It's at left.
No, wait, will you. Download this Medieval woodcut and continue coloring it, or whatever, to taste. Steve Photoshop, himself like.5
3. Graphical writing — Visit a system architect's office and you'll see a white board with a picture of their current system, which they use to explain things to people on the project. Often it's informal, like arrows connecting things, or a bubble chart showing flow. Sign language is images, and is more expressive in certain ways.Why not write this way? Being ingenious on it yourself could be a key, finding something which feels natural.
Left — Mind mapping is an example of graphical writing. Here's a famous one of those, which could be useful for studying or any other place where you feel a time crunch. Say, for improving the efficiency of your own coding. Note the clashing kinds of alternatives, something the available space begs you to try for, graphically. Versus trying to write these time-saving ideas on lines of paper, which puts on you a pressure to sequence and relate your thoughts properly as you first invent those thoughts. If you'd tried to write this in the usual way, would you have thought of offshooting ideas like "monitoring" to make use of reflection? Would you have considered "let go"? Like, just do less? How about asking for help?3
One area where graphical writing is widely practiced is "graphical organizers," kind of a reverse of mind mapping, because they force relationships in particular ways.
4. Alts for diff media — Another thing Steve loves is abbrev wrds when wrtg, smthng that makes less sense if you're spkg. This also randmly lvs rm for varying mng upon rdg it bk.Unless you're showing a new proof for Zorn's Lemma, this can be fine. Svs lotsa X when comb with symbols — see next.
5. Symbol use — beyond emojis. As with many journalers and texters, Steve uses shortcut symbols as he pleases. Like emojis, his can carry a fuzzy meaning that the reader needs to speculate about. He does this so that he in truth has trouble interpreting what he said, on the fly, when he was writing stream-of-consciousness. Lets him feel like another person trying to get what Steve said. So, instead of rereading for "What he meant," he rereads for "What it could now mean." Basic examples of his symbols:
|symbol||possible interpretations||general sense|
|α||could be "any" or "at"||almost a quantifier|
|θ||could be "thinks" or "thought" or "imagines" or "hypothesizes"||cogitation|
|ϕ||could be "feels" or "finds" or "nothing" or "few" or "senses"||sensation, emotion, lack|
|σ||could be "some" or "so" or "such" or "same" or "at times"||not quite indefinite|
|X||could be "time" or "times" or multiplication or stretching||duration|
|>||could be "greater" or "more" or "even more"||comparison|
|>>||could be "lots more" or "dominates greatly"||significance|
|could be 'implies" or "points to" or "proves" or "suggests"||cause & effect|
|could be "says" or "said" or "talked" or "spoke" or "expresses"||verbalization|
|could be "heard" or "hears" or "listens"||attention paid|
|could be "see" or "sees" or "saw" or "envisions"||observation|
|could be "shows" or "showed" or "demonstrated"||displays|
6. Creative punctuation and formatting — In Steve's own jouraling, he gave up on chapters, paragraphs, and margins long ago. He writes on oversized, blank pages so that he's not always thinking what goes on the next line. And most pages end up with multiple columns of varying sizes. Using "exploratory syntax" (idea # 1, above), you can make each line end where a thought ends, not where the margin bell dings or Word decides to do a Return. There's more freedom writing by hand, so you're not messing with formatting, just doing whatever feels natural.
Like many other authors who hand-write, he discoverd new forms of punctuation. Like, isn't it interesting to put a question in the middle of a sentence,? like this, only you could just put a comma under the hook of the question mark, instead of a period. Steve's first recollection of seeing someone else try punctuation combinations was Henry Murray, the psychologist, who used things like commas with dashes to clarify his sometimes complex sentence structure, in treatises on personality theory. Then he heard from other journalers that this is something many fall into.
There is stuff on the web about creative punctuation, including Steve's combo question mark. The problem, usually, is the limitations of the typing tools we use.
7. Getting lost in syntax — Not infrequently Steve tries to go for Language Log's "Trent Reznor prize for tricky embedding," which was based on the following quote:
When I look at people that I would like to feel have been a mentor or an inspiring kind of archetype of what I'd love to see my career eventually be mentioned as a footnote for in the same paragraph, it would be, like, Bowie.
If you write stream-of-consciousness, you turn out more superstrings than untestable physics theories.
8. Mixing images with text — You can already tell Steve stirs these together. A picture tells a thousand words, and more — they inspire new directions which can be explored in words. The scenario that's next is one instance. So are the 23 examples in the table below that. Are these best done electronically or with hand-written documents? You should try both, and decide.
9. Scissors and paste — Novelists pioneered this, like Burroughs in Naked Lunch, and isn't it time we started, in technical writing? The idea is to mix snippets of different threads, because then they interact with each other. Versus a nice, neat flow of chapters. You can get the idea from Steve's flow of musings in the table, below. Like, try to guess how each is connected to the ones around it, as you read through them. This challenge also relates to the middle "C" — Connections — in the KEEN process for entrepreneurial mindset: "Discoveries, however, are not enough. Information only yields insight when connected with other information. We must teach our students to habitually pursue knowledge and integrate it with their own discoveries to reveal innovative solutions." And, you see these relationships by bringing that "other information" closer — weave it in.
A direct application — have web help pages that can be presented in different sequences, depending on the associated action being done. And let your users "crowd source" new sequences that meet their needs, and explain them to the user base.
Or, constructing pipe-and-filter applicaitons, something very much in vogue these days for processing "Big data." At right we see the flow for Microsoft Azure, where the "Activity" can be composed of a variety of stages, varied to taste, such as using different data analysis or machine learning algorithms and their associated helpers.
10. Go postmodern! The prior tip is only one of many devices and styles recent novelists and other authors have used to reveal otherwise hidden content and value in new ways. Italo Calvino's 1979 novel If on a winter's night a traveler is a story about a reader trying to read a book, which of course is also presented, woven into this. Applying the notion — You can show a video of a person trying to use your system, to get other real users to do the same thing. And, in fact, this is done a lot — with You Tube videos demo'ing successrul use. To start down this path, try the Wikipedia article.
The whole postmodern thing is about revealing unintended meaning for both the reader and the writer. So, devices like fragmentation, paradox, and having an unreliable narrator fit right in. Think this has nothing to do with building software? The Agile movement presumes that the client is exactly an unreliable narrator, who doesn't know how the story will turn out, when it starts.
11. Practicing writing scenarios — This one goes beyond grammar, so he saved it for last. Suppose you are about to start on a project with a customer or user you don't know very well. Write a story about how you think this will go, including fictional characters interacting, doing things like you imagine will happen. Or, like how theydo things now, which needs fixing with whatever you're being paid to do. Among other things, this exposes your own assumptions about the upcoming work. You can step back and see things you might actually have said to the customer, as if you'd already done that. Even if you still ask them the same questions or propose the same solution, you have now done this twice, fiction and for real. It's like a "pre-reflection." In writing such things, Steve makes use of all the blurring tricks just described. This way, he can read more into the action — unintended meanings — when he goes back to review it.
Left — Here's a scenario, complete with dialog, that NCR colleague Amy Danielski (Hogan) and Steve did 20 years ago, where a game-like enticement could teach kids to be good banking customers, in a retail environment. This is a step above today's use of "personas" to focus engineers on real user needs — it expands their task toward the imaginative and long-term.
You can analyze this if you want, like "how well it held up over time," but don't forget that your real goal is to practice synthesizing them, yourself. As with story boards, a typical use is to stimulate further thinking. Maybe your own? Maybe for people involved in strategizing, or in creating a new product?
Because "Bobby's Kid Card" was for a wide audience, and we weren't necessarily present to interpret things when they read it, we did go more for readability here, than if this were being written for personal brainstorming.
Returning to the grammar and style topic, he stopped using quotation marks in dialog, when he writes stories, because this lets you blur, in any reader's mind, who said what. Even in your own mind, later. It's a little puzzle you / they have to figure out, and it's delightful when it might be seen in distinct ways.
→ But, of course, these 11 practices may make no sense to you, so make up your own!
At the beginning of this page, Steve apologized for being non-sequential, since that messes with people wanting to understand the contents in a flow of logic. If you don't insist on that linearity, this page may have been the kind of presentation you've been looking for, in contrast. It's just a matter of your personal style.
He apologizes more profusely for this final significant section. It's even more like that. He discusses bits of arguments, returning to them, because the whole mess is interrelated. It's about being open to understanding other people, a state which can't be defined clearly, without making you think of it in a certain way, which bias could detract from the act of that comprehension, of anyone who puts reality together divergently. Being open doesn't mean you've finally found a framework within which to put anyone else's reality you happen upon. Thought frameworks are like software frameworks, in that any one of them is better for some things than others. And the whole art of "getting" others could be an illusion, anyway. Maybe they are not fixed enough that we can do that; it just seems as if we can.
At any rate, trying to make the discussion clearer would be synonymous with making it conform to some particular perspective, the opposite of the goal.
Why do it, then? It's not easy to keep from being proud about accomplishments, or plain old grand over who we are. And, maybe just as bad, waxing majestic over our humility, if this is a trait we're taught to hold in esteem. Monastics and other devout religious people wrestle with that attitude dilemma. So do those who want to learn about other people at a deep level, and who recognize it defeats the goal for you to reside comfortably in what you yourself are. Many of us find that a task as simple as sharing love with a spouse requires detuning our own sense of importance. The job of understanding folks from other cultures demands it. So does the engineering role of knowing, in depth, the non-engineers we serve — the users and clients of systems we build. We professors need to understand our various students at deep levels to transform them via the learning process.
The deal is, understanding people who're different, better than you have, takes more than just concentration. You have to try to think like them, or act like them, in the same way you might get involved in the characters in a good book or movie. Which requires letting down your own defenses, because this is for real, not pretend. That's where the self-abnegation comes in.
But can you do it? One could study for a lifetime how to pull this off. Maybe it's impossible in general, just too slippery an assignment. And high standards are out there as challenges —
Young people are bombarded with such tantalizing challenges, by moral sources in places of worship or at home or in school.
At the same time they see models all around them who don't act anything like saints, including friends, relatives, and other adults. People whose pretentious influence, as we all know, tends to make those admonitions to reduce your wants and demands less accessible in our consciousness.
Even here at Rose, it's a tussle of a choice, about how deep into humility is proper: Can we be deferential entrepreneurs? Or, even lead engineers? When we graduate, if we are unguarded, will we get in trouble for telling a customer the unvarnished truth?
Finally, there's a real puzzlement that everyone else does not appreciate having more humble people around. They are a pain. Being chums with someone is based on sharing values and perceptions, especially social ones. If someone in your group cracks a joke, you are supposed to laugh, showing you share the bias of the joke. How can you do that social closure, share their conclusion about someone else, say, and leave you still just as open about seeing the someone else in a new light? You are a party pooper. If you go far enough down the Gandhi path of valuing all humanity, you're likely to be shunned by some former friends. You kind of have to choose — Is greater insight, if you even get it, worth that?
Background: Steve used to go to the Quaker (as a child) and Mennonite (as an adult) churches, where members actively seek to lead humble lives, even if this brings on a disagreeable reaction from everyone else. Indeed, to them, one test of whether they are doing that is getting such a reaction from time to time. They see value in doing what they think is more modest, even if they might be persecuted severely. The Mennonites were chased all over Europe for a couple centuries; both faiths were among the religious groups coming to America as a refuge. So, Steve has seen quite a number of examples of people who were willing to make real sacrifices, actively avoiding positions of social fame and power, and to maintain attitudes that accompany a more lowly status. Most famously, both these groups refused to serve in government jobs, which they saw as de facto positions of control, or to fight in wars for any government, which they saw as the most vicious form of putting yourself on top. They were uncomfortable in many lines of work we take for granted as part of the fabric of society.
In Steve's heritage, trying to be especially humble, for good reason, was not an idea stuck in your head somewhere, or artificially cut off by the need to act in what everyone else deemed to be common sense ways. Moral reasoning went past Kohlberg's Stage 4 (Law and order) all the way to Stage 6 (Universal ethical principles).
Left — Mennonites today are split on whether to look odd to the world, as a way to emphasize their divergent values. The long, mostly plain, caped dresses featured here are home made. Every such group is heavily steeped in tradition. Mennonite congregations learned to sing in four-part harmony in the 19th Century, using hymnals with shape notes, and they have never forgotten how. Music is a major part of a service, without the help of a choir. Some groups also have no professional clergy.
They are not us: The monk's motto of "poverty, chastity and obedience" is no accident. Self-reminders could be key. It is much tougher to be wielding influence, or even maintaining status, and still see things from the monk's less clouded perspective.
We should admit that we higher-ups on the social scale also resent the behvioral discrepancies of holy types, in the same way we point out discordances in others down the food chain. Can't the friars just see themselves clear to have one drink with us?
Good thing they are in a protected group like behind the walls of a monastery. People intentionally not conforming are considered renegades, for opting to take a less-accepted role. If there's more than one, they are a cult. Those in charge are fearful of them, even when they are not an immediate threat, because we can imagine this being the case in the future. Being ignored or laughed at is not as bad as this can get. Now, we don't sit around worrying about holy-acting people all the time, that's true. But our lives intersect only occasionally with them. The question is, what do we think when we do encounter them, or when they come up in conversations? Same as about immigrants, lower classes, and other races.
We all fool one another that social knowledge exists like knowledge about the physical world, especially our own firm opinions, but it's not so. Indeed, in William Perry's growth stages, which we hope our students evolve through while here, they end up at "constructed knowledge," where social things are knowingly integrated as an intentional act, based on a variety of sources. Now consider how these idea concoctions work in a stratified society. The combination of holding the reins and human imagination is a wonder to behold. You've heard it from your parents, who are charged with your destiny: "Zip up your jacket. You'll catch pneumonia." And, when we butt heads, the masquerade of absolute social truth intensifies.
Disruption of expectations is an especially good example of pride's blindness, because it produces such strong reactions. We want things to remain as we feel they are supposed to be. Consider the law suits by Caucasians who were denied entry to a college, while someone of color got in. And, in some cases, the US Supreme Court backed them up. A favorite ploy of the powerful is to blame the dissenters for causing them to get angry. Everything has to be the fault of the less capable side, so those in place can continue to feel good about themselves. Foucault wrote a book about it. See here, for an intro. As an example, Foucault asserts that dominance does not like to show itself for what it is. It responds, instead, to the actions of those it seeks to control, substituting reasons for doing so. A worst-case may be seen in obvious power flipping: If you don't like having a black President, you instead ferociously go after everything he does, all the while claiming that's not why.
Understanding how less favored groups are held back, if you are a member of the elite, is very difficult. It requires second-guessing how things are explained to function, by people similar to yourself. The rulers will deny that any reinterpretation of their actions has validity. If you are Caucasian, and a Republican, Steve's example, restating conservative criticism of the US Presidency, is utter nonsense, probably motivated by something sinister. Or worse.
This is all much easier to see in someone else's culture. To us, propaganda from contrary countries is ridiculous, and it's hard for us to picture anyone believing it. From the inside, though, it's a different story. For example, Steve's daughter who reads the Russian media noticed that, in a poll, 90% of the people in Russia believed that the Malaysian airliner shot down over Ukraine was targeted by the Ukrainians themselves, because they believed Vladimir Putin was on board. Basically, the privileged group is free to make up stories for why things are that way, and to cover for any problems. When at war, like Russia and Ukraine kind of are, the truth takes a holiday.
The home field situation: Steve saw modeling other groups as a key to understanding why they are such a small percentage of CS people. If he could be one of those rarely seen in the midst of programmers, he might find out more about those people's plight when they try to join. And, more broadly, he could discover how it feels to be on the outside of the circle he'd been inside for several decades. Being treated as a non-member makes you feel pretty quickly like a non-member.
Because of the sex bias in computer science, Steve feels one of the most interesting positions to learn about in this field is what that looks like from the flip side. (See the graph of the downward trend of participation by women, toward the end of Steve's "And more" table, below.) We men in CS believe that we are sensitive to the issue, doing everything we can, but that's a typical rationalization for the group calling the shots.
While you cannot really become a member of some other group very easily, you can push back every possible barrier and give it a try. If you do enough that you can evoke "not one of us" reactions from the dominant group, you'll gain some wisdom about it. You'll know you've crossed important lines when you get dissed, ignored, and discriminated against.
Possible benefits for you: From his background, Steve believes that self-effacing positions do enable you to lead a richer life of engagement with others — You are not busy protecting so much, as you do that. You are not commited to a single course of action because of what you will get out of it personally, or because you have declared it so. Volunteering to be a member of a besmirched subgroup is the fast track to that situation.
C.S. Lewis felt that "Humility is not thinking less of yourself, it is thinking of yourself less." What do you think? Steve hopes that this advice doesn't remove the obligation to be self-reflective. He prefers Mormon leader Gordon B. Hinckley's "Being humble means recognizing that we are not on earth to see how important we can become, but to see how much difference we can make in the lives of others." That's a more operational definition, don't you think?
Right — Mother Teresa's relevant quote stresses the internal strength gained by humility. A proud position, in contrast, requires constant tending to, distracting you from trying to do more important things.
And for everyone else: At Rose, Steve senses a need to try for humility in as many ways as possible, because it is a necessary ingredient of good engineering, of teamwork on diverse teams, of customer relations, and of education itself. How do we work on this skill?
In Steve's section on "Philosophy in action?", close to the top of this page, he suggested compromise as an example of a competency toward staying less pompous. There are more, and likely we each have some we practice regularly. Where can we share these points of personal emphasis? What's the right forum? Since Rose is not a religious school, we are unlikely to reach a consensus about how to go about being more aware of others, through humility, Mindfullness, prayer, meditation, or doing our social discourse in certain ways. It could be useful, Steve wonders, to exchange notes.
Being the lesser: As just noted, a further example, which Steve also pursues at Rose, is representing groups you believe may not be in the favor of the majority. So long as one is a revered professor, one cannot understand what students feel like who are at the bottom, either academically or socially. Those who have to struggle for friends because everyone prefers others, say. He thinks faculty, in general, are far away from this plight. We share in the governance of the institution, hand out assignments and grades, and may have tenure. How can we possibly know how it feels to be on the other side of all that? Students call us "Doctor." It's much easier just to hone our attitudes.
Now let's flip the notion, that those at the top should discern better those falling far below them in status. It is important also that the latter, lowly group know there are people at the top who like them, are like them, or want to be like them, who belong somehow to their powerless group. More identification is better. Saying a school is open to a posted variety of people is not the same as depicting them yourself, on a daily basis. How can we make that visible, so our compassion doesn't just come off as conjecture, unattached to reference points? Can we, oh, portray the student struggling with a problem, at the white board in class, without making fun of them? Or a student in a disliked minority, in a way they would agree is supportive, not problematic? Can we get beyond just trying the food of another culture, once a year? If we can't do those things, aren't we resisting understanding them?
Does this work at Rose? Steve does not know how all the faculty feel, about the traditional function of wielding power to stimulate learning, versus his suggested alternative, staying open and not trying to write the script for what students think. If you give up on playing a dominating classroom role, it's a bit scary, especially with students who are used to being told what to do under close supervision. We all see this in open-ended projects, for one. Their uncertainty as to how to proceed becomes your fault, quite likely.
He thinks the ploy has merit, of trying more to comprehend the students who aren't getting it, versus forming an intellectual phalanx with those who get it the best and are most academically sanctioned. In the same way, abiding with college outcasts and proletariat has an ethical basis.
It's possible that our current system of rewarding academic merit and career qualities in students, with attention as well as grades, would be threatened by a change of pace. Everyone benefitting from the way things are done now might feel a loss, by even one person defecting from the academic pyramid program. It would be like stepping out of line in the graduation parade! Yet deviants play a vital role, as discussed in my section, "Making Change," above. Durkheim said we affirm culturual norms and values by showing contrast, we clarify and sometimes change what is right and wrong, and we give people new ways to unify. How can we attack goals everyone else overlooks, say, reducing the cost of education by having students help one another even more than they do now? Maybe getting the great students to guide the weaker students, taking after us in finding them attractive to be around?
Above, left — Steve maintains that at least one misfit is needed wherever you go. Our Rose grads can't be just a factory output of known quantities, when the world is changing at an accelerating rate. Those running the machinery, who are doing well with things as they are, should be complemented by those willing to dive underneath the success stories, for a better look at the whole thing, unembcumbered by a need to stick to the party line. The 2014 article, featuring the commencement picture behind me, was titled, "Rose-Hulman tops list of Indiana students who graduate with most debt." Note Steve's books are in the shadows here — likely not helping much to solve this problem. (You have to look through the students to see those books.)
Why not identify more with those in need, to discover ways they can be helped, on their terms? They are equally good people. In several spreadsheet studies Steve's produced, how well students do, in our CSSE classes, appears to correlate insignificantly with how well they do in general, like on their GPA. So, the successful ones are probably not, in general, smarter, better at studying, or anything else they might claim as a cause. But CSSE success does tend to be based on their prior experience — like our students who took CSSE 221 first, which was because of prior programming, did better in classes after that, too. Success there predicted success in CSSE 132, more than other courses forecast results in the next. This outcome had little to do with "ability."
Both how they do in their GPA, and how they do in their major, could be partly because of self-fulfilling expectations, as much as it is because of their being more scholarly, since those two things disagree. Haven't you noticed people who see themselves as a "B student," and quit working when they get to that point? Steve believes there is every possibility that students who don't achieve so much here will end up having just as successful a career. For example, going on to something else when you have reached a "good enough" level is how most of business operates. Herbert Simon got the Nobel Prize in Economics for pointing that out. So, don't these "satisficing" students deserve as much attention and esteem?
Perhaps no attempt at gaining a grip on such things is going to be fully successful, but we can try.
Let me know if you see anything in the musings, below, which fascinates you.
Some of it is themed, like tying illusion and motion to software — Does that fit? What do you think?
Some chat, with titles
One or more images,
Optional aphoristic metaphor for education (Steve's humble one-liner — please suggest better!)
|Some more chat, mostly|
Here's looking at you:
Consider how software yields flipped answers from flipped perspectives.
Referring to that, a smaller version of the wood-sculpted hand reaches out to grasp it, while his own hand is poised behind those, as part of an incongruous, wispy image lying opposite to the direction from which he actually had to have been taking the shot. It must be a Sony Style thing...
Does love of self-referrentials explain doing your whole page in the third person? Ask Steve!
In a normal world, things seen in a mirror like this seem reversed left-to-right, but not top-to-bottom. Feynman had a good explanation, see here.
This is one of several illusions noted in this column, which Steve thinks shed light on software development.
Long-term avocation — Photography:
Here's a picture via which Steve made it into the school paper his first term at Rose. .. Roofing people shadows, seen projected on the chimney out Steve's office window.
Steve loved the shadow motion of this event. And, he feels physical motion is a lot like running software. See the next 4 rows, below.
How is photography motion? It captures that!
So often, we only see glimpses of what software does, even as developers.
A college is fully Plato's Allegory of the Cave. Students and faculty can surmise what's going on in the outside world, but, unless you dip in and out of it while in the ivory tower, you are guessing. Are these two, seen from inside the tower, truly fighting, or not? Only a visit to the roof would clarify.
Ready for Lift-off:
The mobiles don't move much, but they can, and they suggest it.
Your precious processes will fly only for a too-brief period, then require change.
Things change fast in the software world. At right, this 2005 class studying requirements management learned to handle that with use cases, designing for a fictitious startup business, the professors (Mark Ardis and Steve) playing the entrepreneurs.
Ten years later, in the same room, Steve's class broke into teams starting their own businesses, perhaps for real, and their processes were now agile.
Of the students in the class shown, two went to Microsoft, and one ended up with a Ph.D. in CS. All are working in the software industry.
This particular section was even smaller than usual, thanks to its meeting at 8 AM!
Process change is motion, too, huh.
Where it's at:
What matters here — students studying. Steve can see them in the lab, as he works on the next lesson in his office.
The motion here is their growth in learning. Much of it is by watching their programs run.
The best learning happens in dedicated spurts — I think!
Rose's open door policy guarantees an unpredictable workflow, for us and for our students, but with lots closer interaction than if we sacrificed that. Musician passes the ostrich above the door, who's enamored of the strange glow given off by students thinking in the lab. Tinkly bell by the plaque serves as both door chime, when entering, and head knocker, when seated in chair underneath.
Once upon a time, "open door policy" was associated with diplomacy, and with keeping imperial powers from dominating trade with China. In businesss, having a manager keep their door open is an invitation, a sign of accessiblity, notably for their employees. It suggests a fast and free flow of communication. Our students see this the same way regarding faculty, as a sign of students' priority in our lives and as an active means to promote their learning.
Steve's personal opinion — When students go looking for a job, they should observe whether this same policy holds true there.
Bricks and mortar:
The chimney out Steve's window is in fact in-between his office and the next one, which has been occupied successively by Salman Azhar, Lisa Kaczmarczyk, Curt Clifton, Matt Boutell, and Valerie Galluzzi, while he stayed put.
To the casual observer, it looks the same from either office, leading to the logical conclusion that there are really two chimneys, but only this perspective reveals the authentic scoop.
Dedicated experimentation also pays off ... given time and accidental observations.
Atop the shelving is one of his toy trains, part of the hobby noted at the end of the next chat block, below. It's a brass model of the original Rock Island Rocket, which was led by a very early, 1200 hp, Electromotive Division (General Motors) TA diesel.
Here — In the full train package you can see that a couple of the cars are joined at a shared wheel set, just like the original. This lowered rolling resistance but prevented easy car replacement.
The horse mobile directly in front is popular — the steed gallops as air conditioning rotates the piece. Which suggests to students, Steve hopes, how an intriguing feature can make the difference.
To the right of it, against the window, is his Fresnel lens, also a hit. It shows a blur from here, but it reverses the image as you see it from the distance of visitors on the far side of Steve's desk. The penguin appears to be crowing over that.
What's all the rest doing at Steve's window? Hah! Attempts to make things that sparkle in the light. A few were duds — Anything solar powered, like the silvery ribbons above the train car, refused to budge. The tall tube of glistening shapes turned yellow. Those stick-ons toward the top melted down the glass. The prism above them, however, shows rainbows across the room, late in the day.
Planes, trains and auotmobiles:
People trust things they can put a recognizable name on. In design work, successful contracting often has been associated with hyping the chief designer as if they had done everything. Thus Frank Lloyd Wright houses and Ralph Lauren shirts and Andy Warhol paintings.
Steve believes we can learn from serious study of other fields of endeavor like this.
Seen here with two of his famous creations, Raymond Loewy was known as "the father of industrial design." He supposedly did the paint layout for Air Force One, but he ran a big operation and it may well have been an assistant's inspiration. One of his specialties was logos: He did the Shell Oil insignia and the Lucky Strike pack. He was a force in making "streamlining" part of Art Deco and the Modern age. The Greyhound Scenicrusier was his. In this painting he's seen with two such creations, the Studebaker Commander and the Pennsylvania Railroad T-1.6
How it looks matters a lot. Styling draws attention to make sales, for one.
Now, new design ideas have unexpected twists, and the two inventions shown here surely did. The T-1 was an effort by PRR to make a fast (100 mph+), more powerful steam engine to haul passenger traffic. Loewy's streamlining was for promotion. It had two sets of drive wheels, as you can see, but it was not articulated. The railroad found out, after building it, that it was prone to wheel slip, and some track improvements were needed so it could haul trains from NYC to Chicago. Loewy's original design included covers above the wheels, which had to be stripped off for ease of maintenance.
Studebakers came out of South Bend, IN. A wagon maker in the 19th Century, they started delivering electric vehicles in 1902, but soon switched to gas. Their later ones, like this 1950 convertible, were termed "cars of the future" due to Loewy's styling. The radical, "bullet-nosed," airplane-inspired look sold well. Steve's wife's uncle drove the even more unconventional "Starlight Coupe" version which gave rear-seat passengers a panoramic view. Virgil Exner, soon to become another famous designer, assisted Loewy in turning these dreams into production cars. Having the fenders and body a continuous unit was still new, and those compound curves couldn't have been easy!
Studebaker had quality control and labor problems in their manufacturing. In the end, they couldn't compete with the "Big 3" car manufacturers on price, and folded in 1963.
The Avanti, last of Loewy's Studebaker designs, continued to be built by various small shops, up to 2006.
Steve gets tickled by considering what made for success and failure in different kinds of designs. He collects models of these, especially trains, so he has something to mull over, while doing his own designs.
Dressed for success, 2011 and 2015:
At left, this is as informal as he could get for an official school portrait. Supposed to look professorial, he guesses. How do you model diversity, humor, complexity, right-brain values, and collecting and making good use of every imaginable thing. Oh, wait, that was supposed to have a question mark, right? Call it more fun with linguistics, or accidental discovery in action.
The tenuous blur of the new ought not tempt us to ignore it.
At right, remove the requirement to be a part of what's official, as in, assuming an impossibly fussy audience has to be pleased, as projected from a cumulative institutitonal superego, and you can combine instead multiple personal appearances, stimulating students to figure out the meaning. What is his intended kinship? The desired, uncanny impact is suggested by the use here of Photoshop's extrusion tool, "pixelating" the image into small, related cubes of meaning, while continuing to try representing the whole. Work is like family, a place to play.
Intentionally violating norms is integral to creativity, not optional. As Plato put it, meaning comes from difference. Although, now that Steve dwells on that, his latest goal has been to vary from Plato. Too much drive to be right on things. Kinda leaves you empty from the combat, don't you think?
Gotta agree, of course, that engineers should spend a bunch of energy being critical of the things we do, so that the bridge doesn't fall down. The twist is, we should spend a bunch of time not being harsh, too. The result we live with ought to play in our hearts like a Strauss waltz, not like a Strauss bascule bridge.
The long view:
Steve's ability to see Rose from a distance is due to more than lengthy industry practice. He's a Buckeye on the weekends, enmeshed in poles-apart town politics and amenities.
Eventually your novice status will give way to the lessons of well-worn habits.
His avocation has become known as traveling-across-I-70.
With two abodes, as marked, you can see why.
Staring down the trash cans: Parked in his Dayton driveway, this is Steve's mode of transportation across that I-70 path, for the last 12 years. He bought the 2004 Toyota Matrix new, and it now has over 320,000 miles on it (515,000 km). Still gets 30 mpg regularly (9.4 litres per 100 km). Being the careful planner he is, Steve does have the most likely replacements in mind. One dealer offered to come pick him up in a new car, when this one finally breaks down on the road.
Piecing together designs:
Steve loves and respects his students, who will have a career like his. He observes how best they can learn. It's possible many are too scared of the unknown to hesitate from employing their hard-earned frame of reference. After all, it's only been a fraction of a decade since they were in middle school, checking Facebook 100 x a day to see if they'd been "dissed."
Where he'd like them to be is willing to "deconstruct" their own position on solving a problem, technical or social. As in, abandon their own intent, so as to see it in a different frame of reference. Versus continuing to argue that they must be right. Only in this way will they understand people they need to make happy in their future lives, say, the users of their products and services.
Design is way subtler than the rest of engineering, and it includes reusing most of the content.
The systems we build in software are roughly equivalent to these "upcycled" handmade styles from Etsy.com, with pieces taken from mismatched old garments and what-have-you, to fashion a thing for a new purpose. Each piece had an original function, and was built by someone with a varying perspective. The best we can do, often, is hope that the results go together, in an overall way that is pleasing to the customer. Or, in this Etsy case, also to the customer's onlookers.
We are not so antithetic to the designers of these garments, in having discretion in the design and in sensing a compulsion to add our own originality. You can perceive the results better in someone else's domain, Steve thinks! How did they do?
We see a lot of contradictions in design. Like clients who refuse to be pinned down about what they want, then insist what we produced isn't it. "Clarity" and "authenticity," though popular for selling, because you want the customer to make a choice, aren't the most useful words for inventing. Meanings are unstable. Everything "depends." Even "responsibility" is blurred by the sharing of stakes and contributions. Ideas are paradoxical and conflicted. And you can't shout your way out of it.
In reimagining Rose, we hope to engage our full community in new ways. This could mean, say, more fully integrating the humanities in with technical learning. We really should use that opportunity to move on, beyond the Hegelian dialectics that math and logic and the physical sciences and CS so often prefer, don't you think? We want our students to participate in creating new forms, not forborn by violent, single-minded reductions at every turn. They need to step past traditional "critical thinking" and into that synthesis. All of it is text, including meta-rules we have a habit of assuming. It's "in play" for discussion in alternative ways, by different people. The more immediate access to broad meanings our students have, the more heads-up will be their designs.
Students need the ability to read between the lines of what's declared to be so. If a client says they want it green, why is that? What influences this opinion. What might change in those influences? Not just why they say now it's gotta be greeen.
What else can we look at besides opposition of ideas? Where does a team have things in common? Where do our clients, with their competitors? How can we corrupt the dichotomies in play? What partial solutions can we offer? Where can we find hints and angles? This is not a cookbook procedure to be learned, it's a general, humanistic approach to permeate the work.
As in computing, undecidability rules.
Reaching for the impossible:
Deconstruction is actually a pretty tough trick for engineers. We are taught mostly to be analytical. But, contrarily, we need the softer skills of synthesis to build anything. There is only one best choice, or even a clear winner, under tightly constrained cirucmstances. When you look at someone else's design, however, it's much easier to come at it from discrepant directions — you are not invested in the particular one you've expended time on.
So, what's this at right, for one thing, and why was it done this way? Would there have been a better design? In deconstructing artifacts, opinions matter.
If you investgate the picture a little, you'll notice oddities like a beautiful woman named "Tobacco" above the left-hand door. And what appears to be a symbolic sun over the middle door to this building. Above these images, is that a big crack in the stone? Hmm...
Steve's wife took the picture. She is fascinated by sculptures and other special effects that architects put over doors, or otherwise above the gaze of most passers-by. Often, they are specific symbols related to the purpose of the building, or representing clearly the era of its creation. 7
Keep staring up, once in a while.
Here's another instance, which his wife took on a different trip, again perched above the normal view on a building, head possibly perched on the body. It looks like it must be from Notre Dame Cathedral or something. But it's not a monster, it's a person, posed as what — Wondering? Is he like a second cousin to Rodin's "The Thinker"?
So, what's the deal with this one? What's your gut-level reaction, which likely, or possibly, is related to the intended effect of the piece's creator? 8
Sometimes when she points the camera up, the complexity frozen is pretty amazing. Regardless of this architect's concept, the result dazzled people we saw taking it in.9
Deconstruction is regarding sensing the intent, or the impact, of symbols like these, from new directions. Demuring, versus just asking the designer what it means. As with your take on these pieces, the "real meaning" is continually unfinished business. This also is true of our engineering works. "What it means" isn't just what we we designers think it means. Even more, it is what the users and others who encounter the artifact feel and believe it means.
Seeing things from dissimilar directions isn't easy — just ask Carl Jung about the unconscious, or something. For complex systems with complex clients, you have to try!
Or, be up there, gazing down.
Here's Steve in a natural setting, 2007 — outside exploring, but holding a pen, so as to be scientific over it. And here we also see the look of surprise that means you are learning something new!
Starry pen? The Impressionist movement thrived on the fact they had oil paints more usable outdoors. Let's see, if van Gogh had done this picture, it might've looked something like this?
Emphasis on the overall craziness, turning sky and tree into a sense of sky and tree, along with a meatier Steve, while also highlighting the rolling role of the pen?24
|What's up with this?
You have to have a long-term goal based on your ethics, to make contributions you can feel, Steve believes. He could be wrong.
Know when your assumptions must be all wrong.
|The problem Steve would love to solve more than anything — the breadth of participation in CS in the US is moving inexorably in the wrong direction.|
Finding support and advice:
Collaborating to achieve results is a specialty.
Appreciate how we are all unique.
|Steve thrives on connecting with other people and their ideas at conferences. Here he's at ASEE 2014 with Timothy Wilson, Chair, Department of Electrical, Computer, Software and Systems Engineering, at Embry-Riddle.|
And mixing-in fun times:
Conferences are even better if family goes along. Here Denise and Steve are outside Florence, 2015, ready for a drive in a 50-year-old Fiat. He was at CSEE&T and ICSE. You can see we also were ready for rain.
The quote in my recommended aphorism below the picture refers to the management jargon which won't die, almost synonymous with "Let's forget how we got here." Usually it's an admonition given by a manager, to stick with discussing how to implement the plan they had in mind. "Moving forward" was voted 2010's most annoying phrase after the new Australian Prime Minister used it 20 times in her innaugural speech. To business people, the phrase is as prickly as when we open a class with, "We might as well get started" to quash lively chit chat in the room.
"Moving forward" requires continuing the past.
The 1100 lb (499 kg) Fiat 500 of that era had 17 horsepower in the rear, and a 4-speed, non-synchronized transmission. We got some detailed instructions before starting out, on how to drive the relic without destroying it. Ever double-clutch on the way up?
We stopped to snack, were passed by many other cars, and saw where Da Vinci got the background for the Mona Lisa.
The ride was a Christmas present from Steve's two daughters. As an encore, they gave him a flying lesson in an equally aged military trainer, for his birthday.
For us, this tiny Fiat was almost a stroll down memory lane. We owned a similarly sized, yellow 1971 Honda 600 sedan like this, which had 10" wheels and a stroked 2-cylinder motorcycle engine. The doors were paper-thin, a little scary. Once a wheel rolled off of it, down the road in front of Steve. Steve logged the expenses, and one year's gas bill totalled $ 60. We'd bought it from Denise's brother, who was heading off to Indiana University, where freshmen couldn't have cars. When the local dealer started running out of parts, we sold it to a mechanic there, who promptly got fired for stealing those parts!
His whole family finds travel to be a learning event, above all because you can dive into a contrasting culture. Here, in 2012, are his two daughters, one in Paris, on a street named after her favorite ink slinger (and he mysteriously appears above her); and the other outside St. Petersburg, at a residence for Peter the Great, imitating the poet Pushkin, who stares out, overhead.
Assume that what you don't know about other cultures must be important.
Montaigne was a 16th Century author, influential in the development of the French language. He made the essay a standard literary form, and he merged casual commentary and autobiographical material with more serious stuff, just as we engineers do — gosh, Steve hopes he learned from him! He allowed doubt to enter into his writing, versus just being pompous. He had more hair than Steve.
This street intersects the Champs Elysees, at a the same place as Avenue Franklin Delano Roosevelt. Definition of fashionable.
Pushkin was a 19th Century romantic playwright and novelist, and often regarded as the greatest Russian poet and founder of modern Russian literature. At times Pushkin was unable to publish and was watched by the Tsar's political police — sound familiar? He fought a lot of duels and, predictably, didn't last the last one.
We traveled to see the palace and gardens where this statue is, on a hydrofoil. Steve's daughter tried to talk us in at the Russian citizen admission rate. The woman in the ticket booth took one look and said, "Those aren't Russians." Perhaps we didn't have the right facial expression?
To de-Hoosierize or not de-Hoosierize...
Steve tries to encourage his students to consider living in various places after they graduate, because they tend not to. If they are from Indiana, why not try someplace else for your first job? If you don't like it, you can always return. Or the reverse — If you came from elsewhere, why not stick around just a bit longer?
We all have multiple paths we can follow.
Here he is with his brother-in-law, Mike, walking a California trail that leads to a bay that leads to the ocean, something you can't do everywhere. Mike taught school in Indiana at the start of his career, but kept visiting friends on the West Coast and decided he liked it.
Kids right out of high school aren't especially good a making life decisions, like the best home turf. It's a good thing not so many get married right away, as they used to. Figuring out where you want to live and work is equally huge. Trying something out, after you graduate from college, but leaving your options open, like Steve's brother-in-law, is increasingly popular. Fortunately, for Steve's students, you can get a job as a software developer almost anywhere.
Let's stretch yet another vacation canvas:
Right – Here’s Steve's wife, Denise, enjoying our nation’s Capitol, spring, 2013, while awaiting cherry buds that were slow to blow. In the background, the National Gallery’s Lady Lilith, by Dante Gabriel Rosetti. He started painting it in 1866, finished it after two years, then changed the face at his client's request, so that it wasn't Rosetti's girlfriend.
That’s an image Denise snapped, if you can figure out how. Not a selfie stick. Too close a resemblance, BTW?
Stay open to prodigal relationships everywhere.
Lilith was of course Adam’s original wife, by Jewish tradition, of whom Goethe said, "She excels / All women in the magic of her locks; / And when she winds them round a young man’s neck / She will not ever set him free again." Thus were the values of the first first family, inspiring Rosetti to paint. There’s a lot to like in the unexpectedly thought-provoking twists of culture!
For non-fans of the concept that women's station is defined by Eve being formed from Adam's rib, Lilith was, in contrast, created at the same time as Adam, refused to mind him and left to live with archangael Samael. Who, himself gets around; among other references, in Gnosticism he's the third name of the demiurge, the guy who fashioned the physical universe. Who of course is not the real God, in Gnostic and Platonic traditions where he's defined, just the one we're aware of, via this particular creation we live in.
So, as she stood by for cherry blossoms, Steve's wife took a picture of Rosetti's impression of his amour as Lilith, altered to be more PC. With Lilith being an alternate origin story for women, who consorted with a possible maker of the universe, who isn't The One, after she dissed Adam. For Steve's money, in all this story, the demiurge is the closest thing we've got to a holy engineer.
How do roots play a part?
Top left — Young Steve investigates a strange golf club with transparent handle — will it even work? His parents encouraged curiosity. He took pride in knowing how to tell time on the watch. (And now collects them — see below.) Mom shows off his sister, who looks on dubiously. The cold-weather clothing styles were pretty standard for the era — "bundling up" was not to be questioned.
The houses all had front porches, on which to sit and view the world. The smaller building behind is a garage where we kept our car.
Middle — A bit earlier, Steve's brother watches, entertained as Steve tries to help his dad wash the family's 1941 Chevy, at the first house he lived in, in New Castle, IN. Are we born to learn by doing, and to be engineers?
Stories told by parents, after the fact, about their children's early predilections, may or may not be trustworthy, but the picture doesn't lie.16 What you see here is a toddler who really wanted to know how to do stuff.
Bottom — This is a Sunday dinner at our house on 24th St in Indianapolis. Steve's grandparents, at left, lived in the other half of the double. His uncle, an artist, took the photo. With his back to the camera, Steve's doing his best to be amusing.
Acceptance of people thinking differently came at an early age: Grandmother was a Christian Scientist, Grandfather was an athiest and socialist, named Steve's dad after Terre Haute's Eugene Debs, whom he knew. Uncle was an Existentialist, contradicting the fact all we see of him here is the reflected flash from his camera. Mother was a Mennonite. Father was a musician — as noted in the portrait of him on the violin, above, by his brother. Steve went with him to Jordan Conservatory, where he taught music theory. He conducted church choirs, but used to read books on Zen during the sermons. Both parents were early food faddists. Everyone at the table except Uncle is drinking just milk or water. Steve didn't try a Coke till he was a lot older, did eat a good amount of wheat germ.
Most folks lived closer to relatives back then, so such get-togethers were not unusual. Before he started school, Steve would go next door to watch soap operas with his grandmother, giving Mom a rest. She raised canaries and African violets. She was part Cherokee — notice the black hair, despite her age.
Unseen behind the camera, desks and tables where the two brothers worked on an endless array of projects and puzzles. This was their play room, most of the day.
The experiences you had as a child continue to resonate.
Top right — Some things don't change so much. Steve's parents were as serious about education, as many of our students' parents were. Here, on the back porch of our house on 24th St, Mom reads to his sister as she views another book — probably wanting to do like Mom! She was two then. Note the prevalence of toys on the shelves behind the boxes, probably containing even more books or toys.
A little game to play: Got old family pictures like these? You should try the following exercise — picturing what is not the same now, even from when you were a small child. It is practice for acts such as imagining what is different for your customers, from your own world.
Things change pretty fast. A hundred years ago, a third of the labor force worked on farms, and being a live-in servant was a common occupation. The era shown here was about halfway between then and now, still a real contrast, to what today's Rose students grew up in.
Steve's mother was a housewife, and had no servants. Grandmother had one, who came a couple days a week on the streetcar. She was black, and grandmother ate lunch with her — considered pretty radical by some neighbors.
The single telephone sits next to grandfather in the bottom picture. The stew we're eating might be made from organ meat, recommended as even better for you than regular red meat. There's a casserole and a head of lettuce on the table. The salt shaker was used liberally.
Our furnace was coal-fired; Dad went to the basement to stoke it, and to light the water heater when we needed hot water. The one bathroom was upstairs; its bath tub had curly feet. Our phonograph played 78 rpm records. Mom had just come into a Hot Point refrigerator, surpassing the ice box. You hung wet clothes on a clothes line. In the summer, we opened windows or sat out on the front porch and fanned ourselves, talking to passersby. We knew most of our neighbors.
Cars sat in detatched garages, in alleys, a carryover from having horses in barns. At this point, Dad drove a Hudson, soon to be replaced by a Nash. After another Chevy, he caught the import bug and bought a 2-cycle Saab 93. A group of neighbors paid us a visit to ask why we'd do that. In letters to the newspaper, he argued it was not un-American.
Steve got mumps and chicken pox at the same time. When he started school, Miss Ott, his first grade teacher, distributed Scotch tape as a threat to anyone who talked as we practiced writing within the lines. We had ink wells with stick pens — you licked the pointed end to get it started. We memorized multiplication tables and did long division by hand. Classes walked en masse from the public school to a nearby church once a week for religious training. Those of us not participating had to do extra math problems. We took French classes in a cloak room because of overcrowding. Steve can still sing Frère Jacques.
We walked to school, including coming home for lunch. Got chased by the Jett boys but had a protector, Gene Hollander, whose family were among the many Jewish refugees from Europe who lived nearby. The Knox Pharmancy on the corner had a soda fountain where Gene worked; with the money he bought the first multi-speed, thin-tired bike we'd seen — a Schwinn World Traveler.
We ran up and down the alley next to our house, pretending to be on a mission with Tom Corbett, Space Cadet. We role-played all the action shows on TV with our best friend, Bruce Szathmary, whose dad played in the Indianapolis Symphony. We dug a hole to China. When we found a construction site, we played with the asbestos and stuff. Steve's grandfather's baseball bat looked like something Honus Wagner used.
Our TV set was a Muntz — at first, it got one channel and we settled for NBC's view of the world. Everyone was afraid of Commies and flying saucers. Uncle was named for Karl Marx, somehow lived through the McCarthy era.
Another of Steve's avocations is collecting cheap, analog watches. He enjoys the many creative ways you can answer the question, "What time is it?"
He doesn't know why men are so fascinated with these anachronisms, but they are a significant use of discretionary income by a lot of us, and the # 1 item advertised in the front section of each week's Sunday New York Times.
He enjoys explaining these little engineering exemplars to his students!
Time is a an enemy and a friend — don't just let it chase you.
Here we see two instances of displaying time using just a third of the watch face. It may not indeed be easier to read, but it's fun.
The unique, 1990-ish Audemars Piguet Star Wheel, left, has 4 hours marked on each of the 3 sapphire wheels, which magically rotate up at the proper time, to point to the correct minutes using the correct hour! And the array of wheels rotates full-circle in 12 hours. It's 10:10 right now. They only made a few, and they still bring $ 12 - 24 k at auction. So, that's out, for Steve's collection!
The Aeromatic 1912 Triple Regulator, right, solves a similar problem by having 3 hands, each pointing to a different band of minutes, on the left, or hours, on the right, with color coding to help overcome the visual confusion. Like, it's 9:25 right now. The "skeleton" areas reveal inner workings, ticking away. More in Steve's price range — €78 direct from the manufacturer.
Teaching the impossible?
The only way to get a grip on ever more interwoven design work is to keep generalizing what you do. Ok, then, how do you teach undergrads how to do that well, when they have not wrestled with the lower levels?
There's high value in knowing people you can rely on.
This is at SEI in Pittsburgh, summer of 2015, at the Software Architecture Educator's Workshop. Shawn is fourth from right. Len Bass, first author of the book we use, is two over from Steve, on the left.
Clinking and clanking:
Many of Steve's students are "kinesthetic thinkers," who engage better in team discussions, in his office, if they have something interesting to do with their hands. He's that way, too!
At top left is "Old Shackles" by Tucker Jones. At top right is the "Patience Puzzle," made by Amish people in Holmes County, OH, among others. Below, Steve's holding an Uncles puzzle that came with a difficulty warning on the box, despite the simple appearance. It's curved slightly because one student stood on it, trying to make the ring come out.
The books behind this last puzzle obfuscate its shape, not the only moment a book has made something less clear! Did you notice that the puzzle is moving? Now try to pretend it is not, after all...
Distractions let the rest of your mind work on a serious problem.
Some students just have to solve one of these puzzles, and Steve lets them borrow the offending item to work on more. They range a lot in difficulty. The goal of the one at top left is to get the ring off. It is widely considered to be "easy," but, initially, it looks impossible, like a lot of what we do in computer science. Does it help if you took topology?
The objective for the Patience puzzle at top right is to get the "traveler" slide out from the row of nails. Only an ocasional student gets it. Steve used it in classes at Bell Labs. One senior member of technical staff worked on it a whole morning without success, then went to lunch. When he walked in after, he "did it" almost in a single gesture. Steve asked him how, and he said, "I don't know."
The Uncles puzzle is a metaphor for engineering problems which appear to be easy, but aren't. Like, how to sort a large file, quickly, or how to display results for a fuzzy search with the most likely answers first.
Standing for something:
Above — Wild horses couldn't drag him away from his new stand-up desk. It is infinitely adjustable down to sitting position, just by tugging on it.
He predicts eventually it will catch on, if the health benefit reports continue.
Below — Making do with available seating, at his Dayton home, Steve works on winter term course materials over Thanksgiving break, 2007. He was revising Software Architecture, adding a research paper assignment, of all things. Did the students end up getting it? Some have built new systems from scratch, including starting their own companies. One now has a Ph.D. in human interface design, a topic this course extended.
He'd say more on what he stands for, or will sit for, but it's time to draw a
and you'll never guess why! Ok, you might.
Just in case it's driving you crazy, check at the end.17
A creative venue is a house loaded with hints.
Above — The puppet in the Anarkali dress is from Steve's former colleague, Abhishek Srivastava. He is now a tenure track prof and acting Dean of Student Affairs, at Indian Institute of Technology, Indore. The artsy double pendulum in front of Steve's glasses is by his younger daughter, Carly, when she was in grade school. The cartoon of him below that was done by Jon Pearson at the 1999 Creative Problem Solving Institute. The open gear clock above the imaged horses is a big hit with Rose students. His hand is on the mouse, clicking this picture, another self-referential — there's an image of this image, on the laptop's screen. Which surely has another one on that... He's lucky he didn't fall through a worm hole. The red and silver track ball reminds him there are alternatives everywhere. The attributed theme of engineering schools, that there is "one right answer," is itself dead wrong.19
The partly revealed "Man on Wire" poster is from the movie concerning Philippe Petit, who can just be seen in between Steve's monitors, illegally crossing from one World Trade Center tower to the other, in 1974. Some of Steve's students identify with this act, an exploit which turns out to be harmless, but still could get you in big trouble, proving, to them, that normal society's values are infirm.
His watch is a Bulova that belonged to his late father-in-law. The sweater is an Ottoman weave. Since this picture was taken, he switched from PC's to Mac's.
Those crazy, caricatured horses are also puppets, by the way. They're in the play "War Horse."
Below — The dining table interloper makes best use of the bay window space at the end. Note pad doubles as mouse pad. It all had to be cleared off every time we ate.
Behind are Christmas dishes from Germany that've seen many years of use. Or, how dated is a china set which includes an ash tray? Inside that slightly ajar lower door, things we'll never look at again.21 Steve's older daughter took this pic, and he raised an eyebrow in response. The house was full, and the Scrabble game was in play.
Steve's sweatshirt is from Gualala, in Northern CA, where the family sometimes spends time in summers. Think crashing Pacific waves and whales, as shown on the shirt.
When giving up, to gain agreement, works:
In his book, The World Until Yesterday, Jared Diamond describes how contrastive "justice" is in tribal societies. There are no prisons, and banishment is roughly a death sentence. When someone is wronged, they still have to live with the perpetrator. Unlike for us, it's mostly a question of compensation to the victims. If your pigs ate their crops, what's the right recourse? What if their fence was broken? And what if they killed one of your pigs?
The parties are poles apart and emotional, for cause. The question is, what has to be done to restore peace? The hope of the tribe is that both sides end up with a resolution they can live with. The process for a Ugandan village is shown in the top image, from Diamond's book.
This is a social, not technical problem. But it is a terrifically useful topic to read up on, a model for how to overcome the worst sorts of difference of opinion, and rejoin as an effective group.
Sometimes friends are only a compromise away.
Here's another model for compromising on a chunk of what you believe must be absolute:
There is a great tradition in labor negotiations, of giving up real value in order to be able to continue a working relationship with co-workers who have fundamentally clashing interests. Each party goes into discussions with the other side, having considered what they really can or can't do without. Each tries, at least, to walk away with those things intact, though they would like more. There is gamesmanship, but plenty of sincerity as well.
At bottom, check-out this 2015 reification close to home — from higher education. In the past, adjunct professors have not been given the same pay, benefits, duration of contracts, or even respect, as have full-time faculty. At Rutgers, this became an issue, because adjuncts are now teaching approximately a third of the classes, but making only a fraction of what full-time faculty are being paid, per course taught, with the same quality expectations.
One can find arguments for why lower pay has invariably been the case. Adjuncts were used to take care of "peaks" and other unanticipated needs, which full-time faculty couln't manage. They usually had other careers, and they were not required to participate in research or service. Because they came and went, they didn't vote on school issues like full-time faculty did, which contributed to giving them lower status.
What has changed now is that they are more often needed, but in the new role of keeping down the cost of higher education. For some of these qualified people, "adjunct professor" has become their main employment, just a low-paid and insecure one. And, because of their oganizational position, they have no power to improve the situation. What you see, at Rutgers here, is their "Boston Tea Party."
Under these changed conditions, if you were a college administrator, what might you be willing to make do with? And, if you are a student, what is your essential stake in it?
Ok, Word says that's over 32 k words, an Steve knows there are over 100 images punctuating. Should be plenty for a single web page, Steve says!
1 Image and commentary from http://www.oxfordstrat.com/ideas/pattern-recognition/. If you're having trouble turning around to picture the illusion, here's the postcard sideways, with a key. Maybe the extra villagers around the mouth are a moustache and beard?
2 1980's image of Columbus Works is from http://cqwe.cboh.org/lc_histories/CB-ColumbusWorks.html.
3 Mind map from https://www.mindtools.com/pages/article/newISS_01.htm.
4 There are of course 47 different ways to separate how the two bridges were designed. Moisseiff played a major role in the design of both bridges, but he worked with Strauss, Ellis, Ammann, Derleth, and others, as a team, on the Golden Gate project. He played a more dominant role on the Tacoma Narrows Bridge, and his design won out over an alternative, based primarily on its low cost. He argued, based on theory, that 8-foot-deep plate girders would provide sufficient stiffness for the bridge.
5 Image from http://www.ubiquitorium.com/woodcut2.htm,which also has some explanations.
6 Image from http://gonzai.com/raymond-loewy-the-self-made-man/.
7 This is the "Industries of the British Commonwealth" scuplture group by Carl Paul Jennewein (1933), over the doors of the British Empire Building, at Rockefeller Center, Midtown Manhattan, New York City. It's pretty typical Art Deco stuff, huh! There's another view at http://travelphotobase.com/v/USNYC/NYE49186.HTM.
8 This is a "grotesque" (gargoyle) at Biltmore House, built in North Carolina in the late 1800's by the Vanderbit family. It's on the back porch of the mansion. See, for example, http://www.wecallitjunkin.com/gargoyles-biltmore-estate/.
9 This is the Hermitage Museum, in St. Petersburg, Russia. It's like city blocks of rooms like this, filled with great art.
10 As of 12/17/2015, the US Bureau of Labor Statistics projects 186,600 new software jobs in the US, in 2014-2024, versus 56,500 for all the other major engineering areas (46,200 for those represented at Rose). This brings the projected total number of software development jobs to 46.3% of all engineering jobs in 2024 (55.2% for those represented at Rose). In 2014, it's already 43.4% of all engineering jobs. For more information, see http://www.bls.gov/ooh/architecture-and-engineering/home.htm and http://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm,
11Garber is chair of Harvard’s Visual and Environmental Studies department and may not strictly see herself as a sociologist. But she writes influentially about social phenomena.
12 See Interaction Design by Preece, Rogers, and Sharp, 4th Ed., pp 256+.
13 Steve doesn't wish to imply that knowing two points of view makes you a better person somehow, or, worse, that you'll agree with him about big issues in life. That's up to you to decide. It's likely to make you feel more fallible, rather like when a CEO hires two different consultants, instead of one, to tell her how to fix a business problem. Or, the way a person who speaks two languages occasionally has to expend energy switching gears when asked a question, because the answer comes to them in the other language.
14 For example, despite many faculty believing students from China are more likely to cheat, the evidence doesn't back it up, and there are associated phenomena that could be more of a cause of cheating than cultural background. Steve's younger daughter knows people from the Russian elite, and they are preoccupied, as are wealthy Chinese families, with having their children attend the best colleges, whether or not they are an academic match. The number of Chinese students expelled for cheating is actually a low percentage of those attending, according to a study just quoted in the Wall Street Journal.
15 Cunningham describes the "technical debt" problem in terms of delayed design work, but it's clear that unanticipated places where the code required change and enhancment underlies the problem of growing design complexity. In Fowler's quadrants, the prudent decision to "ship now and deal with the consequences" may or may not be a fully informed decision.
16 Ok, Steve's mother almost surely took that image with this Agfa Pioneer, amateur-grade, 620 roll film camera that produced 6x9 cm negatives. The viewfinder makes you squint, and she was not comfortable taking pictures. You can argue that such things can be setup, posed, and framed. But, most likely, she didn't even say, "smile." The camera now sits on Steve's office shelf, next to other photo relics. It was styled by industrial designer Henry Dreyfuss, also famous for his work at Bell Telephone. Agfa-Gevaert, a 140-year-old Belgian company, now makes specialty imaging products. Like Kodak, they were onto the marketing ploy of offering cameras cheaply in order to stimulate film sales. Steve liked their 35mm slide film, which had deeper colors. See example on Wikipedia. He processed it himself, using the same chemicals as for Ektachrome. In this picture of Steve taking a picture, the wooden bird appears to be making a run for it. Or is it a fly for it? There's a gong in the background, below Communist propaganda posters. You'll have to guess why the small spotlight below the shelf.
17 This was Steve's solution to making the first table column fixed width, and it works on three different browsers.
18 An em dash is —, among other things. The line in "A visit from St. Nicholas" before that is "To the top of the porch! To the top of the wall!" You gotta believe it ends with "wall" only for the rhyme.
19 In engineering, this idea probably goes back, at least down one branch, to efficiency expert Frederick Taylor's notion that there was "one best way" to do factory work. He was very influential and one time president of ASME. He notoriously considered only improviement of production goals, a single perspective.
20 Rug designs from https://en.wikipedia.org/wiki/Persian_carpet and http://www.persiancarpetwarehouse.com/home.php?cat=256.
21 Ok, Steve looked, just because of saying that. Everyone has a place for miscellaneous dishes and such. Among ours there, two beautiful Royal Worcester decorative square plates Steve won at a United Way pedge drive prize giveaway in 1974. We drew for order of selection and Steve was # 50. Guys before him were picking through mechanical gadgets, but Steve had brought his wife, who chose these. Looks like they're now going for about $ 100. You can see his reaction to that. Could be on Antiques Roadshow. Steve should revisit the cupboard occasionally. And maybe the one behind him? Your projects may also have buried treasure, like features you did long ago and forgot.
22 Steve knows it's unusual to serialize web content. And very old-timey in one way. Yet it also is novel to do it that way intentionally, when the content itself is not meant particularly to be read in any special order. This does give you a better chance to flip through it all, noticing things by chance, than if most of it were just hot-linked and otherwise invisible..
23 The Far Side ® and the Larson ® signature are registered trademarks of FarWorks, Inc. Copyright © 2000, 2007 FarWorks, Inc. All Rights Reserved. Image from http://mikelynchcartoons.blogspot.com/2010/07/there-is-much-truth-in-old-far-side.html.
24 Not van Goghy enough? How about in contrast to his second 1990 portrait of Dr. Gachet, reproduced here. Steve played with the outlines more. The first version van Gogh did of this portrait has the more sketchy, brush-stroked sky, but this one shows the same use of suggestion, expression, gesture, pose, image texture, and foreground objects that Steve employed.
25 So, the question is, at what point do you say, "It works"? At left we see, a fraction of a second later, a better indication of how this particular flight would turn out — straight into the drink. If undergrad engineers are taught always to quit at the first sign of success and go on to something entirely new, that's the wrong message with which to send them out into industry. Perhaps a part of the problem is that this is how academic researchers operate, themselves? If we can get a paper out of it, and picture how someday this might be useful, psychologically it's "almost done" and time to go on to something else. At AT&T, our heuristic was that, when anyone in research declared a new technology was ready to be used in products, more likely anywhere from 1 to 20 times as much work would be required to "productize" it.
Mixed into this training / mistraining issue is the question of "who" gets to announce it's successful. The newspapers observing Langley's flights didn't think this was it, and panned the effort and the public expense. One reported that the craft "slid into the water like a handful of wet mortar." The Boston Herald suggested Langley try submarines next. The Brooklyn Eagle said "the only thing he ever made fly was government money." The original wings were just too flimsy, but Langley insisted it was airworthy. The Smithsonian named a medal after him and awarded the first one to the Wrights. At the ceremony, Langley was lauded more than the Wrights, who then declined to give their original Flyer to the museum. In 1914, the Smithsonian reopened Langley's laboratory and finally cranked up a "proof of concept" flight, using a highly modified version of Langley's plane, not telling how much it was changed, then retroactively trying to pretend Langley's effort was the first bonified human-carrying heavier-than-air craft. Orville Wright already had sued and won a court case about who was first, but the Smithsonian continued to say it for three more decades. There was a lot of pride at stake. And a lot of the action had taken place around Washington, D.C., where politics is king.
26 Ok, there are answers to that question. Doing this puts me out there with Flavor Flav. In current politics, as Steve writes this, Bernie Sanders talks about himself in the third person. He's just the latest person in the public eye to do so. Technically, it is called "illeism," and it has its own Wikipedia page. Like Julius Caesar, Steve does it here to gain a little objective impartiality. When he journals, he never does this. His favorite usage is in British Parliament, where the members refer to each other this way even when addressing the other person directly.
Background: Zen pipe courtesy of Magritte, though ocean-rippled diluted sideways web site background probably was not how he envisioned its presentation. After http://serendip.brynmawr.edu/local/collegesembio1.html.