The rise and fall of the Dungeon Master

  • The Dungeon Master is the author of the original software, that used to support the business in the early days, and still does (albeit with some headaches).
  • He’s deeply entrenched with the software, in facts he knows the software better than anyone else. Even if he’s not any more a software developer, he’s still at close distance from its creation.
  • Whenever there’s a problem in that software (and that happens) he’s the one to talk to.
  • They usually are surrounded by minions, the complementary anti-pattern that deserves a post of its own (coming soon).

Having a Dungeon Master as Product Owner or Domain Expert is a terrible idea

Cyrille Martraire exposed it very well during this year’s DDDEurope:

  • On one hand, the replacement is needed because the company grew, it has now more budget and this is because the legacy software made it possible. In other words the DM did a great job carrying the business on his shoulders. Self esteem is pleased.
  • On the other hand, the replacement is needed because we are now hitting the limits of the original approach, be it the model, the technology, the market evolution or the understanding of them all. Releasing a new solution, way better than the original one, will prove that the DM did a bad job. This doesn’t have to be true to be a problem. It’s the unconscious fear of this to happen (Imposter syndrome, maybe) that drives these unspoken thoughts. Imagine the awkward feeling of walking through armies of employees commenting “Oh, finally some decent software!”.
  • at the conscious level Dungeon Master will join meetings and provide expertise to new developers; he will eventually drop too much knowledge mixing up domain knowledge and his own interpretation, often in the legitimate pursuit to save some time.
  • at the unconscious level, new ideas from the development team will inevitably put him on a defensive stance. After all I’ve been thinking to this problem for years, who are you to propose a ‘better’ solution in a few days? or, put in another way, smarter ideas will make him feel or look stupid.
  1. The new project is much better than its predecessors, allowing for better revenues, and many interesting side effects. However this will also expose how bad the legacy software was and how much money was lost in keeping it alive longer than needed. In a healthy company culture, this won’t be necessarily a problem. It’s part of learning the business. In some cultures this is not acceptable.
  2. The new project is slightly better than the legacy. The ego is somewhat safe, but then the whole thing will start to look awkward: was it really necessary to rewrite the software, for so little advantage? However, a little improvement, especially if coming from new technologies that weren’t available before, is probably the sweetest spot.
  3. The new project is a failure, an endless bloodbath leading nowhere. This is the best option for the Dungeon Master ego, maybe the company wallet will be hit, but a failure in improving his creation will see him triumphant. Despite a bigger budget and armies of developers nobody could be better than he did.

Pretend is a technology problem

Companies can smell the problem, but maybe can’t diagnose it right. Blaming a technology now becoming obsolete is a cheap scapegoat.

  • Good: new technologies were not available at the time the software was written. Using new stuff, like microservices, could allow approaches that were not available at the time the software was written. Whether this is actually true or not, the honour is safe. (Clarification: I am not recommending microservices or any other technology approach, just using one, as an example of a technology fresh enough not to be available. Please, don’t use this one as s Straw Man)
  • Bad: in practice, this often leads to an expensive rewrite of the existing codebase, with little or no improvement of the actual system behaviour. Most of the time, the generated value is negative: new technologies enslaved to legacy constraints create a sense of frustration in the development team that often leads to more severe troubles. After seeing tons of money flushed developing large SOAs that ended up wrapping legacy databases, I don’t believe this works.

Think Money First

Often the DM has already been taking some management responsibilities, or even some stakes in the company. It is a good thing if the DM starts thinking business first and worry only about Return on Investment and Cost of Ownership.

  • Good: hypothetically, from his management role, the Dungeon Master is now detached from mundane things like table structures, primary keys and validation criteria.
  • Bad: he is not. The attachment to the solution is still there. Developers installing a Message Bus to replace a database trigger will be a cruel torture. But money tells a different story too. The moment a different implementation shows that a lot money could have been saved, then the cost of keeping the old software for too long is exposed too. And this can be scary: imagine you discover a wrong design decision you made 10 years ago costed millions to your company… would you happily expose it?

Make them part of the new team

