Skip to content

Instantly share code, notes, and snippets.

@de-sh
Last active September 18, 2022 17:22
Show Gist options
  • Save de-sh/cd667e15348287b607aa770b664b7f61 to your computer and use it in GitHub Desktop.
Save de-sh/cd667e15348287b607aa770b664b7f61 to your computer and use it in GitHub Desktop.
Drawing an analogy from software, I try to explain my hypothesis that all systems follow the CMD framework

The CMD framework for keeping Systems relevant

As is common knowledge, the main dieties in 'Hindu' philosophy/religion are Brahma, Vishnu, and Maheswara, namely the Creator, Maintainer, and Destroyer.

How do they relate to systems? Well, all systems have to go through the cycles that are creation, maintenance, and destruction, no matter how long lived and endless we believe something is, it's just in its own lifecycle. Since I happen to be from the software background, let me frame this explanation in terms of software systems, but hopefully things make sense to everyone reading.

A system obviously requires a creator, that is non-negotiable, but this Brahma could be an independent developer or a large team. No matter the creator, things usually only start coming into place as there are users to provide feedback and it usually takes multiple iterations for a system to get to a stable state. Genesis might be a long journey, and sometimes it is a simple change, either from within or from outside, that creates a great success.

But who relies on something that was created and then just abandoned? All systems have characteristic entropy, i.e. they degenerate over time and need a Vishnu to keep them from descending into chaos. In terms of software, they usually go irrelevant, lose favour to more featureful alternatives without regular feature additions and timely patches for bugs and vulnerabilities. In the case of FOSS codebases it is often observed that they get forked and are maintained by someone else. Users and external influences are constantly in play, keeping maintainers on their toes.

Alas, all systems reach a point in their lifecycle where their cries for moksha are evident. At times it is obvious that a system has outlived itself when you notice that users are sorely disatisfied and neither the creator nor the maintainer are solely to blame. This might be due to a lack of features that users desperately need or bugs and vulnerabilities are just impossible to find/fix without causing immense pain for all involved. The decision to retire a system is a tough one to take, but sometimes it is just not feasible to keep the suffering alive and a graceful shutdown is to some the epitome of a succesful software project.

While this might be obvious, I happen to see this pattern on a daily basis. Software, and Systems at large go through the successive steps of the CMD framework, some faster than others, with different lengths of time spent in the different stages. Being aware of when a system is to be built, ready for maintenance or even destruction, is probably a super power in the world of management that can lead to better decisions, for the welfare of the source and the affected alike.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment