May 28, 2015 2:11 PM

The Grand Complications of Software

Yesterday, Sean Heber made a suggestion drawn, I imagine, from Apple's foray into the world of watchmaking:

I propose we adopt the watch term "complications" for all software features.

It turns out that, in the world of horology, complication is a technical term:

In horology, the study of clocks and watches, a complication refers to any feature in a timepiece beyond the simple display of hours and minutes. A timepiece indicating only hours and minutes is otherwise known as a simple movement.

I don't know if Heber was writing tongue in cheek, but "complication" is certainly a term that programmers can appreciate. In software, we value functions, classes, modules, and even whole systems that do only one thing but do it well. This is sometimes referred to as the single responsibility principle, which engenders a separation of concerns and leads to software that is easier to modify and maintain. Simple movement is one of the defining elements that make up of the the Unix philosophy:

Write programs that do one thing and do it well. Write programs to work together.

In Unix, there is even a standard interface for simple movements, the text stream, which enables almost trivial little programs to be combined to solve any problem.

Horology's use of "complication" also reminds me of Rich Hickey's adoption of the word complect for talking about software systems. See, for example, his RailsConf 2012 talk, Simplicity Matters. Tools that interleave multiple strands of functionality are inherently less reliable, in addition to being harder to work with, so we should seek to create tools with a single strand.

In order to talk about timekeeping devices that perform several functions, watchmakers specialize their term. Informally, a grand complication is a device that contains at least three complications, with at least one timing complication, one astronomical complication, and one striking complications. It might be instructive to classify in a similar fashion the ways in which programmers typically "complect" their code.

The Wikipedia page for "complication" states explicitly that adding complications to a watch makes it more difficult to "design, create, assemble, and repair". That sounds a lot like how programmers feel about complexity. But the page also gives the sense that fine watchmakers revel in complications and see them as a sign of great achievement. Some watchmakers even glory in the complexity of their timepieces.

It seems that watchmakers have more in common with programmers than you might think. Perhaps Heber is on to something here.


Posted by Eugene Wallingford | Permalink | Categories: Software Development

May 26, 2015 2:59 PM

If You Want to Help Students, You May Want to Help Faculty

In The Missing Middle, Matt Reed recommends a way for donors to have a real effect at teaching universities: pay for conference travel.

I've mentioned before that the next philanthropist who wants to make a massive difference in the performance of teaching-intensive public colleges -- whether community colleges or the smaller four-years -- could do it by underwriting conference travel. Right now, most colleges are lucky to send one or two people to most conferences. When an entire team attends the same presentation, it's much easier to get what chemists call activation energy. I've seen it personally.

This echoes a conversation the department heads in my college had earlier this month. Ongoing professional development is important for faculty, both in their research and their teaching. Faculty who are struggling in the classroom need more help than others, but even good teachers need to have their batteries charged every once in a while.

There tends to be more support for faculty development in their research than in their teaching, even at so-called teaching universities. Even so, professional development in research is often a natural side effect of external funding for research, and faculty at these universities don't always conduct research at a scale that is competitive for external funding.

And faculty development in their teaching? There aren't many sources to support this other than the university budget itself. Given the current state of funding for public universities, which is likely the new normal, these funds are being squeezed out of the budget, if they were ever present at all.

Professors need to stay current in their profession, and many need to address weaknesses over the course of their careers. When universities neglect faculty development, the faculty suffer, and so do their students. Often, the best way to help students is to help the faculty.

All that said, I am not holding my breath that dollars will be coming in from donors any time soon. People love to help students directly, but indirect support for students and support for other parts of the university are notoriously hard sells.


Posted by Eugene Wallingford | Permalink | Categories: General

May 22, 2015 1:58 PM

When It Comes to Learning, Motivation and Study Habits Trump Technology

A lot of people have been talking about Kentaro Toyama's Why Technology Will Never Fix Education, which appeared in the Chronicle of Higher Education earlier this week. Here is the money paragraph:

The real obstacle in education remains student motivation. Especially in an age of informational abundance, getting access to knowledge isn't the bottleneck, mustering the will to master it is. And there, for good or ill, the main carrot of a college education is the certified degree and transcript, and the main stick is social pressure. Most students are seeking credentials that graduate schools and employers will take seriously and an environment in which they're prodded to do the work. But neither of these things is cheaply available online.

My wife just completed the second of two long-term substitute teaching assignments this year in a local elementary school, so we have been discussing the daily challenges that teachers face. The combination of student motivation and support at home account for most of the variation in how well students perform and how well any given class operates. I see a similar pattern at the university. By the time students reach me, the long-term effects of strong or weak support at home has crystallized into study habits and skills. The combination of student motivation and study skills account for most of the variation I see in whether students succeed or struggle in their university courses.

This all reminds me of a short passage from Tyler Cowen's book, Average Is Over:

The more information that's out there, the greater the returns to just being willing to sit down and apply yourself. Information isn't what's scarce; it's the willingness to do something with it.

The easy availability of information made possible by technology places a higher premium on the ability of students to sit down and work hard, and the willingness to do so. We can fool ourselves into thinking we know more than we do when we look things up quickly, but many students can just as easily access the same information.

We have found ways to use technology to make information easily available, but we haven't found a way to make motivation an abundant resource. Motivation has to come from within. So do the skills needed to use the information. We can at least help students develop study habits and skills through school and family life, though these are best learned early in life. It is hard for students to change 15-20 years of bad habits after they get to college.

The irony for young people is that, while they live in an era of increasingly available information, the onus rests more than ever on what they do. That is both good news and bad.


Posted by Eugene Wallingford | Permalink | Categories: Teaching and Learning

May 13, 2015 12:12 PM

The Big Picture

I just turned in my grades. For the most part, this is boring paperwork. Neither students nor faculty really like grades; they are something we all have to do as a part of the system. A lot of people would like to change the system and eliminate grades, but every alternative has its own weaknesses. So we all muddle along.

But there is a bigger picture, one which Matt Reed expresses eloquently:

Tolstoy once claimed that there are really only two stories, and we keep telling each of them over and over again: a stranger comes to town, and a hero goes on a quest. In higher education, we live those two stories continuously. Every semester, a new crop of strangers come to town. And every semester, we set a new group of heroes off on their respective quests.

It's May, so we see a new group of young people set of on their own quests. In a few months, we will welcome a new group of strangers. In between are the students who are in the middle of their own "stranger comes to town" story, who will return to us in the fall a little different yet much the same.

That's the big picture.


Posted by Eugene Wallingford | Permalink | Categories: Teaching and Learning

May 09, 2015 9:28 AM

A Few Thoughts on Graduation Day

Today is graduation day for the Class of 2015 at my university. CS students head out into the world, most with a job in hand or nearly so, ready to apply their hard-earned knowledge and skills to all variety of problems. It's an exciting time for them.

This week also brought two other events that have me thinking about the world in which my students my will live and the ways in which we have prepared them. First, on Thursday, the Technology Association of Iowa organized a #TechTownHall on campus, where the discussion centered on creating and retaining a pool of educated people to participate in, and help grow, the local tech sector. I'm a little concerned that the TAI blog says that "A major topic was curriculum and preparing students to provide immediate value to technology employers upon graduation." That's not what universities do best. But then, that is often what employers want and need.

Second, over the last two mornings, I read James Fallows's classic The Case Against Credentialism, from the archives of The Atlantic. Fallows gives a detailed account of the "professionalization" of many lines of work in the US and the role that credentials, most prominently university degrees, have played in the movement. He concludes that our current approach is biased heavily toward evaluating the "inputs" to the system, such as early success in school and other demonstrations of talent while young, rather than assessing the outputs, namely, how well people actually perform after earning their credentials.

Two passages toward the end stood out for me. In one, Fallows wonders if our professionalized society creates the wrong kind of incentives for young people:

An entrepreneurial society is like a game of draw poker; you take a lot of chances, because you're rarely dealt a pat hand and you never know exactly what you have to beat. A professionalized society is more like blackjack, and getting a degree is like being dealt nineteen. You could try for more, but why?

