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!

I was hop­ing, des­per­ately hop­ing that Keynote for the iPad would become my ded­i­cated pre­sen­ta­tion and teach­ing device. Imag­ine it: high­light­ing, cir­cling, pre­sen­ter notes, and all of the media I could want in a seam­less expe­ri­ence, all pumped out of the video out cable to a project.

Unfor­tu­nately, it’s nowhere near that expe­ri­ence yet. It turns out that video out is han­dled in very app spe­cific ways. Keynote, for exam­ple, projects the slides onto the sec­ondary dis­play and sim­ply shows which slide num­ber your on. That’s right: you can’t see your slides while your present. If you want to see what you’re pre­sent­ing, you’ll need to look behind you.

But it’s worse than that. Let’s say I want to show a YouTube video; when I leave Keynote, the dis­play stops sig­nal­ing alto­gether. So rather than an ele­gant black screen, or mir­ror­ing the iPad dis­play, you get your projector’s big ugly blue no sig­nal screen. The expe­ri­ence is quite bro­ken. Any app that doesn’t explic­itly sup­port video out sim­ply doesn’t pro­vide a sig­nal. I can’t project any­thing on the web, for exam­ple, or sketch in front of students.

Luck­ily, most of these are soft­ware lim­i­ta­tions. I hope that the lack of mir­ror­ing isn’t a hard­ware lim­i­ta­tion. Does Apple know these things? Is it rec­ti­fy­ing these issues? Who knows. They’re not known for their trans­parency. Maybe I’ll find out that every­thing is fixed with iPhone OS 4.0…

After 4 hours of con­tin­u­ous use, I can con­fi­dently say that the iPad rocks in many ways, and fails in only a few. It’s a genius way to browse the web, to write short emails, to lis­ten to music, to watch short videos, to use Face­book and Twit­ter, to give sim­ple pre­sen­ta­tions, to read news, and to show pho­tos. Theres lit­er­ally no bet­ter expe­ri­ence out there for most of these activ­i­ties. It’s also a great sketch­pad — not as great as a real sketch­pad, mind you, but oh so much eas­ier to share and archive.

It fails in the obvi­ous places. The onscreen key­board is bear­able. I can tye a lot faster than on my iPhone or any cell phone, but I’m not get­ting my typ­i­cal 80 wpm. A wire­less key­board would make up for a lot of these lim­i­ta­tions, but it sort of defeats the pur­pose of car­ry­ing some­thing slim and light­weight. I’ve typed a lot on is in the past few hours and I feel a bit held back, but not so much that I don’t feel productive.

There are still some ways where mul­ti­touch is inher­ently lim­ited. One out of every 10 times I tap or drag, it doesn’t do what I want. This is no dif­fer­ent than on the iPhone, but I’ve noticed myself accli­mate to the inac­cu­racy. The device hasn’t got­ten any smarter, I’ve just got­ten more tolerant.

The iPhone UI toolkit still breaks many per­va­sive web con­ven­tions. For exam­ple, I’m typ­ing this in a text field in a Word­Press page, and scrolling up to edit the pre­vi­ous para­graphs is incred­i­bly slow, even with the two fin­gered scroll inter­ac­tion, com­pared to a scroll wheel.

But I already love this thing. For all of the activ­i­ties I men­tioned ear­lier, the iPad is the clear win­ner. It’ll sit next to me at my desk and be a con­stant source of dis­trac­tion dur­ing work. I’m think­ing it’ll be a ded­i­cated cal­en­dar while I use my lap­top. Time to start explor­ing what else this form excels at! Like mul­ti­touch visual pro­gram­ming, hint hint…

Back in Novem­ber, I got my first water, sewage, and gas bill from a com­pany called ISTA. My apart­ment man­age­ment had taken a while to set up the billing after the pre­vi­ous billing com­pany went of busi­ness (or dropped the con­tract, I don’t remem­ber exactly what hap­pened). So I hadn’t actu­ally paid water and sewage for two or three months.

