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.