Liturgy as Software?

Over at the National Catholic Reporter, Tom Reese has a piece on Francis’s recent Motu Proprio in which be exploits the metaphor of liturgy as software that gets periodic upgrades. He also makes some concrete suggestions regarding the next “upgrade” that the liturgy should receive. Some of these suggestion might be good ideas (considering a re-visit of 1998), some seem like bad ideas (a preface for every Sunday of the year “that would pick up themes from the Scripture readings of that Sunday so that the congregation would see a connection between the Liturgy of the Word and the Liturgy of the Eucharist”? Talk about tying the hands of the homilist by treating the liturgy as bound to a “theme”!). But what interests me more is the very metaphor of liturgy as software that gets upgraded.

I find the metaphor disturbing because it presumes that liturgical change is driven by a kind of technical advance, whereby every upgrade is presumed to be an advance over what came before, offering more ease-of-use or new features that can accomplish more. But is liturgy really “advancing” in that way? It is a technical activity that accomplishes a task with greater or less efficiency? Do we worship God with greater facility and effectiveness than people did in the day of Gregory the Great or Thomas Aquinas or Charles Borromeo or Dorothy Day?

Also, even though software upgrades often do offer genuine improvements, a lot of the impulse to upgrade is market-driven–the need to offer a product that you simply must have, even though the old product still serves your needs quite well. The impulse to upgrade is driven by a restlessness that may be a kind of Ignatian semper maior, but also may be the Augustinian restlessness brought about by alienation from God. Do we really want to think of liturgy in this way?

Fr. Reese does seem to consider the possibility that not everything new is good—that in addition to real advances like Windows xp we also have turkey’s like Windows Vista. His example of such an unfortunate upgrade is the 2011 translation. But couldn’t one argue equally well that the reformed post-Vatican II Missal is the real analogue to Widows Vista, and that the 1962 Missal is the gold standard to which we should return, and from which all future upgrades should be made? In other words, once you introduce the idea of upgrades that are not good, you need to argue the merits of each individual upgrade—being new is not enough to make something good. But then how do we argue those merits? If we’re going to stick with the software analogy, it seems as if we are going to have to make our argument in terms of functionality. But, as I suggested above, I am not sure that liturgy is “functional” in the way that software is. It seems to me that whatever sort of evaluation is involved in liturgical reform, it cannot be based on the idea of “continuous quality improvement” or even “upgrading.”


  1. When I read his column this morning, I thought the simile a terrible idea.

    If a bane of liturgy before the Council was cultic purism combined with legal minimalism (liturgy as reified performance), a bane of the liturgy since then has been functionalism (liturgy as product, especially as a talisman to elide boredom*).

    Notice the itch [such as if we do X, then Y will happen]. Be skeptical about it; wonder about magical thinking that may lurk behind it. Also wonder if our solution to the itch likely ensures we will simply reinvent the itch in another guise. Rinse and repeat. Especially if one is tempted by BSO (Bright Shiny Object) Syndrome, a common ailment among sales folk and people who write for a living.


    * Boredom has to be penetrated, not elided. Shifting the ritual won’t help. Boredom is, understood properly, an opportunity – among other things, to experience Incompletion, and thus connect with our desire for God.

  2. Liturgy functions, in large part, to maintain traditions, a function that software does not serve. That large difference aside, I kind of like the analogy. Aesthetics, accessibility, and efficiency are things to consider in liturgical upgrades. We can take the analogy further. Software often has different editions that co-exist. Home and pro. Free and premium. Mobile and desktop. They share a lot in common and are usually upgraded simultaneously but aren’t the same. Can we get an upgraded calendar to be used in both the OF and EF? Then there’s betas, alphas, and internal builds that test concepts with a small group before rolling it out to everyone. The 1969 Mass shouldn’t have been released to manufacturers. It should have served as the first test build.

  3. Yes, a terrible idea. (Sorry, Tom. And congrats on your new RNS position!)
    Feeds into the worst of the traddie narrative about liturgical reform being a sacrilegious orchestrating of something divine.

  4. I tend to agree with Emeritus Pope Benedict, that we need an evolution of both current forms of the Roman Liturgy. The development of proprietory computer operating systems like Windows does not provide a fruitful model, in my opinion. However the evolution of some non-proprietory parts of the computing environment would, I feel, have something to teach us. These procede by public discussion until a broad consensus is achieved, including detailed analysis by objectors to show up flaws in proposals. The decision is then taken by a small committee. This is the way we have moved with HTML. Note that HTML4 came out in 1998, and HTML5 in 2014, so it is not a breakneck process even in such a rapidly changing environment.
    Obviously the analogy is not a close one, our environment does not change much, at least God does not, nor human nature change much, though there is a revolution in literacy. There are also technological changes (lighting, sound systems, building methods and materials) which affect the performance of liturgy.

  5. As a programmer working on software some of which was written in the 1970s, it does not strike me as a ridiculous metaphor. When we change things because the outside environment has changed, we must not forget what the software was designed to do, and how it has evolved over the years. Sometimes the right thing to do is to start again, and reimplement a feature from scratch (for example when there have been so many accretions that it is hard to tell what the primary function is), but more often incremental development is more appropriate – provided that you do take the time to refactor and rearchitect what you have changed.
    But I do see that to a user, the metaphor will feel different.

    The function is to build up Christians for living in secular society.
    This function is carried out through sharing Scripture and reflecting upon it in community in light of the immediate challenges facing the members of the community. The existence of the community is confirmed through the sharing of a meal as commanded by Jesus.
    All else is commentary or cultural accretions.
    It is better liturgy if it does a better job of building up the strength of the participants. This requires, among other things, that ALL present participate fully, actively, and consciously; that the ministers are not just going through the motions nor anyone merely be present out of obligation or reward seeking.

    1. The primary point of liturgy is to praise and encounter the transcendent God, to thank Him for his providence and benefits, to seek his intercession for our own needs and the needs of the whole Church (and thereby implicitly or explicitly the needs of the entire world). Some of the fruits of this encounter lead to formation in discipleship and consolation for both the community as a whole and the members as individuals.

  7. One key to successful incremental “versioning” of commercial software is a healthy feedback loop between the magisterium (the developers) and the people (the customers). Through customer service and technical support, the developers are made aware of problems and shortcomings in the current version, as well as new features that their customers want, in some cases because the software’s competitors offer those features already.

    When a new release is ready, it goes into a “beta release” in which it is thoroughly tested in real-life customer environments (oftentimes, these include the most loyal and creative among the customer base, as well as opinion-makers who are most likely to influence subsequent market acceptance); any glitches are carefully monitored by the developers and corrected before the official release. This beta cycle can be very effective when there is healthy and trusted collaboration between the developers and the customers. Some beta releases are made available to many thousands of beta testers.

    1. “(oftentimes, these include the most loyal and creative among the customer base, as well as opinion-makers who are most likely to influence subsequent market acceptance)”

      Yes, that can skew the process unhelpfully, too.

Leave a Reply

Your email address will not be published. Required fields are marked *