The big soft­ware defect story of the past cou­ple of days is def­i­nitely Vassar’s acci­den­tal send­ing of accep­tance noti­fi­ca­tions to sev­eral stu­dents. It’s a great exam­ple of one of the con­se­quences of putting an algo­rithm (and indi­rectly, a pro­gram­mer), in charge of dis­sem­i­nat­ing infor­ma­tion. On the one hand, I’m sure this saved Vas­sar a lot time and per­haps a job or two, com­pletely elim­i­nat­ing their need for post and paper. On the other hand, they’ve adopted a sys­tem that is going to fail from time to time, and not in grace­ful ways that paper does, but in big, dra­matic, and unpre­dictable ways.

The unpre­dictabil­ity of soft­ware defects is one of the most inter­est­ing prop­er­ties of soft­ware as a medium. It’s inher­ent com­plex­ity means that even the peo­ple who develop it are going to have a hard time know­ing what part of the sys­tem will fail and how dra­mat­i­cally. In fact, if the devel­oper fol­lows best prac­tices by mod­u­lar­iz­ing the sys­tem and enabling it to scale grace­fully, it will actu­ally guar­an­tee that the fail­ures will be more dra­matic: whether it’s a list of 1, 100, or 1,000,000, I’m sure the Vas­sar noti­fi­ca­tion sys­tem algo­rithm will do the exact same thing.

I won­der how soft­ware might be built to bet­ter account for the sig­nif­i­cance of the infor­ma­tion it trans­mits and com­putes. At the moment, I sup­pose this is cap­tured in the soft­ware tests that teams per­form. Per­haps a bet­ter way might be to tag the data that moves through soft­ware sys­tems and prop­a­gate things like the con­fi­dence, cred­i­bil­ity, and integrity of data as algo­rithms munge and manip­u­late it.

A few days ago in the NY Times, there was a story reflect­ing on Amber Case’s idea that we are all cyborgs, using a wide range of tools for both phys­i­cal and men­tal mod­i­fi­ca­tion. The key idea in the story is lament­ing the loss of mem­o­ries that have phys­i­cal embod­i­ments, such as a pho­to­graph that has both mean­ing in what it con­tains, but also mean­ing in it’s phys­i­cal con­tainer. In con­trast, the dig­i­tal pho­tographs of today still have their mean­ing, but the con­tainer is mean­ing­less, because it’s vir­tual. It could just as eas­ily be opened on one of a hun­dred photo view­ing appli­ca­tions and dis­played in an infi­nite num­ber of ways and devices.

To me, the divorce of infor­ma­tion from embod­i­ment is one of the most pow­er­ful but sub­ver­sive aspects of soft­ware as a medium. It under­lies nearly every major change in indus­try cur­rently under debate, includ­ing music, print, libraries, pub­lish­ing, jour­nal­ism, movies, and every other kind of media. But the ques­tion that I still puz­zle over is whether this divorce is a nec­es­sary part of pre­serv­ing the power of com­put­ing. Does the abil­ity to change a photo’s con­tainer require that the con­tainer doesn’t have mean­ing? Or, put another way, do peo­ple ascribe mean­ing to their cell phones and dig­i­tal photo frames, even though they can now dis­play any photo in the world?

An inter­est­ing case of this hap­pened a few months ago when my iPhone’s USB port died and I could no longer charge it. It had a few iden­ti­fi­able scuffs on it, and I cer­tainly had a mem­ory for all of the places that I’d been with it and all of the pho­tos I’d taken with it. But when I exchanged it for a nearly iden­ti­cal replace­ment phone, it only felt for­eign for a few days. In fact, some­times I mis­take it for my old phone. This spe­cial case of an iden­ti­cal but dif­fer­ent con­tainer is an inter­est­ing ones, because it speaks directly to the ques­tion at hand: what mean­ing, if any, is there in phys­i­cal objects, other than our mem­o­ries of them?

I get this ques­tion a lot from stu­dents, friends, and fam­ily, but I’m never quite sure how to answer it. Research? Teach­ing? Ser­vice? Those don’t really cap­ture what the job is really like. So I decided to write every­thing down in a big long list at the end of today, cap­tur­ing every sin­gle goal accom­plished, every sin­gle e-mail I sent, and every sin­gle con­ver­sa­tion I had. See if you can find the  research!