A dreamy way out could be to offer them the option to enter history, being part of the winning team that delivered the old version of the software and of the new team too. Like athletes with a career that spans generations.

  • Good: in theory, this could revive the best instincts. These people are smart, and being part of a new game could make them unleash their best energies.
  • Bad: the amount of re-learning is going to be huge. They are going to find themselves less productive than their younger peers, good in useless things, but embarrassingly slow in what matters today. The temptation to fall back to “the old ways” or “the dark side” will always be there. If DMs climbed up hierarchy in the meanwhile, this is not going to be viable.

Bypass them

Acknowledge from the beginning that their contribution is going to be small or negligible. Leave them the option to play the role of “the grumpy old man” commenting the outcome of new generations of developers, but basically bypass them by opening a direct communication channel between today’s developers and today’s stakeholders (which is a good idea anyway).

  • Good: you may discover what the real problem is, without the need to be conformist to yesterday’s solution. More insights can emerge, from conversation happening now eventually leading to a different product, more aligned with the current needs.
  • Bad: the old software would still be around. Collaboration will need to happen even in order to bypass systems. Treating an internal piece of software like an uncontrolled third party one could put project lead under scrutiny, while the opposite could open the door to sabotage.

Separate paths

I am not suggesting to hire a hitman, but to acknowledge that the project would be better off without the Dungeon Master around. If you’re looking for a paradigm shift, you’ll need a team with a different attitude and emotional bonding with the legacy.

  • Good: the team can now look for the best solution available, no matter what, and eventually implement breakthroughs from alternative approaches. The project is now on a learning path, instead of a conformity path, and the mood will reflect it. The Dungeon Master is now free from the curse of maintaining the legacy and can finally go back to life.
  • Bad: a big theoretical money saver (we already have domain expertise) is gone. The need for re-learning is visible, and will affect project estimates. Whenever a bad decision is taken (and this will happen, since the team will be learning), the ghost of the Dungeon Master will appear in the room, warning that things should have been done differently and playing endless “what if …” mind games with the key stakeholders. Not having DMs as part of the team won’t guarantee success (well, …nothing does). It mostly depends on the size of the dungeon, but on many other factors too. In general, this won’t be an easy decision. There’s gratitude and there’s business. And they don’t always go together.

Turn DM into “pure stakeholders”

A lot of the problem revolves around the Product Owner role. Too much power in these hands. Having a Dungeon Master fit into a stakeholder role among many would probably mitigate the problem.

  • Good: stakeholders need to pass through the PO in order to steer development, so they shouldn’t micromanage the backlog, and also be forced not to mix explicit and implicit requirements. Only what is “official” will be delivered.
  • Bad: whether this approach is workable depends a lot on the people involved, and on the organisation (internal project? contractors? what is the current role of the DM?). It could turn again into a power struggle or allow subtle forms of sabotage.

What if YOU are the Dungeon Master?

If you recognised yourself in this portrait (guess what, I did recognise myself in a couple of traits too), you’re probably going to be disappointed, because I haven’t given many workable solutions.

Let it go

You did a great job. You did your best given the constraints and the things you knew at the time you wrote software. You probably did also a lot of things by yourself, because Pair Programming wasn’t in the cards then. So thank you! However, while you’ve been busy doing stuff, somebody else had the privilege of experimenting with NodeJS, microservices and a lot of cool stuff you probably won’t be able to cope with, because you don’t have all that free time anymore. (Clarification, again. This one made a lot of people portray me as a young developer advocating technology as a silver bullet. I am actually the opposite: a former developer acknowledging that I won’t have anymore the privilege of being as good in a given technology as I used to be when I was writing code most of the time).

Start something new

The real fun is in the early days, with not so much responsibility (the business wasn’t that big after all) and people needing you? What about starting something entirely different from scratch?

Restart, but really

This is the “make them part of the new team” from the Dungeon Master Perspective, and I said it’s very unlikely to work. But my statistical sample isn’t big enough to give certainty, and I had the privilege to meet unicorns in my profession. So in case you want to try…

Conclusion?

As I mentioned before, frustration was the main driver for writing this post. Mostly the frustration of seeing project settlement where people are supposed to act in a way that is not going to work, and to see the struggle on both sides of the fence.

--

--

I like to solve problems and to write software that does that. I’ll flood you with sticky notes and call it #EventStorming. I run http://www.avanscoperta.it

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Alberto Brandolini

Alberto Brandolini

I like to solve problems and to write software that does that. I’ll flood you with sticky notes and call it #EventStorming. I run http://www.avanscoperta.it