The tyrant system is where your project dreams go to die. The tyrant system does not answer to anyone. The tyrant system has releases once in a blue moon, and the rest of the organisation had better make sure they fit in. If you don’t like the tyrant system’s API, you are welcome to spend months coding around it, but the tyrant system reserves the right to change and break your code without notice.
The tyrant system gets to say what operating system, what hardware and what other software it will work with. The tyrant system is invulnerable to external change driven by anything smaller than regulatory authorities¹. The tyrant system has a development plan that was set in concrete before you were born; if you want to be agile, knock yourself out.
The tyrant system is easy to spot. It uses 1970’s alphanumeric codes for business terms, and somehow everyone uses them (it is a rite of passage for new joiners to know what a “Z5R” order is). The support team have a web site explaining in great detail what the rules are for the business to get help (and how many months that’s likely to take). In a generally frenetic environment, calm pervades the tyrant system’s development area. There is absolutely no documentation. Recruiters hire for skills in the tyrant system specifically. No one ever explains a tyrant system requirement in business terms. You do it because the tyrant system says it must be done.
There is nothing necessarily wrong with one system to wielding power over others. If you own a business, you want the system closest to the people making money to get highest priority. You have a tyrant when the system calling the shots has nothing to do with that. History offers little comfort. The ruinous reign of a tyrant can last for for decades, and power is never ceded voluntarily. The only hope for us is that, in the very long run, change is inevitable. And perhaps we can also take comfort from the motto of Virginia – sic temper tyrannis!
¹ Assuming your country’s GDP exceeds that of the tyrant system vendor