The rise and fall of the dungeon master on software projects
I feel like I&#x27;m somewhat of a &quot;Dungeon Master&quot; right now, and this article comes across as somewhat condescending. I think this is because right off the bat, we make the assumption that,<p>&gt; <i>The dark secret of the Dungeon Master is that he knows every trap in the existing legacy software, because he was the one to leave the traps around.</i><p>It could be that your Dungeon Master isn&#x27;t responsible for the traps; perhaps they were handed to him from his predecessor, or they were the result of a bad tradeoff — in my experience, usually quality being sacrificed in favor of short term time and cost (and much to the detriment of long term development), time and again, without ever allowing the dev team to revisit the accumulated technical debt, until it becomes so back breaking that we throw our hands up and — against what seems to be the prevailing wisdom — cry for a rewrite. If you start from such an accusatory stance as the above, well, yes, you and your &quot;Dungeon Master&quot; are going to have an adversarial relationship.<p>I feel like when I&#x27;ve been in this position, it&#x27;s not the code that I&#x27;m trying to protect: the code is awful, and I&#x27;ll readily admit that. However, it meets a set of requirements, albeit badly; but more often than not I see the rewrite dropping crucial requirements in favor of &quot;simplicity&quot;, or &quot;we&#x27;re going to start with a minimum viable product&quot; — after which you&#x27;ll repeat the history of the same set of mistakes that the original made by allowing your product to grow organically, all the while ignoring the existing implementation that is ripe with knowledge of how well that won&#x27;t go.<p>&gt; <i>The worst domain expert is the one whose expertise is built from the intricacies of the existing systems</i><p>I agree! And yet this article seems to seek to vilify this person. We <i>shouldn&#x27;t</i> have domain experts whose domain is the cruft of the system, but as long as our software development processes are so broken that the problems with the current system can&#x27;t be addressed, I&#x27;d much rather have someone who is aware of what the limitations of that system are, what corners can be cut and what the risks of cutting them are.<p>Perhaps you&#x27;ve ran into someone who is really as counterproductive as the article makes a Dungeon Master out to me, but I&#x27;ve never so feared for my job security, which seems to be the core reason provided for the Dungeon Master&#x27;s behavior and position. The article comes across as incredibly deadset on a us vs. them mindset, to the point where I question whether the author should take a step back as ask if he isn&#x27;t himself part of the problem.<p>&gt; <i>They are going to find themselves less productive than their younger peers, good in useless things, but embarrassingly slow in what matters today.</i><p>This struck me as incredibly ageist when I read it. He recants somewhat at the end,<p>&gt; <i>One thing that I didn’t intend was to raise a generational&#x2F;age issue. Thanks to Ann Witbrock for pointing me to that. It’s not age: it’s attitude, systems and vicious circles.</i>