What I have learned by dealing with a dungeon master
3 likes343 views
The document discusses the "Dungeon Master" anti-pattern, where an original developer of legacy software becomes entrenched and resistant to change. A Dungeon Master gives too much unnecessary information, focuses on implementation details, and gets defensive when new ideas are proposed. Attempts to work around the Dungeon Master by bypassing them or slowly introducing changes can help. Identifying surrounding anti-patterns like intellectual violence or irrational management is also important. The document advocates questioning the status quo to help identify issues and empower the team.
What I have learned by dealing with a dungeon master
- 1. What I have learned by dealing with a DM Ra炭l Araya @nubeiro Illustrations by Carlos G叩ndara @xoubaman
- 3. Who am I? Currently Backend Tech Lead at Previously worked on 鍖ntech, ecommerce, classi鍖ed ads, and computational linguistics
- 4. Goals Identify the DM anti-pattern Share what has worked and what has not worked when working with a DM Explore how the DM might appear together with other Software Management anti-patterns
- 5. What is a Dungeon Master? In The rise and fall of the Dungeon Master, Alberto Brandolini de鍖nes it as an antipattern.
- 6. author of the original software, that used to support the business in the early days, and still does. entrenched with the software, he knows the software better than anyone else. whenever there's a problem, he's the one to talk to. usually surrounded by minions. What is a Dungeon Master?
- 7. How is a DM born? maybe he built the system? maybe he was the one adding features to a legacy system? maybe $boss->promotes() someone?
- 8. Types of DM Product owner Tech lead Project manager Domain expert Software developer
- 9. How can we identify a DM? DM gives too much information. Mixes domain knowledge and his own interpretation. Will get defensive or resistant to change when somebody gives new ideas. Sometimes will focus too much on implementation details.
- 10. in a rewrite of the original system. in a legacy system being refactored. Where do we 鍖nd a DM?
- 11. DM in a rewrite
- 12. DM in a rewrite Brandolini mentions 3 possible outcomes for the rewrite: new project is much better than its predecessors. This will expose how bad the legacy software was and how much money it was lost in keeping it alive longer than needed. new project is slightly better than legacy. This will raise the question was it really necessary to rewrite the software, for so little advantage? new project fails. Best option for DM. Nobody could be better than he did.
- 13. Lets imagine a scenario
- 14. 14
- 15. Lets imagine a scenario What follows is an account of my own experience. Take it as a description, not as a judgement.
- 16. Lets imagine a scenario Company has no active developers hired No testing culture. No DevOps culture. const DUNGEON_MASTER = $boss; Legacy system
- 17. Legacy as in No tests Old deprecated version of the language being used Big Ball of Mud (TM) Monolithic repo
- 18. Lets add some pressure DM in command, I want this: Now / In 5 / Today / By tonight / Tomorrow Failing involves big losses for company
- 19. In to the 逮看顎姻稼艶霞
- 20. What did not work Suggesting infrastructure changes upfront DB migration after 1 year. Suggesting tooling / delivery changes upfront Deployment system changed after 6 months Working CI after 1 year.
- 21. What did not work
- 22. What did not work Cowboy coders Surgeons Rockstars / Prima Donnas
- 23. What did not work Cowboy Coder: Cowboy Coders are programmers who write code according to their own rules. http://wiki.c2.com/?CowboyCoder
- 24. What did not work Surgeon coder: The "surgeon" on the team is the rockstar programmer. The one with 10x (or more!) speed, skill, and ability than the average team member. The Mythical Man-Month: Essays on Software Engineering, Fred Brooks
- 25. What did not work Rockstar / prima donna coder: If by rock star, you mean someone that parties all night, comes in late and hungover, has weird contractual demands, and trashes hotel rooms on business trips, then yes, I guess I'm a rock star. https://news.ycombinator.com/item?id=1757402
- 26. What did not work By the time a cowboy/surgeon/rockstar/prima donna would 鍖nish, a thorough review would pinpoint: forgotten requirements newly introduced bugs knowledge silos
- 27. What did not work Extracting domain logic from implementation Like having someone explain to you LoTR the movie and then pretending you read the books. Most times implementation would be buggy or simply wrong (according to business).
- 28. What did not work Pretending is a technology problem When new projects moved to newest versions language in use, other anti-patterns would raise. Think money 鍖rst Nope. In my case, that is what got us there.
- 29. What did not work Make them part of the new team old ways and dark side were never gone. Separate paths No way (we卒ll revisit this when we discuss about other anti-patterns).
- 30. What seemed to help Bypass the DM It sort of worked, but also lead to discovery of other anti-patterns. We still needed a huge deal of collaboration.
- 31. What seemed to help Slow architectural changes While adding new features, introduce tools (CI, automated deployments) and libraries (autoloading, own framework ) that will speed development in the future.
- 32. What seemed to help Performing surgery Sometimes having a surgeon and then having the surgery procedure explained to the team was acceptable.
- 33. What seemed to help Questioning status quo (i.e relentlessly asking WHY). This proved most bene鍖cial, since it helped us realise where code was telling lies (DM would realise that there were wrong implementations never tested, never questioned).
- 34. What seemed to help Using implementation to challenge domain knowledge Sometimes DM would explain a story about what was going on in a speci鍖c area. Implementation would sometimes prove DM wrong, some other times DM would 鍖ag it as an error in implementation.
- 35. What seemed to help Understanding business needs Only when you understand business we started being regarded as peers by the DM Acquiring domain knowledge helped when facing feudal disputes.
- 36. How a DM affects a team
- 37. How a DM affects a team Adds confusion, too much information Since DM needs to be involved in every major change, team does not feel empowered to take own decisions Sometimes would become a surgery blocker (by giving misdirections on best short term solution).
- 38. How I became a DM When you spend enough time in a project you will: learn where the traps are, even unset some of them not remember to unset them all Easily start making assumptions on what is general knowledge and what is not Perform surgeries yourself
- 39. How I became a DM All of the sudden you 鍖nd yourself doing the following: Giving too many details about surrounding problems when you should be focusing in just one thing() Explaining workarounds Trying to protect new team players from traps you have not unset yet
- 40. How I realised I was a DM A new member in our team started asking questions: Why? How? Really, why? Is this important now?
- 41. Is DM an isolated anti-pattern? In my own experience it is not. What follows is a list of anti- patterns that Ive seen in the wild. Intellectual Violence: using knowledge to intimidate others in a meeting. Irrational Management: indecisiveness and other bad management habits lead to de facto decisions and chronic development crises. Blowhard Jamboree: opinions of so-called industry experts often in鍖uence technology decisions. From: Alexander Shvets. AntiPatterns: The Survival Guide.
- 42. Take aways / references The Dungeon Master is a complex anti-pattern. Might be surrounded by other project management anti-patterns. Identifying it and giving it a name might help you deal with it. The rise and fall of the Dungeon Master, Alberto Brandolini. Antipatterns, the Survival Guide, Alexander Shvets.
- 43. Thank you Please rate the talk at http://bit.ly/rate-scbcn If you liked the illustrations: tweet @xoubaman and let him know.