So when the bill came for $173, I wasn’t too sur­prised. I didn’t really remem­ber what I’d paid the pre­vi­ous year, but this seemed rea­son­able for a few months of water, sewage and gas. I wrote the check, and for­got about ISTA.

Forty five days later, I got the next bill, but this time some­thing seemed wrong: $463 and it had only been a month and a half. What the hell was going on? I looked back on my old bills and noticed that my aver­age 30 day bill was about $30, even in the win­ter. Either the com­pany was try­ing to extort money from me or some­body had made an account­ing error.

I looked more closely at the bill, which had three columns: pre­vi­ous usage, cur­rent usage, and usage. The dif­fer­ence between the first two columns was exactly 1000. The value in the third col­umn was 10,000. Was there some hid­den mul­ti­plier I didn’t under­stand? Maybe there was some rate that just hap­pened to be 10, and I had just kept my apart­ment and show­ers really warm this winter.

So I called ISTA and dis­puted the bill. They imme­di­ately esca­lated it to their dis­pute man­ager, who called me back after a few days. They said that there had been a mis­read meter and that they had cor­rected the read­ing, and that after the bill was now only about $270, after they had applied the credit. When I got the call, I had a meet­ing to be at, so I didn’t think about it much.

After I got home that night, it still didn’t seem right. $270 for 45 days? What hap­pened to the rates? They must have gone up by a fac­tor of 10! So the next day, I called ISTA back, and spoke to a nice lady about my prob­lem. Rather than call the dis­pute man­ager again, she told me she was open­ing my spread­sheet. She pro­ceeded to walk through the cal­cu­la­tions with me, describ­ing the rates and the for­mu­las. I jot­ted them down on paper as we went. Finally, we got to the final total cal­cu­la­tion, and she said, “so this times the mul­ti­plier is … wait, it shouldn’t be.” She imme­di­ately put me on hold.

A few min­utes later, she came back, say­ing that she needed to have the account­ing depart­ment look at my spread­sheet. My spread­sheet, imply­ing that every cus­tomer has their own. She said that the dis­pute man­ager would, yet again, call me back in a few days.

Four days later, the dis­pute man­ager called me back and explained that there was some sort of dis­agree­ment between billing and account­ing, regard­ing the cause of the prob­lem. Billing thought it was the spread­sheet and account­ing thought it was the meter read­ings. She said she’d call back in a few more busi­ness days, after they’d worked out their differences.

When she did call back, she lev­eled with me: account­ing was wrong, there was an error in the spread­sheet, and after fix­ing the mul­ti­plier cell, my bill was reduced by a fac­tor of 10. After the credit cal­cu­la­tors, they deter­mined that I had over­paid from the pre­vi­ous bill by about $100, and that I prob­a­bly wouldn’t have a bill for the next two cycles. She apol­o­gized for how long it took to resolve the issue, but reas­sured me that it wouldn’t hap­pen to me again.

But I wasn’t think­ing about me at this point. I was think­ing about all of the other cus­tomers, whose spread­sheets prob­a­bly had the same error. Would the accoun­tants audit all of the spread­sheets that copied the error? How many cus­tomers would call about the bills? How many would insist, like I did, that there was a spread­sheet error, and demand that it be prop­erly diag­nosed? And how much of this feed­back would ever make it to the accoun­tants writ­ing the buggy spreadsheets?

Oh, end-user pro­gram­ming. Your man­i­fes­ta­tions in soci­ety abound.

Yeah, I’m a lit­tle late to the dis­cus­sion. But as I’ve con­tem­plated over past weeks the mer­its of the iPads form and func­tion, try­ing to imag­ine what I’d do with it and what oth­ers might do with it, I keep com­ing back to the same prob­lem: the iPad, nor the iPod or iPhone, sup­port jux­ta­po­si­tion. That’s what all of this whin­ing about mul­ti­task­ing is about. So many things we do on com­put­ers is com­pare, con­trast, and cross-reference between appli­ca­tions, and yet that’s one of the major things the iPad can­not do.