• 6:30–6:31 Woke up at 6:30 am still feel­ing under the weather and with another recur­ring corneal abra­sion in my right eye. Applied eye-drops.
• 6:32–6:40 Read e-mail in bed for a few minutes.
• 7:00–7:15 Read more e-mail while eat­ing break­fast, set meet­ing with tech trans­fer depart­ment for next week.
• 7:15–7:30 Loaded CHI PC chair­ing site and assigned a few 2ACs
• 7:35–7:50 Left for work and arrived in the cen­tral garage
• 7:50–8:00 Got cof­fee from Mary Gates cafe and briefly said hi to Karen Fisher and Joe Ten­nis in the hallway.
• 8:00–8:02 Sent e-mail about paper con­flicts for CHI PC for assign­ing 2ACs.
• 8:00–8:05 Sched­uled doctor’s appoint­ment about eye.
• 8:05–8:35 Spent 30 min­utes assign­ing 2ACs to 25 papers
• 8:35–9:10 Spent 35 min­utes craft­ing epic e-mail to junior Ph.D. stu­dent who is wor­ried about his Ph.D. topic and unsure about next steps.
• 9:10:9:30 Revised slides for lec­ture for 18 min­utes, improv­ing clar­ity over last year’s version.
• 9:30–9:32 Responded to fol­lowup e-mail from direc­tor of cor­po­rate rela­tions about cor­po­rate con­nec­tions I made at last week’s research fair.
• 9:32–9:35 Responded to e-mail about affil­i­ate sta­tus renewal for affil­i­ate faculty
• 9:35–9:45 Spent 10 more min­utes assign­ing 2AC review­ers for CHI papers
• 9:45–10:10 Spent more time improv­ing slides for lecture
• 10:20–11:00 Left for class and lec­tured for 30 min­utes about lim­i­ta­tions and assump­tions in designs
• 11:00–11:20 Led activ­ity using sim­u­lated impair­ments on mobile devices to elicit assumptions
• 11:20–12:15 Led activ­ity in which teams brain­stormed assump­tions in their own design projects
• 12:15–12:25 Fin­ished class at 12:15 and spend 10 min­utes eat­ing lunch
• 12:25–12:30 Responded to e-mail about plan­ning dub retreat
• 12:30–12:35 Responded to e-mail about when 2ACs need to fin­ish their reviews by
• 12:35–12:40 Responded to e-mail about cor­po­ra­tiz­ing universities
• 12:40–12:45 Spoke briefly with Scott Barker about how many in-class hours the new cap­stone should include
• 12:45–12:50 E-mails to stu­dent who wants into INFO 461 next quarter
• 12:45–1:15 Drove to Kirk­land to work at library to avoid traf­fic from 1
• 1:15–1:18 Responded to e-mail approv­ing new mem­ber to EUSES consortium
• 1:18–3:18 Copied pro­posal draft to hard drive for writ­ing and worked on dia­grams for Cyber­learn­ing pro­posal draft.
• 3:18–3:23 Dri­ving to car line
• 3:23–3:30 Wait­ing in car line
• 3:30–4:20 Get­ting snacks for Elle before swim practice
• 4:20–4:35 Writ­ing e-mail to col­leagues about frus­tra­tion around method­olog­i­cal rifts among faculty
• 4:35–4:45 Tak­ing Elle into swim practice
• 4:45–4:58 Writ­ing stu­dent ser­vices staff about Spring cap­stone event
• 4:58–5:00 Reply­ing to stu­dent about spring cap­stone team
• 5:00–5:08 Reply­ing to request about all school meet­ing par­tic­i­pa­tion con­flict­ing with my final exam schedule
• 5:08–5:15 Writ­ing co-PI about updated fig­ures in pro­posal draft
• 5:15–5:25 Writ­ing this list
• 5:25–5:30 Call with ex about Thanks­giv­ing plans
• 5:35–5:41 Fin­ish­ing this list
• 5:41–5:48 Edit­ing this list and press­ing the pub­lish post button.

Abstrac­tions and the abil­ity to cre­ate them are what make us human. Our abil­ity to rea­son abstractly and sym­bol­i­cally, to rep­re­sent what we see and do and to cap­ture and uti­lize knowl­edge is fun­da­men­tal to all forms of human progress and com­mu­ni­ca­tion. And when we think care­fully about what role abstrac­tions have played in human soci­ety, we see that our abil­ity to reduce the incred­i­ble com­plex­i­ties of the world to their essen­tial natures is behind nearly every­thing we do as humans.

When look­ing back on recent his­tory, how­ever, it is pos­si­ble that human­ity has made a fun­da­men­tal shift in its use of abstrac­tions. We have always used abstrac­tions to com­mu­ni­cate and talk, to coor­di­nate, to under­stand nature and build tech­nolo­gies, from weapons to print­ing presses to com­put­ers, to con­cep­tu­al­ize the essen­tial nature of nature, and bend it to our wills and desires. Abstrac­tions, I would argue, have been the pri­mary medi­a­tors between human­ity and nature, besides our bod­ies. The axe or the ham­mer are not sim­ply wood and metal, they are instan­ti­a­tions of abstract ideas that human­ity has car­ried from gen­er­a­tion to gen­er­a­tion. It is only through the idea of a ham­mer that a ham­mer can exist.

In just the past cen­tury, how­ever, our use of abstrac­tions has evolved. We now reg­u­larly use abstrac­tions not only to medi­ate our rela­tion­ship to nature, but also to medi­ate rela­tion­ships with our­selves and oth­ers. Take, for exam­ple, the notion of IQ tests. These use of these tests is not sim­ply to assess: the tak­ers of these tests con­sume the results of the test and use such infor­ma­tion to change per­cep­tions of them­selves. Or, con­sider any mod­ern com­mu­ni­ca­tion medium, such as e-mail or text mes­sag­ing. These abstract forms of face to face com­mu­ni­ca­tion medi­ate, con­strain and mold our con­ver­sa­tions in very spe­cific ways.

This in itself isn’t prob­lem­atic. After all, abstrac­tions, by def­i­n­i­tion, elim­i­nate detail in order to facil­i­tate com­mu­ni­ca­tion and action, so there are bound to be abstrac­tion fail­ures and mis­match; their inher­ent min­i­mal­ism is also what makes abstrac­tions use­ful, by help­ing us to man­age the com­plex­ity of the world.

But there is a more nefar­i­ous way in which our use of abstrac­tions may change human behav­ior: in many sit­u­a­tions, we view abstrac­tions not as a means to an end, but an end in them­selves. We begin to mis­take the abstrac­tion for the thing it represents.

There are sev­eral cul­tural memes that high­light this phe­nom­ena. “Gam­ing the sys­tem,” for exam­ple, is the idea that some­one will exploit prop­er­ties of a sys­tem of rules or poli­cies in order to effect results that vio­late the intent of the rules; Baker et al. doc­u­mented this behav­ior in edu­ca­tional tutor­ing soft­ware, where stu­dents would learn the con­di­tions in which the soft­ware would pro­vide aid or answers, and do pre­cisely the actions nec­es­sary to most quickly acquire the aid or answers.

Other exam­ples are not about exploita­tion, but prag­ma­tism. For exam­ple, stu­dents in high schools and uni­ver­si­ties want to acquire knowl­edge and skills, but per­ceive that it is scores, grades, and degrees—our abstrac­tions of learn­ing in mod­ern education—that are truly impor­tant, and not the learn­ing itself. The dan­ger here is less at the indi­vid­ual level (as an indi­vid­ual stu­dent may over­come this through reflec­tion), and more at a soci­etal and cul­tural level: over time, it is pos­si­ble that the abstrac­tions rep­re­sent­ing knowl­edge become so insti­tu­tion­al­ized that soci­ety for­gets what they were intended to represent.

