4 ms·

I feel like I'm somewhat of a "Dungeon Master" right now, and this article comes across as somewhat condescending. I think this is because right off the bat, we

I feel like I'm somewhat of a "Dungeon Master" right now, and this article comes across as somewhat condescending. I think this is because right off the bat, we make the assumption that, > 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. It could be that your Dungeon Master isn'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 "Dungeon Master" are going to have an adversarial relationship. I feel like when I've been in this position, it's not the code that I'm trying to protect: the code is awful, and I'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 "simplicity", or "we're going to start with a minimum viable product" — after which you'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't go. > The worst domain expert is the one whose expertise is built from the intricacies of the existing systems I agree! And yet this article seems to seek to vilify this person. We shouldn't 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't be addressed, I'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. Perhaps you've ran into someone who is really as counterproductive as the article makes a Dungeon Master out to me, but I've never so feared for my job security, which seems to be the core reason provided for the Dungeon Master'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't himself part of the problem. > They are going to find themselves less productive than their younger peers, good in useless things, but embarrassingly slow in what matters today. This struck me as incredibly ageist when I read it. He recants somewhat at the end, > One thing that I didn’t intend was to raise a generational/age issue. Thanks to Ann Witbrock for pointing me to that. It’s not age: it’s attitude, systems and vicious circles.

jamesmiller5 10y ago
> Perhaps you've ran into someone who is really as counterproductive as the article makes a Dungeon Master out to me, but I've never so feared for my job security, which seems to be the core reason provided for the Dungeon Master's behavior and position. I have and it's very scary indeed. I've heard "You will be fired if you don't support technology X" simply because that's the technology the DM used originally and is more familiar with. I'm not disagreeing with your other comments, but I think the authors main point boils down to when a DM's ego becomes tied to a system in need of replacing, the act of replacing said system can feel like a personal attack to that DM. If that developer is in a or has risen to a position of power it can feel even more intimidating to suggest other technologies. That being said, I've learned to expect such behavior. It's part of the job. A great skill to have is negotiating and communicating why the system needs to be replaced in such a way that the DM is collaborating and seeing the value the new system can produce. I'm going to work with people everyday that don't see or don't like how I'm trying to solve something and their concerns need to be addressed for us to continue working together.
- pm 10y ago
  BobX is the logical conclusion of said behaviour. http://thedailywtf.com/articles/We-Use-BobX http://thedailywtf.com/articles/We-Use-BobX
sbov 10y ago
I'm destined to be a "dungeon master" on a recent project, and would love to restart with an MVP. I had to fight tooth and nail to leave out features no one was going to use - some of which weren't cut. Project manager kept predicting we would be done in 1 month when we obviously had way more than 1 months worth of work. Ultimately we ended up developing our current version as if it was just 1 month from being done (cut some corners so we can hit the target!) for the majority of it's development time.
bigger_cheese 10y ago
Like you I think I've inadvertently become the "Dungeon Master". I don’t like maintaining a legacy app but if you’re going to replace this software the replacement better be an improvement. > 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 take issue with this quote as well. In my experience, I know about the traps because I've seen what happens when they get triggered and had to recover from them - often at great time and expense. Put another way traps are edge cases and like any system it's easy to account for 90% of the complexity it's the remaining 10% of edge cases that cause the headaches. When I hear a young developer say something like "We’ll just use a const and assume each day is 24 hours long because it simplifies the code immensely". When I then point out they’ve stumbled into a trap because their program will now fail catastrophically twice a year (daylight savings, when you have a 23 and 25 hour day). I’m not doing it to be a curmudgeonly dungeon master trying to protect my turf. I’m pointing it out because I’ve dealt with that pain when I got bitten by DST in the app I maintain. I was young once too. It’s easy for some junior to say “This error will rarely occur it is not worth introducing complexity to handle it.” They aren't the ones who will get called out to fix it when the 'unlikely error' inevitably crops up. In the case of DST twice a year for the 15+ year life of the app adds up. Edit: I'm sure someone will mention UTC - I agree better to use this if underlying DB supports it.

jamesmiller5 10y ago

> Perhaps you've ran into someone who is really as counterproductive as the article makes a Dungeon Master out to me, but I've never so feared for my job security, which seems to be the core reason provided for the Dungeon Master's behavior and position. I have and it's very scary indeed. I've heard "You will be fired if you don't support technology X" simply because that's the technology the DM used originally and is more familiar with. I'm not disagreeing with your other comments, but I think the authors main point boils down to when a DM's ego becomes tied to a system in need of replacing, the act of replacing said system can feel like a personal attack to that DM. If that developer is in a or has risen to a position of power it can feel even more intimidating to suggest other technologies. That being said, I've learned to expect such behavior. It's part of the job. A great skill to have is negotiating and communicating why the system needs to be replaced in such a way that the DM is collaborating and seeing the value the new system can produce. I'm going to work with people everyday that don't see or don't like how I'm trying to solve something and their concerns need to be addressed for us to continue working together.

pm 10y ago
BobX is the logical conclusion of said behaviour. http://thedailywtf.com/articles/We-Use-BobX http://thedailywtf.com/articles/We-Use-BobX

sbov 10y ago

I'm destined to be a "dungeon master" on a recent project, and would love to restart with an MVP. I had to fight tooth and nail to leave out features no one was going to use - some of which weren't cut. Project manager kept predicting we would be done in 1 month when we obviously had way more than 1 months worth of work. Ultimately we ended up developing our current version as if it was just 1 month from being done (cut some corners so we can hit the target!) for the majority of it's development time.

bigger_cheese 10y ago

Like you I think I've inadvertently become the "Dungeon Master". I don’t like maintaining a legacy app but if you’re going to replace this software the replacement better be an improvement. > 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 take issue with this quote as well. In my experience, I know about the traps because I've seen what happens when they get triggered and had to recover from them - often at great time and expense. Put another way traps are edge cases and like any system it's easy to account for 90% of the complexity it's the remaining 10% of edge cases that cause the headaches. When I hear a young developer say something like "We’ll just use a const and assume each day is 24 hours long because it simplifies the code immensely". When I then point out they’ve stumbled into a trap because their program will now fail catastrophically twice a year (daylight savings, when you have a 23 and 25 hour day). I’m not doing it to be a curmudgeonly dungeon master trying to protect my turf. I’m pointing it out because I’ve dealt with that pain when I got bitten by DST in the app I maintain. I was young once too. It’s easy for some junior to say “This error will rarely occur it is not worth introducing complexity to handle it.” They aren't the ones who will get called out to fix it when the 'unlikely error' inevitably crops up. In the case of DST twice a year for the 15+ year life of the app adds up. Edit: I'm sure someone will mention UTC - I agree better to use this if underlying DB supports it.