I wish copy and paste were enough, but it’s not. It’s about writ­ing an email about the news arti­cle you have open, or quickly check­ing the sta­tus on some build, or read­ing a dic­tio­nary def­i­n­i­tion online while you’re writ­ing. You can’t do these things on single-task UIs, because the cost of leav­ing one app, open­ing another, and then return­ing to an app is at least 30 sec­onds. That, and every­thing you might want to jux­ta­pose against has to be kept in your head for these 30 sec­onds. Good luck with that when you’re try­ing to think.

So maybe Apple decided the device wasn’t for think­ing or cre­at­ing. Maybe it’s just for con­sum­ing. But even con­sump­tion takes jux­ta­po­si­tion. I find myself on my iPhone all the time, want­ing to read a Yelp review and see where a place is on the map at the same time.  Because this isn’t pos­si­ble, the Yelp app tries to do maps well, and the Maps app will prob­a­bly try to incor­po­rate reviews, lead­ing to sub­stan­dard expe­ri­ences in both apps. Or, another exam­ple was when I was doing my taxes online: I was ref­er­enc­ing advice in forums about teacher deduc­tions (which I found out I can’t take), while try­ing to decide how to answer a Tur­b­o­Tax ques­tion. On the iPad, I’d have to go back and forth between the two, mem­o­riz­ing all the num­bers and excep­tions in the forum post in order to act upon them in the tax software.

Peo­ple are going to real­ize this soon, too, and Apple’s going to suf­fer for it. Either Apple is just wait­ing for the right time to sup­port jux­ta­po­si­tion, or their design­ers just have no idea how peo­ple pro­duce and con­sume information.

I’m no fan of time. It is a relent­less, immov­able force, destroy­ing plans, induc­ing stress, and bring­ing unpre­dictable change to our del­i­cate expec­ta­tions of con­sis­tency. But I’m slowly real­iz­ing that of all of my schol­arly respon­si­bil­i­ties, time is the one con­stant, the ever present sub­ject. Teach­ing is design­ing pace and order of con­tent. Research is pre­dict­ing and invent­ing the future based on all that has passed. And doing both of these well requires me to care­fully sequence my thought and actions to best lever­age what lit­tle time I have. To man­age my time.

I don’t feel like an expert at this. But peo­ple often com­ment on my abil­ity to man­age time well, and I’m always struck at people’s inabil­ity to under­stand where their time goes. What am I see­ing that oth­ers can’t? What am I doing to con­trol time?

After think­ing about it a bit, I think it boils down to three basic skills. First, I’ve always been able to pri­or­i­tize. That might sound sim­ple, but it’s an astound­ing act to take the thou­sands of things one cares about and rank them. This is because there’s noth­ing inher­ently ordered about the things one cares about. The laun­dry isn’t inher­ently less impor­tant than writ­ing a lec­ture if all my clothes are soiled. Know­ing how to pri­or­i­tize and con­stantly repri­or­i­tize as sit­u­a­tions change needs to be a con­scious, explicit act, if one hopes to influ­ence the future. Oth­er­wise, the for­ward thrust of time will always dom­i­nate and dic­tate what’s important.

But know­ing what’s impor­tant isn’t enough. Being able to artic­u­late what’s impor­tant, and define what that means, is impor­tant as well. For instance, my aller­gies have been both­er­ing me a lot lately and I’ve wanted them to bother me less. But there are a lot of ways to artic­u­late that goal, some more use­ful and action­able than oth­ers. For exam­ple, when I say, “bother me less,” I have to be very care­ful to know what I mean by “bother” and “less.” Do I want to get off allergy pills? Do I want to buy less facial tis­sue? Do I want fewer sinus headaches? These are all dif­fer­ent goals and I might do dif­fer­ent things to accom­plish each. They also might improve my life in dif­fer­ent ways. It’s not until I start giv­ing mean­ing to verbs and adjec­tives in my goals that I can start to eval­u­ate what’s really impor­tant to me.