Keep in mind that this article appeared in 1985. Entrepreneurship has taken a much bigger share of the public conversation since then, especially in the teach world. Still, most students graduating from college these days are likely thinking of ways to convert their nineteens into steady careers, not ways to risk it all on the next Amazon or Über.

Then this quote from "Steven Ballmer, a twenty-nine-year-old vice-president of Microsoft", on how the company looked for new employees:

We go to colleges not so much because we give a damn about the credential but because it's hard to find other places where you have large concentrations of smart people and somebody will arrange the interviews for you. But we also have a lot of walk-on talent. We're looking for programming talent, and the degree is in no way, shape, or form very important. We ask them to send us a program they've written that they're proud of. One of our superstars here is a guy who literally walked in off the street. We talked him out of going to college and he's been here ever since.

Who would have guessed in 1985 the visibility and impact that Ballmer would have over the next twenty years? Microsoft has since evolved from the entrepreneurial upstart to the staid behemoth, and now is trying to reposition itself as an important player in the new world of start-ups and mobile technology.

Attentive readers of this blog may recall that I fantasize occasionally about throwing off the shackles of the modern university, which grow more restrictive every year as the university takes on more of the attributes of corporate and government bureaucracy. In one of my fantasies, I organize a new kind of preparatory school for prospective software developers, one with a more modern view of learning to program but also an attention to developing the whole person. That might not satisfy corporate America's need for credentials, but it may well prepare students better for a world that needs poker players as much as it needs blackjack players. But where would the students come from?

So, on a cloudy graduation day, I think about Fallows's suggestion that more focused vocational training is what many grads need, about the real value of a liberal university education to both students and society, and about how we can best prepare CS students participate to in the world. It is a world that needs not only their technical skills but also their understanding of what tech can and cannot do. As a society, we need them to take a prominent role in civic and political discourse.

One final note on the Fallows piece. It is a bit long, dragging a bit in the middle like a college research paper, but opens and closes strongly. With a little skimming through parts of less interest, it is worth a read. Thanks to Brian Marick for the recommendation.


Posted by Eugene Wallingford | Permalink | Categories: Computing, General, Teaching and Learning

April 30, 2015 6:00 PM

Software is a Means of Communication, Just Like a Research Paper

I can't let my previous post be my only comment on Software in Scientific Research. Hinsen's bigger point is worth a post of its own.

Software is a means of communication, just like papers or textbooks.

... much like the math that appears in a paper or a textbook -- except that, done properly, a computer program runs and provides a dynamic demonstration of an idea.

The main questions asked about scientific software [qua software] are "What does it do?" and "How efficient is it?" When considering software as a means of communication, we would ask questions such as "Is it well-written, clear, elegant?", "How general is the formulation?", or "Can I use it as the basis for developing new science?".

This shift requires a different level of understanding of programs and programming than many scientists (and other people who do not program for a living) have. But it is a shift that needs to take place, so we should so all we can to help scientists and others become more fluent. (Hey to Software Carpentry and like-minded efforts.)

We take for granted that all researchers are responsible for being able to produce and, more importantly, understand the other essential parts of scientific communication:

We actually accept as normal that the scientific contents of software, i.e., the models implemented by it, are understandable only to software specialists, meaning that for the majority of users, the software is just a black box. Could you imagine this for a paper? "This paper is very obscure, but the people who wrote it are very smart, so let's trust them and base our research on their conclusions." Did you ever hear such a claim? Not me.

This is a big part of the challenge we face in getting faculty across the university to see the vital role that computing should play in modern education -- as well as the roles it should not play. The same is true in the broader culture. We'll see if efforts such as code.org can make a dent in this challenge.


Posted by Eugene Wallingford | Permalink | Categories: Computing, General

April 29, 2015 1:52 PM

Beautiful Sentences: Scientific Data as Program

On the way to making a larger point about the role of software in scientific research, Konrad Hinsen writes these beautiful sentences:

Software is just data that can be interpreted as instructions for a computer. One could conceivably write some interpreter that turns previously generated data into software by executing it.

They express one side of one of the great ideas of computer science, the duality of program and data:

  • Every program is data to some other program, and
  • every set of data is a program to some machine.

This is one of the reasons why it is so important for CS students to study the principles of programming languages, create languages, and build interpreters. These activities help bring this great idea to life and prepare those who understand it to solve problems in ways that are otherwise hard to imagine.

Besides, the duality is a thing of beauty. We don't have to use it as a tool in order to appreciate this sublime truth.

As Hinsen writes, few people outside of computer science (and, sadly, too many within CS) appreciate "the particular status of software as both tool an information carrier and a tool". The same might be said for our appreciation of data, and the role that language plays in bridging the gap between the two.


Posted by Eugene Wallingford | Permalink | Categories: Computing, Teaching and Learning

April 27, 2015 2:33 PM

The Program Is In The Programming

I would rather have too little architecture
than too much because that might interfere
with the truth of what I say.
-- Ivan Turgenev

How can agile approaches to software development create coherent programs? Don't we need a plan, a well-thought-out design to follow closely? Without one, won't we end up with a mess?

Let's turn again to Italo Calvino for some perspective. He is known for novels with intricate structure and acknowledges that, for at least a decade, the "architecture" of his books occupied more of his mind than it should have. Yet his novels never seemed to follow closely any of his advance plans:

I spend a lot of time constructing a book, making outlines that eventually prove to be of no use to me whatsoever. I throw them away. What determines the book is the writing, the material that's actually on the page.

The ultimate architecture of a book comes to life alongside the book itself, hand-in-hand with the writing.

And so it can be with software. Programmers can and should think about what they are building but, in the end, what determines the program is the programming, the material that's actually on the page or in the browser.

Again, we must careful not to take the analogy too far. Programs are often created for external clients with specific technical requirements. Programmers are not usually free, as novelists are, to change the product they are creating. Even so, design is how we make the product, not what it does. Whether it evolves during the course of programming or is specified up-front, the client can receive the product they asked us to make.

Ward Cunningham once gave what is, for me, still the best definition of design:

Design is the thinking you do when you make something.

The most important product of that thinking is not a design document or an architecture. It is the mind that is prepared to make the thing you need to make.


Posted by Eugene Wallingford | Permalink | Categories: Software Development

April 26, 2015 9:55 AM

Yesterday's Questions Can Have Different Answers Today

I wrote on Twitter Thursday [ 1 | 2 ] that I end up modifying my lecture notes every semester, no matter how well done they were the last time I taught the course. From one semester to the next, I find that I am more likely to change the introductions, transitions, and conclusions of a session than the body. The intros, transitions, and conclusions help to situate the material in a given place and time: the context of this semester and this set of students. The content, once refined, tends to stabilize, though occasionally I feel a need to present even it in a different way, to fit the current semester.

Novelist Italo Calvino knew this feeling as well, when he was preparing to be interviewed:

Rarely does an interviewer ask questions you did not expect. I have given a lot of interviews and I have concluded that the questions always look alike. I could always give the same answers. But I believe I have to change my answers because with each interview something has changed either inside myself or in the world. An answer that was right the first time may not be right again the second.

This echoes my experience preparing for lecture. The answer that was right the last time does not seem right again this time. Sometimes, I have changed. With any luck, I have learned new things since the last time I taught the course, and that makes for a better story. Sometimes, the world has changed: a new programming language such as Clojure or Scala has burst onto the scene, or a new trend in industry such as mobile app development has made a different set of issues relevant to the course. I need to tell a different story that acknowledges -- and takes advantage of -- these changes.

Something else always changes for a teacher, too: the students. It's certainly true the students in the class are different every time I teach a course. But sometimes, the group is so different from past groups that the old examples, stories, and answers just don't seem to work. Such has been the case for me this semester. I've had to work quite a bit to understand how my students think and incorporate that into my class sessions and homework assignments. This is part of the fun and challenge of being a teacher.