I see these abstrac­tion appro­pri­ate every day when I teach. Just yes­ter­day I had an enjoy­able, but dis­heart­en­ing dis­cus­sion with a cou­ple of stu­dents near grad­u­a­tion who were dis­ap­pointed in their final grades for a course I taught last quar­ter. Their con­cern was that the grade points they received, which were one or two tenths lower than the grade points they typ­i­cally receive, would lower their GPA sev­eral hun­dredths. I assured them I under­stood their con­cern, but also pointed out to them that there was prob­a­bly not a sin­gle per­son who would ever look at that grade, nor the tenths place of their grade, ever again in their lives. One of them men­tioned grad­u­ate school appli­ca­tions and I insisted, if they were above a 3.7, what would really mat­ter were their let­ters, pub­li­ca­tions, and expe­ri­ence, since the num­ber doesn’t really mean much of anything.

This was dis­ap­point­ing to them, to say the least. I reas­sured them that it was the prod­ucts of their work, and the expe­ri­ence they had gained in the course, that would be the truly last­ing parts of their edu­ca­tion, and that the num­bers meant noth­ing. They thanked me for my time and walked away slightly con­fused, unsure about what other strange quan­ti­ta­tive incen­tive struc­tures might be in store for them post graduation.

Every edu­ca­tor knows what I’m talk­ing about. Every mid­dle man­ager who’s had to quan­tify or cat­e­go­rize their employ­ees’ per­for­mance knows what I mean. And while these abstrac­tions may help us facil­i­tate deci­sion mak­ing, we rarely think about their side effects on human behav­ior and the larger incen­tive struc­tures we prop­a­gate through society.

Where else do you see the abstrac­tion mis­ap­pro­pri­a­tion? And what are the con­se­quences of embed­ding these abstrac­tions in the soft­ware through­out our com­mu­ni­ca­tions and infra­struc­ture? Is all of this just a man­i­fes­ta­tion of Campbell’s law, or does this idea go beyond social plan­ning? And what is it about human cog­ni­tion that leads this phe­nom­ena, if it is as wide­spread as it seems?

In his new book Shop Class as Soul­craft, Michael Craw­ford shares a num­ber of fas­ci­nat­ing insights about the nature of work, its eco­nomic his­tory, and its role in the main­te­nance of our indi­vid­ual moral char­ac­ter. I found it a cap­ti­vat­ing read, encour­ag­ing me to think about the dis­tant forces of tenure and rep­u­ta­tion that impact my judg­ments as a teacher and researcher and to recon­sider to what extent I let them intrude upon what I know my work demands.

Buried through­out his enlight­en­ing dis­course, how­ever, is a strike at the heart of computing—and in par­tic­u­lar, automation—as a tool for human good.

His argu­ment is as follows:

“Rep­re­sent­ing states of the world in a merely for­mal way, as “infor­ma­tion” of the sort that can be coded, allows them to be entered into a log­i­cal syl­lo­gism of the sort that com­put­er­ized diag­nos­tics can solve. But this is to treat states of the world in iso­la­tion from the con­text in which their mean­ing arises, so such rep­re­sen­ta­tions are espe­cially liable to nonsense.“

This non­sense often gives machine, rather than man, the authority:

“Con­sider the angry feel­ing that bub­bles up in this per­son when, in a pub­lic bath­room, he finds him­self wav­ing his hands under the faucet, try­ing to elicit a few sec­onds of water from it in a futile rain dance of guessed-at mudras. This man would like to know: Why should there not be a han­dle? Instead he is asked to sup­pli­cate invis­i­ble pow­ers. It’s true, some peo­ple fail to turn off a man­ual faucet. With its blan­ket pre­sump­tion of irre­spon­si­bil­ity, the infrared faucet doesn’t merely respond to this fact, it installs it, giv­ing it the sta­tus of nor­malcy. There is a kind of infan­tiliza­tion at work, and it offends the spir­ited personality.“

It’s not just a lack of accu­rate con­tex­tual infor­ma­tion, how­ever, that is miss­ing from the infrared faucet, thiev­ing our con­trol to save water. Craw­ford argues that there is some­thing unique that we do as human beings that is crit­i­cal to sound judg­ment, but inim­itable in machines:

”… in the real world, prob­lems don’t present them­selves in this predi­gested way; usu­ally there is too much infor­ma­tion, and it is dif­fi­cult to know what is per­ti­nent and what isn’t. Know­ing what kind of prob­lem you have on hand means know­ing what fea­tures of the sit­u­a­tion can be ignored. Even the bound­aries of what counts as “the sit­u­a­tion” can be ambigu­ous; mak­ing dis­crim­i­na­tions of per­ti­nence can­not be achieved by the appli­ca­tion of rules, and requires the kind of judg­ment that comes with experience.“

Craw­ford goes on to assert that this human expe­ri­ence, and more specif­i­cally, human exper­tise, is some­thing that must be acquired through sit­u­ated engage­ment in work. He describes his work as a motor­cy­cle mechanic, artic­u­lat­ing the role of men­tor­ship and fail­ure in acquir­ing this sit­u­ated expe­ri­ence, and argues that “the degra­da­tion of work is often based on efforts to replace the intu­itive judg­ments of prac­ti­tion­ers with rule fol­low­ing, and cod­ify knowl­edge into abstract sys­tems of sym­bols that then stand in for sit­u­ated knowledge.”

The point I found most damn­ing was the designer’s role in all of this:

“Those who belong to a cer­tain order of society—people who make big deci­sions that affect all of us—don’t seem to have much sense of their own fal­li­bil­ity. Being unac­quainted with fail­ure, the kind that can’t be inter­preted away, may have some­thing to do with the lack of cau­tion that busi­ness and polit­i­cal lead­ers often dis­play in the actions they under­take on behalf of other people.“

Or soft­ware design­ers, per­haps. Because design­ers and pol­icy mak­ers are so far removed from the con­texts in which their deci­sions will man­i­fest, it is often impos­si­ble to know when soft­ware might fail, or even what fail­ure might mean to the idio­syn­cratic con­cerns of the indi­vid­u­als who use it.

