This is a pretty big misunderstanding of how products like DDB should work.
To be fair, the discussion isn't about how D&D Beyond
should work, but about how it
does work.
If you're sane, you essentially (and yes, I am dumbing this down a bit) build the building blocks you need, then you arrange them in the ways you need. And you have a team who can quickly add features, and those are unlikely to be wasted, because they tend to be possible to reuse later.
You're in the software development industry, yes? So am I. You should know as well as I do that a
lot of software development projects don't work like this (again, not talking about how they
should go, but how they
do go). It's not about sanity, it's about reality. The platform was built by a very, very small team essentially trying to get an MVP out, and then when that was shown to be promising, they did what a
lot of companies do... they continued to build out feature that people would need to actually use this as a full-fledged product
at the time because they needed to have something that people would actually pay for and subscribe to.
If you're really in the software development industry, you know that this is the way it goes
most of the time with
most companies. It's easy to talk about the optimal way to develop things when you have the luxury to actually be able to do that, when you have teams of engineers who are experienced enough to know the right way to build things
and business people who are willing to accommodate that. I'm fortunate enough to be at a company that understands this. I have not had that luxury for most of my very long career as a software engineer.
I had the pleasure of meeting some of the developers from D&D Beyond at the first PAX Unplugged. My big ask at the time (still is) was homebrew classes. I even dropped high-level suggestions of barebones ways they might be able to support it and said I'd even be happy if they could provide some sort of API that people who had developing chops could use to build our own features. The developer told me it was an interesting idea that they had discussed as a team, but there were like only three or four developers and they had too many must have features that they had to get out the door. I was not at all surprised by any portion of the nice conversation that we had, as disappointed as I was to hear it.
You say "Just spells and Feats would be fine", but no, actually you're demonstrably wrong.
Unearthed Arcana that
was "just spells and feats" actually would be fine for the most part, assuming they were spells and feats that didn't turn existing rules and mechanics on their head. Most of the UA in the past has really just been what you said earlier -- "just" data entry. The homebrew tools in place are what the team actually uses to implement many of the new objects in the system, so if it's something that you or I could
actually do ourselves in the homebrew framework, they could do it super easy... just need the time to do so.
The more recent stuff has been notably more than "just" data entry. Heck, even the stuff that was leading up to Tasha's was problematic because it required changes to the underlying framework. You're right that this falls on the poor design of that foundation, but, again, when you've got a team of like two or three people who built the MVP and then you have to choose between refactoring that architecture or investing in features that are actually going to get people to pay you money, you're going to choose those money making features 10 times out of 10, unless you have the luxury of working in a bigger company that can afford to accommodate delays to address tech debt.
What's particularly striking is that they've also avoided cheap "brute force" approaches (i.e. putting stuff in, in a format that isn't final but will work for now).
That's actually the strategy they
had to use early on as they built out their platform. The key difference being the outcome. In the situation we're particularly talking about right now, they would be investing valuable resources just getting "something" out there that they can't be reasonably confident will ever make it to "production" for the game. Plus, consider that the "time to production" seems to have gotten a lot shorter for UA as of late. We used to see UA sit there for at least six months if not close to a year before it would make it into a publication... and we wouldn't even necessarily know if it would make it into a publication until closer to publication date. The Strixhaven subclasses UA released at the beginning of June, the book is due out in November, and we already learned a few weeks ago that they nixed the whole idea. I don't know about you, but I'd be pretty ticked off if I pushed my team to work feverishly on a feature in June and then a month later it got nixed.
Maybe it would be different if D&D Beyond was actually owned by Wizards, in which case they would have gotten advanced notice of the UA, and Wizards themselves would have been able to tell them whether it made sense to build the feature out. As it is, they find out about these things when we do, and they have to then decide whether to dedicate resources to building out experimental features that are increasingly becoming more complex and potentially unlikely to make the final cut. It really doesn't make business sense to keep supporting UA with that trend, especially since it's used by a minority of players.
That can indicate one of three things - firstly, completely incompetent management - you can't rule it out!
Certainly a possibility. I mean, there must have been
some impetus for Adam looking for another gig and leaving the company he founded.
Secondly, it can mean that the actual proper solution is just around the corner - i.e. 3-6 months away or less. That's demonstrably not the case.
Definitely not. It's really as simple as "it just doesn't make sense to keep supporting experimental features."
Thirdly, extreme under-resourcing, which means even the minimal budget to basically data-entry this stuff (which they can do, hence them telling us to do it) isn't available.
They're definitely under-resourced — most projects are — and why would you even have your development team doing data entry? LOL
And why haven't they had the resources? Not because it's hard - it isn't.
I don't know where you've been, but finding development resources is
hard right now. It was hard before the pandemic, and it's much harder now, at least insofar as experienced developers are concerned. A lot of tech companies are going so far as to hire people for whom they don't even have roles established yet just so they can have the resource when they actually need them. As someone who has been knee deep in hiring for the better part of the year and working in a company owned by a major corporation that you almost certainly know, I can tell you without a shadow of a doubt that it is not easy to hire experienced engineering resources right now unless you work for one of FANG/FAANG/FAAMG (however they're grouped nowadays).
It's because they've taken their developers (and no, this is not like gaming where devs are ultra-specialized) and put them on projects like making glowing dice to sell to people,
I would be
really surprised if the team that worked on the actual platform itself were the ones creating animated dice.
or working on a VTT that's seen apparently zero progress but they've constantly claimed to have a bunch of devs on, and so on.
Who knows what sort of progress has been made on the VTT? I don't think either of us have anywhere near the insight into that project to be able to say whether it's progressing beyond naive conjecture.
You keep saying that it's just a data entry thing, but that's not the issue at all. (and part of the problem there is what you referred to... a rather poorly designed framework).
www.dndbeyond.com