Finally, a clearly artic­u­lated goal isn’t enough to accom­plish it. A third skill is being able to take a well artic­u­lated goal and care­fully break it down into smaller goals. For exam­ple, if I decide I want fewer sinus headaches, I need to find out what causes sinus headaches and see what causes I have con­trol over in my life. This might lead to sev­eral new activ­i­ties and goals, such as drink­ing more flu­ids. How can I drink more flu­ids? Maybe I need a water bot­tle. What’s a good water bot­tle? And so on. With­out break­ing down the future into man­age­able parts, it would be quite dif­fi­cult to find a moment where progress seems action­able. Big goals only lead us to imag­ine big, unwieldy futures. A good small goal is some­thing you can imag­ine get­ting done in an hour.

So how does one get good at these things? Prac­tice is prob­a­bly the best approach. Hav­ing accom­plished a goal before makes it a lot eas­ier to know how to break down the goal into smaller goals, with con­fi­dence. It also gives one prac­tice at artic­u­lat­ing goals. Another trick I like to use is to write to do items about to do items, such as “break down the goal of reduc­ing sinus headaches”. That way, the first and most impor­tant step of accom­plish the goal becomes a legit­i­mate step in a process, and some­thing that I can accom­plish in 20 minutes.

Tools can help with all of this, but most are just glo­ri­fied lists. Most of the impor­tant parts of man­ag­ing time come with discipline.

Here is part two of Emer­son Murphy-Hill’s inter­view with me. This part cov­ers some of the chal­lenges in pub­lish­ing in HCI venues.

Q: A promi­nent pro­po­nent of empir­i­cal soft­ware engi­neer­ing once told me that that he typ­i­cally spends a full page dis­cussing the threats to valid­ity of his eval­u­a­tions. At the same time, it’s not unusual to find a CHI paper that doesn’t dis­cuss threats. How does one choose which threats to include and exclude, and how to present those threats, to the CHI community?

Most CHI papers clearly dis­cuss threats, just not in a sec­tion titled “threats to valid­ity.” This tra­di­tion comes from CHI’s cog­ni­tive psy­chol­ogy research, where the threats were inher­ent to the study design and dis­cussed through­out the method and dis­cus­sion sec­tions. There never needed to be a sep­a­rate sec­tion because it was expected that dis­cus­sion of the lim­i­ta­tions would appear through­out the arti­cle. As a guide­line, one should always dis­cuss all non-obvious threats to valid­ity. Its a nec­es­sary part of hon­est schol­arly work.

Q: Where do you draw the line about whether a threat is obvious?

Some threats are com­mon to all empir­i­cal research: the sam­ple size was to too small, the study may not gen­er­al­ize, sit­u­a­tions may not have been rep­re­sen­ta­tive. These are stan­dard dis­claimers and its always worth men­tion­ing them briefly. The ones to really spend time on are the def­i­n­i­tions and mea­sures one uses and what like­li­hood they have at actu­ally cap­tur­ing the con­cept of inter­est (the con­struct valid­ity) and whether they have any mean­ing for the real world (eco­log­i­cal validity).

Q: Have you had an HCI reviewer sug­gest that your work is bet­ter suited for a soft­ware engi­neer­ing venue, or vice versa? If so, how did you deal with the sug­ges­tion? If not, how do you think you pre­empted it in the first place?