Crawford’s claim that soft­ware degrades human agency is dif­fi­cult to con­test, and yet at odds with many core endeav­ors in HCI. As with the faucet, defi­cient mod­els of the world are often at the root of usabil­ity prob­lems and yet we per­sist in believ­ing we can rid of them with the right tools and meth­ods. Context-aware com­put­ing, as much as we try, is still in its infancy in try­ing to cre­ate sys­tems that come remotely close in mak­ing fac­sim­i­les of human judg­ments. Our efforts to bring machine learn­ing to the fold may help us rea­son about prob­lems that were before unrea­son­able, but in doing so, will we inad­ver­tently com­pel peo­ple, as Craw­ford puts it, “to be that of a cog … rather than a think­ing per­son”? Even infor­ma­tion sys­tems, with their focus on rep­re­sen­ta­tion, rather than rea­son­ing, frame and fix data in ways that we never intended (as in Facebook’s recent release of phone num­bers to mar­keters).

As HCI researchers, we also have some role to play in Crawford’s para­dox about tech­nol­ogy and consumerism:

“There seems to be an ide­ol­ogy of free­dom at the heart of con­sumerist mate­r­ial cul­ture; a promise to dis­bur­den us of men­tal and bod­ily involve­ment with our own stuff so we can pur­sue ends we have freely cho­sen. Yet this dis­bur­den­ing gives us fewer occa­sions for the expe­ri­ence of direct respon­si­bil­ity… It points to a para­dox in our expe­ri­ence of agency: to be mas­ter of your own stuff entails also being mas­tered by it.“

Are there types of soft­ware tech­nol­ogy that enhance human agency, rather than degrade it? And to what extent are we, as HCI researchers, fur­ther­ing or fight­ing this trend by try­ing to make com­put­ing more acces­si­ble, ubiq­ui­tous, and context-aware? These are moral ques­tions that we should all con­sider, as they are at the core of our community’s val­ues and our impact on society.

I just fin­ished read­ing Jonah Lehrer’s How We Decide, a fas­ci­nat­ing sur­vey of recent (and not so recent) schol­arly lit­er­a­ture on deci­sion mak­ing, behav­ioral eco­nom­ics, and neu­ro­science. The cen­tral the­sis, or per­haps, the cen­tral extract from the large body of work on the sub­ject, is that while we often think of the ratio­nal parts of our minds as cen­tral to effec­tive deci­sion mak­ing, the emo­tional parts of our minds are in fact often more objec­tive. Jonah argues, through the exten­sive overview of sev­eral hun­dreds of stud­ies span­ning eco­nom­ics, psy­chol­ogy, mar­ket­ing, and med­i­cine, that this is because our brains actu­ally take in much more infor­ma­tion that the work­ing mem­ory our ratio­nal mind depends on could ever hope to process. There­fore, when our instincts (assum­ing our instincts come from prac­ticed, expert behav­ior) are often the bet­ter informed of the two. There are obvi­ously may sub­tleties to this point (and Lehrer does a great job explain­ing them), but the bot­tom line comes down to a fairly straight­for­ward to under­stand (though dif­fi­cult to exe­cute) rubric for deci­sion making:

• If the prob­lem is novel (to you), instincts will not suf­fice. This is a job not only for the ratio­nal part of your mind, but for our cre­ativ­ity. Our instincts can often help with the sub­prob­lems of novel prob­lems, but the ratio­nal mind must inte­grate them.
• If the prob­lem is rou­tine and can be fully char­ac­ter­ized with a few well defined vari­ables (or sim­pli­fied in this way because the decision’s con­se­quence mat­ters lit­tle), let rea­son care­fully assess and ana­lyze the options.
• If the prob­lem is rou­tine, but can­not be sim­pli­fied to a few well defined vari­ables, use your ratio­nale mind to iden­tify what infor­ma­tion is and is not avail­able, but let the emo­tional part of your mind process and ana­lyze it. The instinct result­ing from this is your mind’s expert judgement.

These ideas about human deci­sion mak­ing have many fas­ci­nat­ing impli­ca­tions for soft­ware engi­neer­ing. For one, the rubric above sug­gests that soft­ware engi­neers need a keen abil­ity to know when a prob­lem is new to them, so that they may apply dif­fer­ent strate­gies to solv­ing it. I’ve seen in many of the courses I’ve taught involv­ing soft­ware engi­neer­ing deci­sions that novice engi­neers often view every prob­lem as rou­tine, where some prior solu­tion is likely to solve the new prob­lem. Rec­og­niz­ing when this is not the case is a cru­cial skill. This might involve, for exam­ple, step­ping away from a prob­lem after try­ing to apply some known solu­tions, and using the ratio­nal mind to judge whether the prob­lem has novel char­ac­ter­is­tics that deserve cre­ative solutions.

Not only should soft­ware engi­neers be able to rec­og­nize a prob­lem as novel, but they must be able to judge whether it is novel to them or novel to every­one. Novice soft­ware devel­op­ers quickly real­ize that most prob­lems they encounter have been solved already; the chal­lenge thus is not to cre­ate solu­tions, but to find exist­ing solu­tions whose assump­tions fit the prob­lem at hand. The same is true in solu­tion spaces of a smaller scope; for exam­ple, some prob­lems may be new to an indi­vid­ual, but old hat to an orga­ni­za­tion. Novice soft­ware engi­neers should know when to con­sult cowork­ers for this expertise.

Both of the above abil­i­ties prob­a­bly come with expe­ri­ence; one issue that may not, how­ever, is know­ing what you don’t know. For exam­ple, I rou­tinely see experts strug­gle with bug triage deci­sions, mak­ing quick emo­tional judge­ments about a bug report’s legit­i­macy, fix­a­bil­ity, or impact, and then ignore infor­ma­tion in the report that would dis­con­firm their judge­ment. What’s miss­ing from these deci­sions is a process by which soft­ware engi­neers use their ratio­nal mind to care­fully enu­mer­ate what infor­ma­tion they don’t have, or what infor­ma­tion is sus­pect. Fight­ing this con­fir­ma­tion bias and get­ting com­fort­able with uncer­tainty is a fun­da­men­tal part of mak­ing effec­tive deci­sions about com­plex problems.

In his dis­cus­sion of avi­a­tion, Lehrer makes an inter­est­ing point about how com­put­ers can help pilots with such biases:

The reason planes are so safe, even though both the pilot and autopilot are fallible, is that both systems are constantly working to correct each other. Mistakes are fixed before they spiral out of control.


