OK, first off. I don't know anything about coding.

Secondly: I don't want to come across rude or ungrateful in any way.

Recently I wondered about the speed of development on ddb though. The new system has been coded over the last year or so and took a lot of resources as Adam pointed out in one of the dev updates but.

There are programs out there which are developed by single programmers and are cranking out new functional features on a weekly/monthly basis. (encounter+ or foundry vtt come to mind, not you roll20 you lazy bum)

A lot of features on ddb are still missing which I think are crucial for the future of the site as a whole (campaign managment, vtt, character organisation, AL integration, black and whitelisting of campaign books etc. etc.). A lot of these features are there but only in very, very basic capacity.

So my question is: What is the difference between developing ddb to lets say foundry vtt or encounterplus? Is it the number of users ddb has to cope with? Is the team still not big enough? Or is there so much work going in book releases (as Adam hs pointed out in one of the dev updates).

In short, can somebody explain where the difference in development speed comes from? I want to understand how that all works :)

Disclaimer: I have a master tier subscription on ddb, purchased the legendary bundle and I still use ddb on a daily basis and want nothing more than it being a success.

I think it is just the nature of reality that some dev teams are faster at putting out features than others. In my long experience with this as a user (not as a developer because I only do that a little bit professionally and only for tools that I and my research group use -- not ones that I sell to the public), this is often unrelated to how big the dev team is. There are tons of variables and I am not sure you will get an answer here. None of the users are going to have any insight into the development timelines and I doubt the devs will respond with anything satisfying.

I work in development with a lot of people who do personal projects as well, so I can maybe give you some insight into how the two different processes go (seeing as you drew a comparison between DDB and people making extensions and such).

Personal Project Developer

1. Comes up with an idea
2. Figures out how they would do idea
3. Writes code locally however they want as long as it works
4. Pushes it to personal github account
5. Makes a build
6. Does the thing
7. Yay, works
8. Someone asks for a feature/reports a bug
9. Repeat steps 3-7

When you're working on a personal project, you don't have to worry about time management, organising with other teams, logging hours, project deadlines etc. You don't have to have code reviews or gated evaluation or stick adhere to code policies. It's fast and loose and means you can churn out stuff a lot quicker, especially if you're working on a (relatively) small scope project such as an extension that modifies CSS script.

Industry Development

1. Team leads (production, design, development, art, etc) meet to layout how many tasks there are
2. Tasks get sorted by priority
3. Bugs get triaged (deciding which bugs need fixing right now, which ones later)
4. Production creates tasks
5. Tasks are assigned to team leads
6. Team leads assign tasks within their team
7. Developers/artists/etc do work, including bug fixes
8. Commit work to a development branch
9. Build is made from development branch
10. Build is sent to QA, who try and find as many of the bugs that may exist as they can
11. QA sends bugs to QA lead
12. QA lead sends bugs to be triaged (see step 3)
13. Once team leads are happy on build, a pull rest into the production branch is made
14. This pull request is usually reviewed to check that changes are within scope of the next release, evaluate risks etc
15. Production build is made and prepared for release

When you have dozens of people working on various areas of a piece of software; css, art, scripting, coding, whatever, you have to have a lot of careful checks and balances. You can't have one person throw in a fix that breaks another devs new feature. You need to ensure time is being focused on the priority tasks, which are usually the ones that increase or maintain revenue. This is because to fix those less profitable things, and add those small quality of life features, you need to keep things profitable and in the red, you need the lights on, the servers powered up and the devs paid. Code must be checked to ensure every dev is writing stuff in a similar way to everyone else, ensuring code is horizontally and vertically compatible, as well as future proof. Artists need to be coordinated to be exporting at the same resolution using the same file compression in the same colour space. When you have a project that consists of a team that needs to be paid, it needs to be managed. You need to do stuff like code refactoring where you look at the 16 libraries you have and realise they could be combined into 4 smaller libraries. Or remove a massive chunk of code that's called on page load that isn't needed any more. There's a lot of house keeping involved to ensure you don't end up hoarding code, so to speak. Stuff needs to be kept neat and tidy so that when you on board a new dev or artist, it doesn't take 3 months for them to learn what syntax style of file structure everyone uses.

Basically coordinating a large group of people on a big project requires more time and has a lot more background work. Even the simplest feature needs to be run by the producers and project managers to see if it's actually worth the person hours it'll take to implement. It then needs to be made into a series of tasks within a project so it can be tracked in case anything goes wrong. The work has to be done on branches in repos that have to be checked and merged and built and QA'd and sent back for bug fixes and checked and merged and built and QA'd again. 

Software development is hard work, something that a lot of hobbyist programmers don't realise. It's meetings and delegation and doing things because they'll make future things possible with no visible return now. When you also have to deliver new products and features, in addition to ensuring everything keeps ticking over, things move slow and cautiously.

You also need to consider how complexity increases the difficulty of things by an order of magnitude. You can't compare developing a standalone vtt to integrating a vtt into an already complex system of moving parts with a relatively large and active userbase. Everything on the site would need to hook into the vtt - not just character sheets but campaign settings, the encounter tool, combat tracker, custom things, etc. It's a huge undertaking.

Furthermore, they need to keep up with new content. As I understand it, integrating things like the UA Alternate Class options (and I think some options from the upcoming Theros book?) has required a massive overhaul of the existing codebase - basically rewriting much of the core software from scratch. This also is an immensely complex and inevitably frustrating task, but once it's done it should facilitate getting out new features much faster.

A small team is very agile. It also often consists of a few very driven individuals who work on a schedule that is unsustainable for a multi-year project. As you grow and your initial dream becomes reality, the enthusiasm fades a bit and you need to account for all the stuff Dave mentioned above. Your pace becomes the speed of the slowest link. It's just an unavoidable consequence of growth and success.

thx for all the answers. Even if I don't like it that it really has to take so long :)