Seekeepeek wrote: ↑Wed Sep 18, 2019 5:14 am
Arelith class changes could need some more peer review before releasing the class concept to coding.
if nothing else then to protect the awesome code contributors, so they can receive their well earned kudos for their amazing coding work, rather then having to deal with the balance backlash that sometimes get personal on a uncomfortable and unfairly level.
This is something really important, and I've been planning to most a post on it for a while. I don't want anything I'm about to say sound like an attack on the team. I just want to give some insight that I've gained from working as a professional software developer (as I'm sure many of our devs have) about how updates go when they're good and when they're bad.
Having worked as a software developer for quite a few years now, the reality is that, whether the work is payed or voluntary, whether the client is paying you or some else is, or whatever other circumstances you can think of, bad or breaking updates will always reflect poorly not just on the dev who released them, but on the dev team as a whole, especially when those bad or breaking changes make it into production.
If I wrote a script to migrate data, and it didn't migrate the right data, or didn't put it in all the right places, they'd wonder why we didn't test the migration script more thoroughly. If we actually released the product that way, they'd wonder if we even tested it at all. If I wrote a reporting tool that didn't generate the right information, they'd wonder the same things, and wonder why we didn't talk to the subject matter experts and instead decided our understanding of it was complete.
Even if it was a volunteer project, the same thing would be true. Breaking and bad changes undermine confidence in the dev team, always. People can talk about how understanding they are that it's volunteer work, and work done for fun, but at the end of the day, when updates break things, especially in major ways, people will start to doubt the abilities of the team.
I've seen this happen to myself and teams I've worked on, and I've seen it on various Discord channels, especially when class changes are released. The Kensai debacle still gets talked about, and I'm sure Monk will too for a long time. Druid and Wild Mage gets brought up, Weave Master, Pale Master. Even Spellsword gets mentioned pretty often; they're in a good place now, but people don't forget this kind of stuff.
There's this idea among developers, volunteer and professional alike, that if they were just allowed more freedom to do what they wanted, they could release things perfectly. If they didn't have to go through the entire code review, QA, testing process, things would be smoother. It's never true, and never works out. Those processes are there not only to ensure everything is working, but to protect the devs and the team. They're there to make sure that bad updates don't get released, so that the team can work in peace, and don't have to deal with the distrust and anger of the clients.
I know there's this idea on the dev team here that less process is always better, but stuff like the ongoing (as we can all see, even after the fixes) harsh feedback and criticism proves otherwise. The original monk update was bad, and it's meant that Xerah and the dev team have been crucified multiple times for months now because of it. Is getting something out the door faster, with less process, really worth going through all that criticism? Is it worth eroding the trust of the playerbase in class updates?
Taking the time to go through QA, and a balance team, and making the necessary fixes months ago might have been irritating (it isn't fun to be told your ideas aren't working), but if this most recent monk update, or a similar one, would have been what was released originally, the players would have been singing praises to the dev team for making a great class update from the get-go, rather than the rather lukewarm "These changes were necessary because it was broken".
*Edited for typos