What would bug triage look like if humans and com­put­ers col­lab­o­rated together to judge and ana­lyze infor­ma­tion about bugs? Would it help if bug reports high­lighted what infor­ma­tion was miss­ing from bug reports, such as details about the defect’s impact on users, details about who those users are, and infor­ma­tion about what com­po­nents a bug concerns?

Of course, bug triage is just one of many deci­sion mak­ing processes in soft­ware engi­neer­ing. Require­ments engi­neer­ing involves a great deal of trade­off and analy­sis and knowl­edge about human deci­sion mak­ing might improve design­ers’ con­fi­dence that what they are spec­i­fy­ing will sat­isfy user needs. Debug­ging and other types of diag­nos­tic activ­ity share the same diver­sity of novel and rou­tine prob­lems and may ben­e­fit from the same kind of metacog­ni­tive strate­gies. Bug fix­ing is also rife with choices about the scope of a change and the impli­ca­tions of a change on both users, inter­act­ing sys­tems, and other com­po­nents. In all of these, it may be of the utmost impor­tance to pro­vide novice soft­ware devel­op­ers prac­tice in rec­og­niz­ing and char­ac­ter­iz­ing the prob­lems encounter so that they may choose effec­tive strate­gies to solve them.

I was hav­ing a dis­cus­sion today with one of my Ph.D. stu­dents about exam­ples of human­i­ties style, con­cep­tual, crit­i­cal analy­sis work in the domain of soft­ware design and couldn’t think of many exam­ples. Cer­tainly there’s work in HCI con­cep­tu­al­iz­ing inter­ac­tion, infra­struc­ture, design. There’s also Michael Jackson’s Prob­lem Frames, con­cep­tu­al­iz­ing the soft­ware world, prob­lem world, and how they relate. None of these really felt like sat­is­fy­ing answers to the ques­tion, what makes code dif­fer­ent than other media? And what are the impli­ca­tions of these dif­fer­ences on society?

I’m not usu­ally one to get mired in such debates; most of my research is fairly prac­ti­cal and athe­o­ret­i­cal. But this one has always com­pelled me. I think its the ques­tion that dri­ves many of the ques­tions I ask as a scholar and much of what I teach.

One stan­dard answer to this ques­tion is that code dif­fers from other media in that it is rigid. Often­times, peo­ple describe dis­tin­guish it from the phys­i­cal world by describ­ing it as dis­crete or binary, where other media are fluid and con­tin­u­ous. The prob­lem with these char­ac­ter­i­za­tions of code is that they aren’t use­fully explana­tory or pre­dic­tive. If code is rigid, what does that say about people’s inter­ac­tions with it? That they will be sim­i­larly rigid? In what way? Peo­ple will strug­gle to do what they need to do when they need to do it because the media will not allow it? How is that dif­fer­ent from not being able to write on paper because of the mois­ture in the air? Is paper not rigid in the envi­ron­ments in which it may be used?

We have to go fur­ther. Let’s go to the source: maybe it all boils down to the pre­ci­sion of num­bers. Maybe what we mean when we say soft­ware is rigid is that it mod­els the world through num­bers, most of which fail to fully rep­re­sented what they intend, or can­not fully rep­re­sent what they intend to rep­re­sent because what they intend to rep­re­sent is not one clearly defined thing. For exam­ple, any effort to store someone’s age is inher­ently wrong because it’s a con­struct that has no pre­cisely defined start­ing point, is always being updated, and is, in many cases, deter­mined socially. That a vari­able knows your date of birth isn’t really enough, because in some sit­u­a­tions, a per­son may want to present their to oth­ers in other ways (I’m below 40). What would make this rigid, then, is that the deci­sion of how to model and com­mu­ni­cate age is a uni­ver­sal one, made by a designer, inde­pen­dent of the con­text in which the age will be com­mu­ni­cated. Any par­tic­u­lar software’s way of deal­ing with age will there­fore be inher­ently rigid because the mod­el­ing of the world and its infor­ma­tion will not be deter­mined by the indi­vid­ual sit­u­a­tion in which it is con­veyed, but long before in a uni­form way. Even attempts to have the use of infor­ma­tion react dynam­i­cally to con­text will require con­text that mod­els the world in sim­i­larly dis­crete ways, ensur­ing that there are at least some cir­cum­stances in which the adap­tive tech­niques will not have enough infor­ma­tion to make the choice a human would have made.

But it’s not just num­bers. Another fun­da­men­tal part of the medium of code is branch­ing, a dichoto­mous form of deci­sion mak­ing that only leaves room for final­ity. The machine needs to know, unam­bigu­ously, what it should do next, because delay is the utmost fail­ure. How does branch­ing make machines rigid? In one sense, its not the branch­ing itself that leads to rigid­ity, but the inabil­ity of pro­grams to eas­ily change their deci­sions. When a per­son begins to walk down a path and real­izes its the wrong direc­tion, the per­son can change their mind, turn around, and walk down a dif­fer­ent path. When a pro­gram fol­lows a branch, mod­i­fy­ing this deci­sion and return­ing to a pre­vi­ous state is no sim­ple mat­ter. The designer must have antic­i­pated this need to return to a state and archi­tect the soft­ware in a man­ner that facil­i­tates this rever­sal. Just like with num­bers, it is the machine’s mod­el­ing of the state of the world, and its ori­en­ta­tion toward reach­ing future states, rather than prior states, that makes soft­ware rigid.

Other media are rigid in sim­i­lar ways. When you put pen to paper, the medium does lit­tle to allow you to return to prior states. In this case, software-based sketch­ing tools are far more flex­i­ble. But per­haps this is apples and oranges, since the paper hasn’t made a deci­sion, it’s the per­son that’s made a deci­sion. The same is true for some mechan­i­cal media. If you dent a piece of alu­minum, it’s non-trivial to get it to return to its prior state.

Both of these exam­ples con­flate the designer express­ing some­thing in the media and the per­son using the expressed thing. With soft­ware, it is the con­sumer that feels the rigid­ity of the medium; the pro­ducer of soft­ware expe­ri­ences rigid­ity in con­form­ing to syn­tac­tic and seman­tic rules. Where each of these par­ties expe­ri­ences rigid­ity has more to do with whether the pro­gram is being writ­ten or used.

