I have seen a consistent set of issues when it comes to DevOps implementations. The issues are:
- Clients say they are emploing a DevOps lifecycle, but it’s more the case they are simply doing continuous integration and deployment (CI-CD) supported by an associated tool chain.
- Many times the Dev (development) teams are separate from the Test teams and the Ops (operations/support) teams. Sometimes they are even in different silos in the organization. As a result, communication and collaboration — an critical part of a successful DevOps implementation — may be limited and weak.
- As a result of that separation, the incentives may differ by team. In some cases they can end up almost competing against each other. (For example, I have seen Dev teams take time away from the Test teams in order to complete their assigned development tasks. The Devs “win” and the Testers “lose”.)
- Quality standards held by the Test and Ops teams may not shift left to the Dev teams. As a result, quality responsibilities may lie mostly with Test/Ops, or there is a significant imbalance. (The Devs may do some limited unit or regression testing, but not enough to prevent bugs from being passed downstream in the DevOps lifecycle.)
- Delivered functionality on time may become the primary driver for a project in order to meet the needs of key stakeholders, while the non-functional / quality of the system (e.g., performance, observability) may become secondary or even considered a Day Two problem.
- As a result of all this, it’s not surprising to see Dev teams become focused and measured on delivering functionality at increasing velocities, while the Testers and to some degree the Operators have to maintain that focus / those measurements, while also being responsible for and measured on software quality.
- In the end, you can get a situation where Devs are measured in terms of speed and functionality, while the Testers / Ops are measured on speed, functionality plus software quality. If delivering software is like a game, the Testers and the Operators are playing the game with a handicap due to quality metrics.
I have thought about these issues for some time and I wanted a framework to apply to them so I communicate in a more concrete way not only the issues but how to address them. I thought that one such framework to use could be supplied by game theory.
To apply game theory to DevOps, I started by considering the Devs as one set of players and Testers/Ops as another. To quickly work through some scenarios to see if such an approach was even valid, I decided to use LLM models. First I used GPT-OSS-20B to get my initial results. While it seemed promising, I noticed some errors creep into its analysis with regards to Nash equilibriums. I swapped out that model and used a larger LLM (provided by IBM Bob) to analyze and correct the initial results and produce a final analysis. You can read that final analysis, here.
I learned a few things from this exercise:
- when the Devs are not bound by quality, a Nash Equilibrium is achieved, but it is one where they get a bigger payoff for going as fast as possible and the Testers/Ops have to settle for a situation where they suffer and get a worse payoff.
- If the Devs are bound by quality, they get a lesser payoff but the Testers/Ops get a better payoff and overall software quality can be increased. It seems obvious to do this, but working out a pay-off matrix helps with this.
- Under certain conditions the Nash equilibrium can become weak for the Devs and that may result in them being less quality focused in order to succeed. Again, not surprising.
- Game theory can show why Developers rationally can decide to forgo quality, but it may not be the best way to practically analyze your project. I’d simply recommend you continually work to spread quality measures throughout your DevOps lifecycle and to continually work to improve quality as the software matures.
- LLMs can speed up the production of documentation just like it can speed up the production of code, but you don’t want to solely depend on it to get the documentation correct. Based on my understanding of game theory, I think its output is correct. If someone with a better understanding wants to correct me, I’d be happy to hear about it and I’ll be happy to amend this post.
- For a more important project I would heavily modify the LLM documentation and take more ownership of it. This is more of a side project / exercise for me, so I decided to leave it as it is and move on to bigger things with bigger payoffs, to use the language of game theory. I hope you can still find it useful. I’d suspect the number of people who read it can be measured in one hand.
(P.S. The opinions expressed in this post are mine and do not necessarily reflect those of my employer.)








For a container running in ECS, it is an entirely different beast. You have to:












Yep, it’s true. If you have some technical skill, you can download this repo from github: 










If you are using python packages like xmltodict or yaml to write and read your own XML and yaml files, you probably don’t need to know this. But if you are reading someone else’s files, here is something to be aware of.
If you want to merge PDF files on a Mac, you might be tempted to use a tool like 
Wow. I have not posted any tech links since 


You’ve likely heard of Advent, but have you heard of Advent of Code? Well let the maker of the site, 