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.