Per­haps then there is some mean­ing­ful dis­tinc­tion between the medium of code and the medium of exe­cu­tion. To this point, I have largely been dis­cussing the rigid­ity of pro­gram exe­cu­tion and its rela­tion­ship to branch­ing and num­bers, over­look­ing the rigid­ity in the expres­sion of code. I sup­pose that the rigid­ity in the expres­sion of code may have some role in bias­ing soft­ware devel­op­ers into cre­at­ing pro­gram exe­cu­tions that are also rigid. For exam­ple, because it is dif­fi­cult to teach a pro­gram to make some state changes reversible, the result­ing exe­cu­tion of soft­ware is rigid in its abil­ity to return to prior states.

Obvi­ously there’s much more think­ing to do here. What are the impli­ca­tions of these con­cep­tu­al­iza­tions, as they are now? If one chooses soft­ware over some other media for facil­i­tat­ing infor­ma­tion trans­fer, one should expect that the way the soft­ware mod­els the world, and the biases and over­sights inher­ent to that model, will leak through to people’s expe­ri­ences, bias­ing and restrict­ing people’s use of the soft­ware to con­form to its model of the world. Peo­ple will rec­og­nize these biases and go to great efforts to workaround them, to over­come them, and to have them changed. No model will be per­fect because many things that are mod­eled are not well defined or must change to fit the sit­u­a­tion, and there­fore these reac­tions to soft­ware are inevitable. A sci­ence that allows soft­ware devel­op­ers to ana­lyze the lim­i­ta­tions of the mod­els inher­ent in a par­tic­u­lar pro­gram and pre­dict the reac­tions to its lim­i­ta­tions would help soft­ware teams and soci­ety bet­ter antic­i­pate software’s lim­ited abil­ity to facil­i­tate and sup­port human activity.

Accord­ing to my Omni­Fo­cus data­base, I have 1,272 active to do items span­ning 197 projects and 93 zip files. Their due dates range from tomor­row to retire­ment. Every day, I open Omni­Fo­cus and it tells me what to do today, so I don’t have to worry about tomor­row. And yet, I have this nag­ging feel­ing of dis­so­ci­a­tion from the present. I think past me plan­ning for future me has left present me with noth­ing to do.

Case in point: last Fri­day was a mis­cel­la­neous day, where I take all of those to dos that I pushed off from the past cou­ple of weeks and got them done. I had a nice tidy list of 17 of of them, each with care­fully cho­sen dead­lines and terse, but effec­tive notes remind­ing me what I was doing when I last worked on it, why it was impor­tant, and what was left to fin­ish. I spent the day fir­ing off e-mails, edit­ing stale para­graphs in paper sub­mis­sions, sub­mit­ting travel forms, plan­ning grant spend­ing, set­ting up Trac for my class in the fall. Yet by the end of the day, I wasn’t really sure what I’d accom­plished. When the girl­friend asked me about the high­lights of my day, I was at a com­plete loss. What had I done? Was any of it fun? Was it frus­trat­ing? Were there any mem­o­rable moments at all? At least to my con­scious self, it felt like I’d really only done one thing that day: clear my to do list. The rest was a blur. Past me had present me so pre­pared to mech­a­nis­ti­cally work through those 17 items, I hadn’t even formed mem­o­ries of the work I’d done or the emo­tions I felt. I was a to do bot whose sole mis­sion was plac­ing check­marks on a vir­tual list, all in ser­vice of future me’s ever grow­ing workload.

Now that I reflect on this, I think what’s going on is that I’ve sep­a­rated all of the think­ing and decid­ing about what I should be doing now from the now itself. At least at work, I rarely find a moment where decid­ing what to do and actu­ally doing it co-occur in any mean­ing­ful way. This is never clearer than on the week­ends, where I try to let present me make the deci­sions, instead of past me. Past me had noth­ing to say about brunch this morn­ing, he didn’t give me a list of chores. It was present me who got to play with my 16 wak­ing hours and decide how to break them down, how to fill them, and when the day was done. And being so involved in decid­ing about today has led to so many won­der­ful mem­o­ries: the arugula hol­landaise risotto bene­dict, the peach dutch baby pan­cakes, writ­ing this blog post at Uptown Espresso in the Bell­town sun­shine with my girl­friend. Aren’t these the kind of mem­o­ries and expe­ri­ences that life is about?

I sup­pose it’s a trade­off, like any­thing else. What’s more impor­tant at work, get­ting things done or remem­ber­ing get­ting things done? I like my job, or at least I like the idea of it, but lately my obses­sion with effi­ciency is trans­form­ing work that used to be so sat­is­fy­ing into a hazy blur of typ­ing and talk­ing. To com­bat this, maybe I’ll try insert­ing lit­tle moments of reflec­tion into my day, where I sit and reflect for 5 min­utes and maybe write a bit, just to crys­tal­lize the con­crete in my mind. In fact, I’ll add it to my to do list right now!

It’s been an inter­est­ing week­end. My post on cul­tural homo­gene­ity at the Mozilla Sum­mit ruf­fled some feath­ers and led to a flurry of fas­ci­nat­ing responses on red­dit. I’ve replied to many of the com­menters who work at Mozilla, try­ing to under­stand the anger, con­fu­sion, and dis­be­lief in their state­ments, with the fol­low­ing gist: I love Mozilla, Mozilla’s great, but there are a lot of peo­ple in the com­mu­nity who are elit­ist and con­de­scend­ing towards any­one with­out cod­ing chops. I still stand by that obser­va­tion, no mat­ter how hard it is to hear.

One of the inter­est­ing points of con­tention in the dis­cus­sion was the claim I made about the trade­offs between open­ness and sim­plic­ity. There was a lot of push back on that one; most of the com­menters believed that the two were much more com­pat­i­ble than I sug­gested. How­ever, rather than try to defend it, I think it would be much more inter­est­ing to point out sev­eral other trade­offs between soft­ware qual­i­ties that I’ve observed, to stir the pot a bit more:

• secu­rity and sim­plic­ity. Almost by def­i­n­i­tion, it’s dif­fi­cult to design some­thing that is both impen­e­tra­ble and acces­si­ble. This is obvi­ously a gross over­sim­pli­fi­ca­tion, but eas­ily demon­strated by the con­cept of a pass­word. What’s sim­pler, going to gmail.com and read­ing your mail or going to gmail.com, enter­ing your pass­word, and open­ing your mail? The two trade­off with one another in a vari­ety of ways.
• per­for­mance and com­pre­hen­si­bil­ity. The Knuthian apho­rism, “pre­ma­ture opti­miza­tion is the root of all evil” comes to mind. By design­ing sys­tems that are time and space effi­cient, we often make sys­tems’ designs more dif­fi­cult to under­stand (and I’d argue, more buggy).
• pri­vacy and par­si­mony. The most fru­gal and spar­ing of solu­tions, often described by devel­op­ers as the most ele­gant and beau­ti­ful of solu­tions, are often in direct oppo­si­tion to each other. Take Facebook’s pri­vacy set­ting schemas; the most spar­ing of schemas are often wholly inad­e­quate for express­ing the com­plex­ity of indi­vid­u­als’ expec­ta­tions about who has access to what.
• con­fig­ura­bil­ity and learn­abil­ity. One way to think of learn­abil­ity is as the dif­fi­culty of learn­ing the map­ping between a system’s inputs and out­puts. The more inputs you expose, the more map­pings to learn.

Of course, these are very weakly defined: it could take decades of writ­ing, thought and expe­ri­ence for to really under­stand the nature of these trade­offs and whether they actu­ally exist. I raise them because I think each rep­re­sents an oppo­si­tion between two val­ues, and that blind devo­tion to one over another often leads to prob­lems. Con­sider secu­rity, for exam­ple. We have whole com­mu­ni­ties of researchers and prac­ti­tion­ers who amass a great deal of exper­tise in secur­ing sys­tems. Many of them are my friends. But what I often find is that secu­rity is often treated by devel­op­ers and ana­lysts in these com­mu­ni­ties as a cause, per­haps even an ide­ol­ogy, rather than just one of many pos­si­ble soft­ware qual­i­ties. Case in point: I deployed an inter­nal pro­to­type last win­ter and had sev­eral stu­dents use the pro­to­type while I gath­ered usage infor­ma­tion. After an hour, my data­base was full of lots of fas­ci­nat­ing data which would help pro­pel my research on the pro­to­type for­ward. How­ever, one enter­pris­ing user decided that rather than use the pro­to­type, he would test it for secu­rity flaws. He even­tu­ally found a poten­tial SQL injec­tion attack and decided to test it by drop­ping my tables— so much for my data. Rather than writ­ing and apol­o­giz­ing for destroy­ing my data­base, he wrote proudly, declar­ing that he’d found a vul­ner­a­bil­ity in my code and he’d be happy to help me look for oth­ers. Of course, secu­rity was the last thing on my mind, and his single-minded pur­pose toward espous­ing secure soft­ware sys­tems had led to actual dam­age to my research.

Now I’m not say­ing that secu­rity doesn’t mat­ter. My claim is that what mat­ters depends on the sit­u­a­tion. I did care about secu­rity in the story above, but not as much as I cared about get­ting the data and sav­ing time. Given lim­ited resources, this all devel­op­ers have to make tough choices between com­pet­ing val­ues. What I find prob­lem­atic about many of today’s devel­oper cul­tures is the belief that any one soft­ware qual­ity mat­ters more than another in all sit­u­a­tions. It’s been true for per­for­mance in the aca­d­e­mic com­puter sci­ence research com­mu­nity; it’s been true for par­si­mony and ele­gance; it’s increas­ingly true for secu­rity, pri­vacy, and yes, even usabil­ity. The world isn’t that sim­ple, and any belief that one value ought to always take prece­dent over another does a dis­ser­vice to the users who oper­ate in sit­u­a­tions with dif­fer­ent priorities.

I’m cer­tainly not claim­ing that all devel­op­ers believe this. If there’s any­thing I’ve observed amongst all of the devel­op­ers I know, its that the more expe­ri­ence they’ve gained, the more they real­ize just how dif­fi­cult it is to clar­ify the pri­or­i­ties for a project in a way that is acted upon con­sis­tently across a team and over time. In all of the research that I’ve done study­ing devel­oper dis­cus­sions around design deci­sions, this seems to be the cen­tral strug­gle: how do you clearly com­mu­ni­cate to every­one involved how var­i­ous soft­ware qual­i­ties rank with one another? This is espe­cially dif­fi­cult when we don’t even have def­i­n­i­tions of these qual­i­ties that peo­ple agree upon, let alone an under­stand­ing for how they interact.

If there was any point to my ram­bling about the Mozilla cul­ture, it was that more devel­op­ers need more knowl­edge about the dif­fer­ing pri­or­i­ties of their users and how this dif­fer­ing pri­or­i­ties inter­act with Mozilla’s goal of espous­ing open­ness. I wish that as a researcher I had more to offer on this sub­ject, but alas, I have not. At least for now.

men, men, men

One thing that’s always inter­ested me about soft­ware design is the inescapable bias of the designer. Whether we like it or not, design­ers’ per­spec­tives always color what they think makes sense, what they think is use­ful, and what they think is good.

Never has this been more appar­ent to me than at the 2010 Mozilla Sum­mit. I couldn’t help but notice that every ses­sion I vis­ited, every recep­tion I attended, and every con­ver­sa­tion I had was dom­i­nated by male hacker stereo­types. The game room was full of obscure board games, first per­son shoot­ers, caf­feine and candy. Group con­ver­sa­tions inevitably drifted towards the finer details of an API or a tech­ni­cal dis­cus­sion of the mer­its of one plat­form or another. I had many short-lived and terse con­ver­sa­tions with shy and intro­verted but incred­i­bly proud geeks like myself.

It’s not that there’s any­thing wrong with the typ­i­cal Mozillian—it’s that Mozil­lians are such a sur­pris­ingly typ­i­cal group. It didn’t mat­ter what coun­try I came from, whether I was speak­ing to a man or a woman, or whether the con­trib­u­tor was a devel­oper, tester, local­izer or other form of con­trib­u­tor, there was a some­what shock­ing homo­gene­ity to the per­son­al­i­ties and value sys­tems of the peo­ple I met.

