I am honored to have my recent paper, "The Grand Unified Model of DevOps/SRE Dynamics" (at times referred to simply as "GUM"; the direct link to my paper only is at https://github.com/scottvr/GUM_of_Devops/blob/main/The_Grand...), appear in the proceedings of SIGBOVIK 2026. (Finally, the tull proceedings are released! This is not a dupliate of older submitions, best I could tell, and in any case the focus is on my paper, now tha the full proceedings are out there. https://sigbovik.org/2026/)
The venue and publication are a good fit for the paper and serve as useful signals for the temperament of the paper and the treatment throughout the development of the model. It also says something about the reviewers acuity and elite selection criteria, which are to be celebrated for what they are.
As my paper's abstract makes clear, the model is not offered as a predictive instrument in the strict scientific sense. It is instead a formalized account of a familiar practitioner truth: software delivery is not shaped only by pipelines, tooling, deployment frequency, or architectural complexity; it is also shaped by technical debt, morale, urgency campaigns, competence mismatch, and executive volatility.
The ethos of GUM does not stem from a belief that DevOps metrics are useless. Rather, they are useful enough to make omissions conspicuous. If we can assign symbols to deployment frequency and change failure rate, we may eventually have to admit that organizations themselves also perturb the system. Recent literature has done much of the work of formalizing the example proxies given in GUM 1.0, which allows us to construct a new model that may satisfy the critics who claimed GUM 1.0 required "measuring the immeasurable."
While researching for GUM 2.0, we were surprised by how rapidly the recent literature appears to be moving into territory adjacent to that of the GUM. One paper formalizes delivery speed as a function of automation and CI/CD maturity; another models developer-experience variables such as cognitive load and technical frustration as causal contributors to release-cycle duration, which looks quite a lot like the GUM term M (Developer Morale Multiplier). A third attempts to quantify technical debt as a compound-interest problem with remediation ROI. It is, of course, an honor to see how much impact the GUM has had, even if it has not yet been cited in any papers. A more thorough survey of these papers from recent literature can be found at the GUM's primary site at https://github.com/scottvr/GUM_of_Devops/blob/main/sigbovik2...
We are currently working to address these developments in GUM v2.0. As stated in the original "Grand Unified Model of DevOps", when the real world begins to collide with a model, *it is time to introduce more formalism.*
ycombiredd•1h ago
The venue and publication are a good fit for the paper and serve as useful signals for the temperament of the paper and the treatment throughout the development of the model. It also says something about the reviewers acuity and elite selection criteria, which are to be celebrated for what they are.
The conference proceedings are also available in print from Lulu at https://www.lulu.com/search?sortBy=PUBLICATION_DATE_DESC&pag... Just FYI.
As my paper's abstract makes clear, the model is not offered as a predictive instrument in the strict scientific sense. It is instead a formalized account of a familiar practitioner truth: software delivery is not shaped only by pipelines, tooling, deployment frequency, or architectural complexity; it is also shaped by technical debt, morale, urgency campaigns, competence mismatch, and executive volatility.
The ethos of GUM does not stem from a belief that DevOps metrics are useless. Rather, they are useful enough to make omissions conspicuous. If we can assign symbols to deployment frequency and change failure rate, we may eventually have to admit that organizations themselves also perturb the system. Recent literature has done much of the work of formalizing the example proxies given in GUM 1.0, which allows us to construct a new model that may satisfy the critics who claimed GUM 1.0 required "measuring the immeasurable."
While researching for GUM 2.0, we were surprised by how rapidly the recent literature appears to be moving into territory adjacent to that of the GUM. One paper formalizes delivery speed as a function of automation and CI/CD maturity; another models developer-experience variables such as cognitive load and technical frustration as causal contributors to release-cycle duration, which looks quite a lot like the GUM term M (Developer Morale Multiplier). A third attempts to quantify technical debt as a compound-interest problem with remediation ROI. It is, of course, an honor to see how much impact the GUM has had, even if it has not yet been cited in any papers. A more thorough survey of these papers from recent literature can be found at the GUM's primary site at https://github.com/scottvr/GUM_of_Devops/blob/main/sigbovik2...
We are currently working to address these developments in GUM v2.0. As stated in the original "Grand Unified Model of DevOps", when the real world begins to collide with a model, *it is time to introduce more formalism.*