we might describe the operational space of software in the context of a user at a desktop system as having a liminal boundary

If the interrupt teaches us anything about software, it is that software is in many cases only as effective as the people who use it, those mondeterministic machines with their complex, non-reproducible behaviors, those "others" on whom it relies--can it really control such beasts? To understand software in terms of the interrupt is to understand it in terms of its place within larger structures of social formation and governance. Software engineering is simultaneously social engineering. Software criticism, therefore, must also be simultaneously social. In critically engaging with software, we must not only map the vectors of the interrupt, but also seek to make our own interruptions, to pose questions and insert alternative vectors and practices within the assemblages it connects to.