And it’s not even that these per­son­al­i­ties or value sys­tems are wrong: in fact, I share many traits and val­ues with the peo­ple I met. I’m shy; I’m intro­verted; I believe in stan­dards, open com­mu­ni­ca­tion, trans­parency. As an aca­d­e­mic, I may have learned to over­come these traits for the ben­e­fit of my career and to fos­ter other val­ues, but at my core, I iden­tify strongly with Mozil­lians in both per­son­al­ity and beliefs.

No, the trou­bling thing was the lack of oppos­ing traits and beliefs. Where are the tech­ni­cally dis­in­ter­ested Mozil­lians? The gre­gar­i­ous? The empathiz­ing? Where are the Mozil­lians who are inter­ested in peo­ple, soci­ety, his­tory, diversity?

The answer, of course, is prob­a­bly quite obvi­ous: they’re Mozil­lians because they’re inter­ested in tech­nol­ogy. The ones inter­ested in peo­ple have self-selected out of this group and are con­tribut­ing to soci­ety in other ways and other places.

What this means, how­ever, is that a com­pa­ra­bly small group of peo­ple with sim­i­lar goals, sim­i­lar inter­ests, sim­i­lar view­points, and sim­i­lar skills have a dis­pro­por­tion­ate influ­ence on how the rest of the world expe­ri­ences the web. And unsur­pris­ingly, the expe­ri­ences that Mozil­lians cre­ate are the ones that prop­a­gate and rein­force Mozil­lians’ own viewpoints.

None of this is very con­tro­ver­sial either. In fact, I spoke with many Mozilla employ­ees who believe that Fire­fox and Mozilla’s other mature prod­ucts are really prod­ucts for power users, despite the orga­ni­za­tions unique user-facing stance rel­a­tive to other open source com­mu­ni­ties. They believed that while it may be pos­si­ble for the rest of the world to use Fire­fox as an alter­na­tive to other browsers, the Mozilla com­mu­nity ulti­mately builds for itself and its own per­spec­tives because it knows no other way.

What is this way, then, that Mozil­lians view the world? Through­out my many dis­cus­sions, I noticed a num­ber of recur­ring beliefs (many of which are gen­eral to engi­neers and devel­op­ers, and not just open source communities):

• There’s always a right answer. Unlike most pro­fes­sional design­ers, I noticed that devel­op­ers like to use the word “right” a lot when design­ing solu­tions. Under­stand­ings of trade­offs seem to be limited.
• My answer is right. Most of the Mozil­lians I met like to believe they have the right answer. There appears to be a joy on defend­ing this posi­tion as well.
• If a ratio­nale argu­ment can’t be made for a solu­tion, the solu­tion is invalid. Ratio­nal thought is the only valid means of obtain­ing knowl­edge or solv­ing a problem.
• Proof by exis­tence, not by evi­dence. Pro­to­type it and then I’ll believe you.
• Ambi­gu­ity is unac­cept­able. Messy or noisy prob­lems need not be solved. Solve the solv­able problems.

Another recur­ring stance I noticed was that devel­op­ers are spe­cial, priv­i­leged class. Obvi­ously this isn’t the first time I’ve see this, but it did make me won­der where it comes from. So I probed. What I found was that every story of how some­one learned to pro­gram and become part of the com­mu­nity was one of com­pet­i­tive selec­tion. It’s hard to learn to pro­gram, it’s hard to get into CS, it’s hard to get a devel­op­ment job, and it’s hard to become a Mozilla devel­oper. In fact, many told me that with all of these tri­als by fire, they learned quickly to act con­fi­dent, to act cer­tain, and to act as if one is right. One devel­oper described this as a form of elit­ism, which brings with it a dis­dain for other view points and other more eas­ily acquired skill sets (hence the appar­ent lesser sta­tus of local­iz­ers, testers, and support).

What no one said, but what I gleaned, is that this cul­ture of elit­ism is as much an iden­tity thing as it is a social thing. Per­haps the com­pet­i­tive processes by which devel­op­ers attain sta­tus cre­ates an iden­tity that must be fed by being right. And what do we know about iden­ti­ties? Peo­ple rein­force them, they defend them and they seek expe­ri­ences that keep them intact.

What is the impact of all of these on the design of soft­ware, or at least Mozilla soft­ware? For one, design cul­ture itself appears in direct con­flict with how devel­op­ers view the world. There is often an ambi­gu­ity, or mys­ti­cism to how design­ers learn to cope with ambi­gu­ity, and at least with respect to devel­op­ers, I can see how this ambi­gu­ity is dis­con­cert­ing and uncon­vinc­ing. More­over, it dis­em­pow­ers con­cep­tual design­ers by requir­ing func­tion­ing pro­to­types as a ticket to entry.

The par­tic­u­lar mis­sion of Mozilla, to sup­port the open web, also has inter­est­ing inter­ac­tions with this devel­oper cul­ture. For exam­ple, many devel­op­ers I spoke to believe that the pub­lic ought to care about their abil­ity to con­trol their online expe­ri­ence and own their data. I asked them, as devil’s advo­cate, why Mozillian’s had the right to impose these val­ues through soft­ware, and many made a free mar­ket argu­ment: peo­ple group together to espouse their val­ues and those groups that per­suade best, win. I saw lit­tle room in most stances for the pos­si­bil­ity that users might not value the free­dom espoused by Mozilla, and that the very espous­ing of open­ness might in fact oppose other val­ues, such as sim­plic­ity, human­ity, and beauty.

Are these trends in devel­oper cul­ture inescapable, or just an ephemeral aspect of a rel­a­tively young trade? Is it pos­si­ble that as more peo­ple with more diverse per­spec­tives learn to code, this imbal­ance in per­spec­tive will cor­rect itself? Or are there only cer­tain types of peo­ple drawn to code? Per­haps the mar­ket will ulti­mately force devel­op­ers to empathize with other view­points, because soci­ety will cease to tol­er­ate the engi­neered design of today and demand designs that respect their own val­ues. I do not know—but I’ll be inter­ested to find out!