We have to be careful not to take this analogy too far. Teaching computer science is different from an author giving an interview about his or her life. For one thing, there is a more formal sense of objective truth in the content of, say, a programming language course. An object is still a closure; a closure is still an object that other code can interact with over time. These answers tend to stay the same over time. But even as a course communicates the same fundamental truths from semester to semester, the stories we need to tell about these truths will change.

Ever the fantastic writer, Calvino saw in his interview experience the shape of a new story, a meta-story of sorts:

This could be the basis of a book. I am given a list of questions, always the same; every chapter would contain the answers I would give at different times. ... The changes would then become the itinerary, the story that the protagonist lives. Perhaps in this way I could discover some truths about myself.

This is one of the things I like about teaching. I often discover truths about myself, and occasionally transform myself.

~~~~

The passages quote above come from The Art of Fiction No. 130, Italo Calvino in The Paris Review. It's not the usual Paris Review interview, as Calvino died before the interviewer was done. Instead, it is a pastiche of four different sources. It's a great read nonetheless.


Posted by Eugene Wallingford | Permalink | Categories: General, Teaching and Learning

April 20, 2015 4:02 PM

"Disjunctive Inference" and Learning to Program

Over the weekend, I read Hypothetical Reasoning and Failures of Disjunctive Inference, a well-sourced article on the problems people have making disjunctive inferences. It made me think about some of the challenges students have learning to program.

Disjunctive inference is reasoning that requires us to consider hypotheticals. A simple example from the article is "the married problem":

Jack is looking at Ann, but Ann is looking at George. Jack is married, but George is not. Is a married person looking at an unmarried person?
  1. Yes.
  2. No.
  3. Cannot be determined.

The answer is yes, of course, which is obvious if we consider the two possible cases for Ann. Most people, though, stop thinking as soon as they realize that the answer hinges on Ann's status. They don't know her status, so they can't know the answer to the question. Even so, most everyone understands the answer as soon as the reasoning is explained to them.

The reasons behind our difficulties handling disjunctive inferences are complex, including both general difficulties we have with hypotheticals and a cognitive bias sometimes called cognitive miserliness: we seek to apply the minimum amount of effort to solving problems and making decisions. This is a reasonable evolutionary bias in many circumstances, but here it is maladaptive.

The article is fascinating and well worth a full read. It points to a number of studies in cognitive psychology that seek to understand how humans behave in the face if disjunctive inferences, and why. It closes with some thoughts on improving disjunctive reasoning ability, though there are no quick fixes.

As I read the article, it occurred to me that learning to program places our students in a near-constant state of hypothetical reasoning and disjunctive inference. Tracing code that contains an if statement asks them to think alternative paths and alternative outcomes. To understand what is true after the if statement executes is disjunctive inference.

Something similar may be true for a for loop, which executes once each for multiple values of a counter, and a while loop, which runs an indeterminate number of times. These aren't disjunctive inferences, but they do require students to think hypothetically. I wonder if the trouble many of my intro CS students had last semester learning function calls involved failures of hypothetical reasoning as much as it involves difficulties with generalization.

And think about learning to debug a program.... How much of that process involves hypotheticals and even full-on disjunctive inference? If most people have trouble with this sort of reasoning even on simple tasks, imagine how much harder it must be for young people who are learning a programming language for the first time and trying to reason about programs that are much more complex than "the married problem"?

Thinking explicitly about this flaw in human thinking may help us teachers do a better job helping students to learn. In the short term, we can help them by giving more direct prompts for how to reason. Perhaps we can also help them learn to prompt themselves when faced with certain kinds of problems. In the longer term, we can perhaps help them to develop a process for solving problems that mitigates the bias. This is all about forming useful habits of thought.

If nothing else, reading this article will help me be slower to judge my students's work ethic. What looks like laziness is more likely a manifestation of a natural bias to exert the minimum amount of effort to solving problems. We are all cognitive misers to a certain extent, and that serves us well. But not always when we are writing and debugging programs.


Posted by Eugene Wallingford | Permalink | Categories: Computing, Teaching and Learning