No, I’ve never had a reviewer sug­gest that. Of course, the work that I pub­lish at HCI venues usu­ally has more to do with the actual work of soft­ware engi­neers, their col­lab­o­ra­tions, or their inter­ac­tions with users, as opposed to con­ven­tional soft­ware engi­neer­ing research on automa­tion. I think one of the main stum­bling blocks that soft­ware engi­neer­ing researchers will have try­ing to pub­lish at HCI venues is demon­strat­ing that the prob­lems they work on are of sig­nif­i­cance. For exam­ple, a com­mon type of soft­ware engi­neer­ing paper will find some spe­cific set of cir­cum­stances that can be exploited to auto­mate bug find­ing or prove cor­rect­ness within a cer­tain set of assump­tions. In gen­eral, HCI researchers aren’t inter­ested in these types nar­row con­tri­bu­tions, unless there’s some good evi­dence that the set of cir­cum­stances exploited is large and gen­er­al­iz­able to some degree.

Q: In an HCI paper, where do you make the argu­ment about gen­er­al­iz­abil­ity? Is there room for speculation?

Andrew: There’s always room for spec­u­la­tion. That’s what dis­cus­sion and lim­i­ta­tion sec­tions are for. The whole point of stud­ies is to use a ker­nel of rig­or­ous and trusted analy­sis in order to make pre­dic­tions about the larger con­text of the world. In fact, I think too many soft­ware engi­neer­ing papers sim­ply report results and ignore what impact a tool design or study might have on our under­stand­ing of soft­ware engi­neer­ing. Tools, after all, are embod­i­ments of the­o­ries about the world, and they have just as much poten­tial to teach us about our sur­round­ings as stud­ies – per­haps more.

Q: As a reviewer for HCI venues, what is the most com­mon mis­take that you see soft­ware researchers making?

Being more fas­ci­nated with tech­nol­ogy itself than what tech­nol­ogy does for peo­ple (whether those peo­ple are tech­nol­ogy users or hard­core soft­ware devel­op­ers). More often than not, I will read soft­ware engi­neer­ing papers pub­lished at HCI venues that try hard to per­suade me that the clever tricks they devised are inter­est­ing enough to over­come the min­i­mal impact the tricks will have on users’ work and expe­ri­ence with a tool.

I also see soft­ware engi­neer­ing researchers try to make knowl­edge con­tri­bu­tions about soft­ware devel­op­ment prac­tice with­out cit­ing the large body of work done at CSCW and other con­fer­ences about group work. HCI researchers tend to view soft­ware devel­op­ment as just one of many exam­ples of col­lab­o­ra­tive work. The argu­ment that its spe­cial and unique usu­ally doesn’t fly with­out evidence.

Q: Although HCI sub­mis­sions are often anony­mous, peo­ple tend to be sus­pi­cious of “out­siders,” and may treat out­siders’ work with some undue hos­til­ity. What can a soft­ware researcher do to avoid iden­ti­fy­ing him­self as an out­sider in the HCI community?

All HCI researchers are out­siders. There’s not enough of a con­cen­tra­tion on any one topic or prob­lem for there to be a com­mon core. The best thing to avoid sound­ing naive is to read as much about a topic out­side of your dis­ci­pline as pos­si­ble. HCI draws from cog­ni­tive sci­ence, psy­chol­ogy, design, com­puter sci­ence, engi­neer­ing, anthro­pol­ogy, social psy­chol­ogy, com­mu­ni­ca­tion, edu­ca­tion, and sev­eral other fields. Chances are, there’s work in all of those fields you should at least be aware of, if not read and cite.

Q: Suppose that you attempt to solve a usabil­ity prob­lem for a cer­tain kind of soft­ware tool; HCI researchers may per­ceive that you are solv­ing only a very nar­row prob­lem, and thus your con­tri­bu­tion is small. How do you deal with that?

The typ­i­cal solu­tion to this prob­lem is find­ing a com­mu­nity that thinks your prob­lem is broad instead of nar­row. HCI research tends to have a fairly broad view of the world, since its so applied, so under­stand­ably, many prob­lems will viewed as small (just like any non-academic would view our prob­lems as nar­row). The best one can do is demon­strate what rela­tion the prob­lem has to soci­ety and what impact it might have on the world – not just on the tool users.

