http://queue.acm.org/ http://queue.acm.org/detail.cfm?ref=rss&id=3395214 The Lindy effect tells us that if a paper has been highly relevant for a long time, it's likely to continue being so for a long time to come as well. My first choice is "How Do Committees Invent?" Author Melvin E. Conway provides a lot of great material that led up to the formulation of the law that bears his name. My second choice is Lisanne Bainbridge's "Ironies of Automation." It's a classic treatise on the counterintuitive consequences of increasing levels of automation. Wed, 15 Apr 2020 17:22:24 GMT 3395214 http://queue.acm.org/detail.cfm?ref=rss&id=3394057 There is no single answer to the question of how to apply software to systems that can, literally, kill us, but there are models to follow that may help ameliorate the risk. The risks involved in these systems come from three major areas: marketing, accounting, and management. It is not that it is impossible to engineer such systems safely, but the history of automated systems shows us that it is difficult to do so cheaply and quickly. The old adage, "Fast, cheap, or correct, choose two," really should be "Choose correct, and forget about fast or cheap." But the third leg of the stool here, management, never goes for that. Wed, 08 Apr 2020 12:08:09 GMT 3394057 http://queue.acm.org/detail.cfm?ref=rss&id=3391621 When work began at Mozilla on the record-and-replay debugging tool called rr, the goal was to produce a practical, cost-effective, resource-efficient means for capturing low-frequency nondeterministic test failures in the Firefox browser. Much of the engineering effort that followed was invested in making sure the tool could actually deliver on this promise with a minimum of overhead. What was not anticipated, though, was that rr would come to be widely used outside of Mozilla?and not just for sleuthing out elusive failures, but also for regular debugging. Sat, 28 Mar 2020 12:26:45 GMT 3391621 http://queue.acm.org/detail.cfm?ref=rss&id=3390746 Many engineering projects are big and complex. They require integrating into the existing environment to tie into stuff that precedes the new, big, complex thing. It is common to bemoan the challenges of dealing with the preexisting stuff. Many times, engineers don't realize that their projects (and their paychecks) exist only because of the preexisting and complex systems that impose constraints on the new work. This column looks at some sophisticated urban redevelopment projects that are very much part of daily life in San Francisco and compares them with the challenges inherent in building software. Tue, 24 Mar 2020 12:44:11 GMT 3390746 http://queue.acm.org/detail.cfm?ref=rss&id=3388781 Self-sovereign stablecoins are interesting and probably here to stay; however, they face numerous regulatory hurdles from banking, financial tracking, and securities laws. For stablecoins backed by a governmental currency, the ultimate expression would be a CBDC. Since paper currency has been in steady decline (and disproportionately for legitimate transactions), a CBDC could reintroduce cash with technological advantages and efficient settlement while minimizing user fees. Mon, 16 Mar 2020 17:11:47 GMT 3388781 http://queue.acm.org/detail.cfm?ref=rss&id=3388515 Smaller transistors can do more calculations without overheating, which makes them more power efficient. It also allows for smaller die sizes, which reduce costs and can increase density, allowing more cores per chip. The silicon wafers that chips are made of vary in purity, and none are perfect, which means every chip has a chance of having imperfections that differ in effect. Manufacturers can limit the effect of imperfections by using chiplets. Fri, 13 Mar 2020 12:39:07 GMT 3388515 http://queue.acm.org/detail.cfm?ref=rss&id=3387947 People often use lists of various sizes when communicating. I might have 2 reasons for supporting the new company strategy. I might tell you my 3 favorite programming languages. I might make a presentation that describes 4 new features. There is 1 vegetable that I like more than any other. The length of the list affects how the audience interprets what is being said. Not aligning with what the human brain expects is like swimming upstream. Given the choice, why would anyone do that? Wed, 11 Mar 2020 12:14:54 GMT 3387947 http://queue.acm.org/detail.cfm?ref=rss&id=3384393 The two papers I've chosen for this issue of acmqueue both challenge the way we think about and use data, though in very different ways. In "Stop Explaining Black-box Machine-learning Models for High-stakes Decisions and Use Interpretable Models Instead," Cynthia Rudin makes the case for models that can be inspected and interpreted by human experts. The second paper, "Local-first Software: You Own Your Data, in Spite of the Cloud," describes how to retain sovereignty over your data. Tue, 18 Feb 2020 12:20:53 GMT 3384393 http://queue.acm.org/detail.cfm?ref=rss&id=3383461 Many silly metrics have been created to measure work, including the rate at which tickets are closed, the number of lines of code a programmer writes in a day, and the number of words an author can compose in an hour. All of these measures have one thing in common: They fail to take into account the quality of the output. If Alice writes 1,000 lines of impossible-to-read, buggy code in a day and Carol writes 100 lines of well-crafted, easy-to-use code in the same time, then who should be rewarded? Wed, 12 Feb 2020 14:08:11 GMT 3383461 http://queue.acm.org/detail.cfm?ref=rss&id=3382016 The goal of a hardware root of trust is to verify that the software installed in every component of the hardware is the software that was intended. This way you can verify and know without a doubt whether a machine's hardware or software has been hacked or overwritten by an adversary. In a world of modchips, supply chain attacks, evil maid attacks, cloud provider vulnerabilities in hardware components, and other attack vectors it has become more and more necessary to ensure hardware and software integrity. Tue, 04 Feb 2020 13:47:02 GMT 3382016 http://queue.acm.org/detail.cfm?ref=rss&id=3380780 Given that humanity's study of the sociological factors in safety is almost a century old, the technology industry's post-incident analysis practices and how we create and use the artifacts those practices produce are all still in their infancy. So don't be surprised that many of these practices are so similar, that the cognitive and social models used to parse apart and understand incidents and outages are few and cemented in the operational ethos, and that the byproducts sought from post-incident analyses are far-and-away focused on remediation items and prevention. Tue, 21 Jan 2020 13:23:16 GMT 3380780 http://queue.acm.org/detail.cfm?ref=rss&id=3380779 Some initial considerations to control cognitive costs for incident responders include: (1) assessing coordination strategies relative to the cognitive demands of the incident; (2) recognizing when adaptations represent a tension between multiple competing demands (coordination and cognitive work) and seeking to understand them better rather than unilaterally eliminating them; (3) widening the lens to study the joint cognition system (integration of human-machine capabilities) as the unit of analysis; and (4) viewing joint activity as an opportunity for enabling reciprocity across inter- and intra-organizational boundaries. Tue, 21 Jan 2020 13:15:43 GMT 3380779 http://queue.acm.org/detail.cfm?ref=rss&id=3380778 Four incidents from web-based software companies reveal important aspects of anomaly response processes when incidents arise in web operations, two of which are discussed in this article. One particular cognitive function examined in detail is hypothesis generation and exploration, given the impact of obscure automation on engineers' development of coherent models of the systems they manage. Each case was analyzed using the techniques and concepts of cognitive systems engineering. The set of cases provides a window into the cognitive work "above the line" in incident management of complex web-operation systems. Tue, 21 Jan 2020 13:09:53 GMT 3380778 http://queue.acm.org/detail.cfm?ref=rss&id=3380777 Knowledge and understanding of below-the-line structure and function are continuously in flux. Near-constant effort is required to calibrate and refresh the understanding of the workings, dependencies, limitations, and capabilities of what is present there. In this dynamic situation no individual or group can ever know the system state. Instead, individuals and groups must be content with partial, fragmented mental models that require more or less constant updating and adjustment if they are to be useful. Tue, 21 Jan 2020 13:03:31 GMT 3380777 http://queue.acm.org/detail.cfm?ref=rss&id=3380776 Understanding, supporting, and sustaining the capabilities above the line of representation require all stakeholders to be able to continuously update and revise their models of how the system is messy and yet usually manages to work. This kind of openness to continually reexamine how the system really works requires expanding the efforts to learn from incidents. Tue, 21 Jan 2020 12:56:47 GMT 3380776