That was too long ago, and there are completely different people working on the VTT now.
Because company culture is just the people currently working on a project?
Ya, no. Company culture outlasts the current people implementing it, and changing it isn't as simple as a round of employee turnover over a decade.
Regardless, I'm talking about the complexity of an IT project. The idea that it is guaranteed that you can make a character builder that doesn't suck is ridiculous, because we've seen it done and we've seen it failed. And same with a VTT - we have a company of basically the same size, try and fail to make a VTT - this same company, a short while ago.
Am I proving that this VTT will fail?
I am not trying to prove that.
Fine, so they failed last time, you taking this as an indicator for the current development team is still worse than saying we have no track record, because of the above, but hey, knock yourself out
No, I'm saying it is unreasonable to assume success. I'm the one saying 50-50 - a toss up, failure or success -- and you are objecting to that estimate rate of failure is too high. You seem to want to assume success as nearly guaranteed or something.
Alternatively, you are talking my claims that success isn't guaranteed as if my position is failure is guaranteed?
Who knows, I don't.
I just think that most IT projects fail, are significantly overbudget, and/or produce something that sucks, and this holds across most industries and over most kinds of companies who try to implement IT projects. So given an IT project, there is a better than 50-50 chance it will be overbudget, fail or suck. And that WotC isn't magically immune to it, as evidenced by its past failures in exactly the same area.
You might think that this new iteration (tm) would be magically immune to that? Or that most IT projects don't fail, aren't significantly overbudget, and don't produce something that sucks? I'm really not sure what you are objecting to here. It appears to be whatever I'm saying, however.
if that were the general rule, we would not have any. What is baked into the plan is a buffer, just like there is when you e.g. build a house or a bridge, etc.
No. The general rule is that they fail, so you bake into the project graceful exits and backup plans.
A buffer just means you are over-committing - you are saying "well, this project might not work, and if it doesn't we'll just throw more resources at it". That handles like 1 of the 3 common IT failure modes, and makes the other 2 failure modes worse.
When implementing an IT project you aren't copy/pasting an existing design on a new spot like most houses; you are designing a new kind of house. This is because on a computer you can literally clone an existing solution - there is no
project to exist as an IT project if an existing solution solves your problem. (If you can't clone a solution that already exists for whatever reason, then the mechanism of cloning
itself becomes the IT project)
By making "duplicating what has already been solved" trivial, information technology ensures that projects do not consist of "duplicating what has already been solved". In the world of IT, once you have built the first suspension bridge, you can copy-paste it over every river that it can cross. So installing the suspension bridge becomes about how it interacts with the ground. Once you have solved how the suspension bridge interacts with certain kinds of ground, you get free copy-paste of that bridge on all ground that matches your solution.
Which means anywhere else you want to build that "IT suspension bridge", the ground where you want to put it
by definition has some problem that doesn't match the existing solutions; if that wasn't true, the bridge would have already been installed and you wouldn't be talking about the project.
So your project has to build up a new theory of how the pre-made pieces will interact with the unique local demands. Then you have to iron out all of the details that this new theory glosses over. In doing so, you could learn that your new theory is garbage. If your plan is to just have a resource buffer, you solve this by throwing more resources at the problem -- which does nothing, because what you are doing is the wrong thing to solve the problem.
Instead you have to plan for failure. You come up with the new theory, and a plan for both implementing it, and a plan for detecting failure, and a plan for backing out and abandoning the project. That last plan could involve intermediate milestones that deliver value even if the entire project will fail (to reduce potential losses), and making those intermediate milestones start as soon as possible (both as a means of detecting failure (if they don't appear as planned, then this is a red flag) and to reduce risk.
Things can still go well. Everything might work out as planned. You can even end up coming in under budget!
But you should
plan for failure while you aim for success.
I said you can do due diligence. I didn't say you have to.
"Look, some idiot did something stupid, thus there is no hope of doing it right" is funny.
yeah, that is not what it is. Many of the things you need for a DDB clone have been done time and again. It's basically a remote database with a web frontend that needs to scale decently, there are many of those out there. You are not inventing something radically new here, hire someone with the right experience.
Ok, you again seem to be saying that I am saying that making a character creator is impossible.
I am not saying that. I'm saying that most attempts will fail, will be significantly over budget, or produce something that sucks.
And it isn't "basically a remote database with a web frontend" except in incorrectly over-simplified way that would describe everything, from the entire world financial industry to being "a remote database with a web frontend", wikipedia is a "remote database with a web frontend", expedia is a "remote database with a webfrontend" a bank is a "remote database with a web frontend" a hospital medical records tracker is a "remote database with a web frontend" a car share service is a "remote database with a web frontend" and ...
Heck - if you removed the entire "store character" portion from a character creator and just left the character creator, what you have in your sense is "a web frontend". As you can literally run any desktop software in a browser today, you just reduced every piece of desktop software to being "a web frontend", which (according to you) can be solved in a near-guaranteed manner simply by hiring a single someone with the right experience.
I just boggle.
Yes, there are many character creators. Many of them suck. Oh god, so many of them suck horribly. You never hear about them because nobody shares them and they don't get well known. The ones you know about are the cream of the crop, of thousands of people creating character creators and the 0.1% that are the best being shared around. Then people clone features off the better ones, and thousands of people again make iterative clones, of which 99%+ suck and are never seen by most people.
Looking at the roll20 or DDB code itself, it is full of these little hacks and crap that nobody designing a character creator de novo would ever insert into their design. It has iteratively replaced features that didn't work out. It has conventions for creating new features that didn't work, iterated upon until they did. It has bugs that have been ironed over.
It also has compromises that are far from guaranteed to be ideal.
Like, imagine a character that is a merkle tree of the character's build history, with information about invalid state being part of the tree, and each node being an applied change. Or a chain of appied changes being the core of the character, the results being at best cached output. This is a fundamentally different one than a character that is a character sheet, like literally what is written down on the paper, with rules to auto-fill some areas and rectify and fix errors. Alternatively, the character could be an abstract set of attributes which is rendered into a character sheet. I'd bet dollars to donuts that all 3 of these have been used in a character builder before, and they all have tradeoffs and limitations. (with all of these I can tell you what neat stuff you could do that would be hard with the alternatives).
And the rules system! The rules system is dynamic - naive implementations are going to presume that the rules that define what a character is aren't. Do you have characters that exist in a given (possibly no longer valid) rules system and mechanisms to update them? Do you update chracaters as the rules change? How do you represent the rules in a way that handles iterative change of the rules against static character sheets?
You might reduce this to "hire the right person" - the right person being someone who already solved it and get them to duplicate what they did in the exact same way? Or do you get them to be creative and solve it in the new way that they couldn't do at the last job they had, solving problems that bugged them there?
And all of this is still the "web frontend" part of the problem; I don't think it is a good idea to have all of this logic be handled on the server, as that leads to needless overhead. On the other hand, we do need to validate stuff; we don't want illegal characters to be in the database, do we? So do we actually implement everything on the server, all of the game logic, and just provide a web gui?
I'm up to at least a million different plausible designs for this in a 15 minute brainstorm. I'm betting most of them wouldn't scale right, and if you committed to the wrong one "with a buffer" you could easily end up throwing good money after bad at a variant that won't actually work when finished. Practically the only way to figure out which of these isn't going to work at a fundamental way is to try it - so now we are going to reverse engineer DDB and a dozen other character creators, and maybe clone the best one. Is that what you mean by the right person with the right skills?
My point is that IT projects can be glibly described in a way that hides infinite complexity. And if it is an actual project, that complexity hidden is where the actual work and risk is. The glib description is nonsense marketing you can use to sell it to decision makers who aren't actually qualified to know if the solution will work, it isn't the information you need to know if it works.
Let's try something else. They are implementing a VTT. Do you agree that VTTs are more complex that what DDB is? Do you agree that if WotC can pull that off (which is still tbd), they could have created a DDB of their own as well?
I think their VTT, even at this late stage, has under a 50% chance of not sucking, not blowing its budget hugely or launching.
And I think they could have created a DDB character builder. Their attempt would also have had under a 50% chance of not sucking, not blowing its budget hugely, or launching.
Again, I'm not saying these things are impossible. I'm saying they are deceptively hard.
I mean, other than baking in "something will happen that makes our plans useless, so plan for that".