Q: Where should soft­ware researchers send their human-centered papers?

Anon: CHI is an obvi­ous choice, but it’s the pre­mier con­fer­ence in HCI, which makes it a dif­fi­cult tar­get even for very expe­ri­enced HCI researchers. Beyond CHI, what would we rec­om­mend? I’ve been invest­ing in VL/HCC, the log­i­cal suc­ces­sor to the sadly defunct Empir­i­cal Stud­ies of Pro­gram­mers (ESP) con­fer­ence. It’s a strong sec­ondary con­fer­ence, with a first-rate com­mu­nity, but with less con­tent about pro­fes­sional SEs than I would like. I’m hard-pressed to rec­om­mend another HCI conference.

About a month ago, Emer­son Murphy-Hill (cur­rently a post-doc at UBC) asked if he could inter­view me about the chal­lenges of doing HCI research about Soft­ware Engi­neer­ing (and vice versa). I’ll post our inter­view in two parts: the first, listed here, cov­ers HCI and soft­ware engi­neer­ing research and the sec­ond cov­ers pub­lish­ing in HCI venues.

Q: What are the biggest dif­fer­ences between the HCI and soft­ware research?

Both pur­suits are very problem-driven: we want things that work, that demon­stra­bly solve issues, and move prac­tice and our under­stand­ing of prac­tice for­ward. Not only that, but both pur­suits are largely inter­ested in solv­ing the same prob­lem: we want to find ways of cre­at­ing soft­ware and tech­nol­ogy that achieves its require­ments and ulti­mately serves cus­tomer and user needs.

Where HCI and soft­ware research dif­fer are in their meth­ods. Most HCI research focuses on under­stand­ing the con­text being designed for and using this under­stand­ing to drive inno­va­tion. Soft­ware research often works the other way around, seek­ing inno­v­a­tive tech­no­log­i­cal approaches to well-established prob­lems, but not often doing for­ma­tive research to dis­cover new prob­lems. The other dif­fer­ence between the two pur­suits is the breadth of their method­olog­i­cal tool­boxes. HCI researches will use what­ever method is appro­pri­ate for a research ques­tion, whether that means con­trolled exper­i­ments, inter­views, ethno­graphic field work, or any num­ber of the­o­ret­i­cal frame­works and for­malisms. Soft­ware research tends to be more restricted method­olog­i­cally, focus­ing mainly on first order logic and quan­ti­ta­tive empiri­cism. In my view, this restricted set of epis­te­mo­log­i­cal tools pre­vents soft­ware researchers from see­ing the larger con­text of the prob­lems we try to solve.

Q: It sounds like you are sug­gest­ing that soft­ware research could make more of an effort to do for­ma­tive research to find prob­lems. Are there any areas in soft­ware research that you think that we don’t truly under­stand the nature of the problems?

I think that soft­ware research, as a whole, severely under­es­ti­mates the role of com­mu­ni­ca­tion, coor­di­na­tion, and man­age­ment in suc­cess­ful soft­ware projects. The impor­tance of this fac­tor has been claimed for decades and stud­ied infre­quently for nearly 20 years, but it plays such a minor role in most soft­ware engi­neer­ing research. This is sur­pris­ing, since most other engi­neer­ing dis­ci­plines focus heav­ily on the actual human process of engi­neer­ing dif­fer­ent goods.

Another area that is under­stud­ied is the notion of require– ments and what they actu­ally mean. Ulti­mately, the role of soft­ware in human­ity is to sup­port human­ity, but more often then not, soft­ware engi­neers let the medium, rather than human­ity, dic­tate the design. There are inter­est­ing con­nec­tions between Require­ments Engi­neer­ing and HCI, in that both seek to elicit require­ments, but using dif­fer­ent meth­ods. I’ve seen very lit­tle work that bridges these dif­fer­ent approaches to soft­ware design. Gen­er­ally, most soft­ware research focuses on “get­ting the design right” rather than “get­ting the right design.”