What are the effects of this enumeration, of these metrics that count our social interactions? In other words, how are the designs of Facebook leading us to act, and to interact in certain ways and not in others? For example, would we add as many friends if we weren’t constantly confronted with how many we have? Would we “like” as many ads if we weren’t told how many others liked them before us? Would we comment on others’ statuses as often if we weren’t told how many friends responded to each comment?
In this paper, I question the effects of metrics from three angles. First I examine how our need for personal worth, within the confines of capitalism, transforms into an insatiable “desire for more.” Second, with this desire in mind, I analyze the metric components of Facebook’s interface using a software studies methodology, exploring how these numbers function and how they act upon the site’s users. Finally, I discuss my software, born from my research-based artistic practice, called Facebook Demetricator (2012-present). Facebook Demetricator removes all metrics from the Facebook interface, inviting the site’s users to try the system without the numbers and to see how that removal changes their experience. With this free web browser extension, I aim to disrupt the prescribed sociality produced through metrics, enabling a social media culture less dependent on quantification.
While the client has some knowledge of his symptoms, he may not understand the real causes of them, and it is foolish to try to cure the symptoms only. Thus while the systems engineers must listen to the client, they should also try to extract from the client a deeper understanding of the phenomena. Therefore, part of the job of a systems engineer is to define, in a deeper sense, what the problem is and to pass from the symptoms to the causes.
Just as there is no definite system within which the solution is to be found, and the boundaries of the problem are elastic and tend to expand with each round of solution, so too there is often no final solution, yet each cycle of input and solution is worth the effort. A solution which does not prepare for the next round with some increased insight is hardly a solution at all.
I suppose the heart of systems engineering is the acceptance that there is neither a definite fixed problem nor a final solution, rather evolution is the natural state of affairs. This is, of course, not what you learn in school, where you are given definite problems which have definite solutions.