4E WotC, DDI, 4E, and Hasbro: Some History - Page 9
Page 9 of 11 FirstFirst 1234567891011 LastLast
Results 81 to 90 of 108
  1. #81
    Quote Originally Posted by xechnao View Post
    How much does software teams cost (a usual normal-a usual high)? Are they paid by month?
    Depends entiurely on the size of team and delivery contract. The two main methods of payment are time and materials basis (pay each month for the salaries and expenses -- customer eats cost overruns) and fixed price (developer eats costs overruns) with milestone payments (payments made upon reaching specific project delivery points).

    For new development with limited requirements and no code basis is almost certainly going to be T&M. No development shop will commit to a confirmed price and milestone payments model because of uncertainties outside their control.


    How much will T&M cost? This gets back to the size of the team. Typically, I see 20-30K per month on oversight (program/project management, architectural oversight, customer managment), plus development, documentation, and analysis salaries plus any internal salaries assigned to the project.

    Typical bill-out rates are 2x-4x employee salary so a documentation specialist may be billed at $80/hr and receive $30/hr. Senior people especially in solution architecture and development get charged out at in the low thousands per day.

    Depending on the engagement, spending over a million a month is notable, but not unheard of. Especially if the client wants it done fast; typically more bodies are thrown at the problem and paradoxically end up slowing the project down (everyone spends more communication and coordination).

  2. #82
    Join Date
    Dec 2007
    Location
    europe
    Posts
    2,224
    Christ. That's a lot of money...
    I wonder if they would or could ever recover these with their current revenue of DDI subscriptions (of course DDI would have its operational and developmental costs still for what we know it is still in beta and aspires to grow in functionality).

  3. #83
    That was a great read, and very informative, thank you for sharing.

    Adam

  4. #84
    Quote Originally Posted by Nagol View Post
    Depends entiurely on the size of team and delivery contract. The two main methods of payment are time and materials basis (pay each month for the salaries and expenses -- customer eats cost overruns) and fixed price (developer eats costs overruns) with milestone payments (payments made upon reaching specific project delivery points).
    Those are the main methods.
    In this situation you might get different terms (which could well be part of the problem)
    I don't know the details of the company spinoffs and what was going on but I wonder if it was launched because somebody important was a D&D fan and was eager to get in at any cost even though they hadn't got the experience in the area to get results.

    Quote Originally Posted by Nagol View Post
    For new development with limited requirements and no code basis is almost certainly going to be T&M. No development shop will commit to a confirmed price and milestone payments model because of uncertainties outside their control.

    How much will T&M cost? This gets back to the size of the team. Typically, I see 20-30K per month on oversight (program/project management, architectural oversight, customer managment), plus development, documentation, and analysis salaries plus any internal salaries assigned to the project.
    It varies a huge amount depending on project size and how the team works as to how much oversight etc is needed (traditional approaches have a much longer design phase than the current agile approaches for instance)

    I don't know what SolutionsIQ had done before (they're still around but seem to be more focused on consulting and training than development -> guess based on the website) but if they thought it was worth spinning off a new company for Gleemax and DDI then I suspect that the new development was in significantly different areas from where they'd worked before

    Quote Originally Posted by Nagol View Post
    Typical bill-out rates are 2x-4x employee salary so a documentation specialist may be billed at $80/hr and receive $30/hr. Senior people especially in solution architecture and development get charged out at in the low thousands per day.
    Rates vary a lot by market area, historically game development wages are typically a lot less than business application development

    Quote Originally Posted by Nagol View Post
    Depending on the engagement, spending over a million a month is notable, but not unheard of. Especially if the client wants it done fast; typically more bodies are thrown at the problem and paradoxically end up slowing the project down (everyone spends more communication and coordination).
    "The Mythical Man Month" - released in 1975. Sad that people are still making the same mistake over 30 years later -> as well as a whole heap of new ones being added to the pot.

    If Gleemax and DDI were paying enough to justify the cost of spinning off a new company I doubt it would be at the cheap end of the cost scale (It might also be a sign that there was a non-standard funding scheme where Radiant Machine was going to be getting some of the subscription money rather than being paid in a standard manner so that they were sharing the risk)

  5. #85
    Join Date
    Apr 2007
    Location
    Washington State
    Posts
    1,040
    Quote Originally Posted by GMforPowergamers View Post
    I know someone had some base number of subscribers for DDI, how close are they? I imagin board games and the Scyfy movie will help... but I wonder if ANY RPG company makes more then 30 mill...
    $30 mil just on TRPGs? no, not is in this day and age.

    But if you factor in miniatures, board games, novels, epub, distribution/ecom (like what Paizo does), video games, and other licensed products based on your TRPG property then you might have a chance at $30mm. Video games could push you into the $50-100MM level if you had a really big hit like a Skyrim, Dragon Age, KoTR, Infinity Blade etc.
    Last edited by Scott_Rouse; Saturday, 7th January, 2012 at 06:40 PM.

  6. #86
    Quote Originally Posted by Mad Hamish View Post

    <snip>

    Rates vary a lot by market area, historically game development wages are typically a lot less than business application development
    I am much more familiar with business application development costs, it is true. Though they'd probably be getting a bit of "it's geeky fun!" discount, probably not as much as seen on game development. I was trying to give xechnao a feel for the costs. The actual burn rate probably isn't known outside the financial group at WotC and how much internal cost got capitalised as well is also unknowable.

    WotC did and does have another networking/game arm in Magic so it would be my hope they could have tagged onto that group, but the internal politics are also beyond my ken. My business instincts are suggesting that wouldn't happen too easily since each brand is reporting separately and extra cost incurred on behalf a sister co. buys goodwill with the sister and hurts with the parent.

    "The Mythical Man Month" - released in 1975. Sad that people are still making the same mistake over 30 years later -> as well as a whole heap of new ones being added to the pot.
    Some fallacies never fall out of style. "Throw more people into the pit!" and "Sunk costs need protection!" are two I fight most frequently, still.

    If Gleemax and DDI were paying enough to justify the cost of spinning off a new company I doubt it would be at the cheap end of the cost scale (It might also be a sign that there was a non-standard funding scheme where Radiant Machine was going to be getting some of the subscription money rather than being paid in a standard manner so that they were sharing the risk)
    Yeah, there's a whole bunch of possibilities for setting up a separate companty ranging through protecting the parent from failure, alternative remuneration for key personnel, stakeholder differences, etc. that I don't find the secondary company too telling.

  7. #87
    Quote Originally Posted by Truename View Post
    This is my field. (Companies hire me to teach them how to organize and manage software development teams.)
    As a developer I'll add a few thoughts from the trenches (about 12 years in the trenches as a developer & tester).

    Quote Originally Posted by Truename View Post
    The biggest issue is that software is intangible. It's like the proverbial iceberg; for the 10% of the software you can see, there's 90% more required to make that work. And software development is a huge amount of work. Polished, complete products typically take 5 or more people working for months (at least) or years. Big products take much more than that.
    And a hell of a lot of the work is in areas that you won't predict unless you've worked on similar things before.

    Data storage, speed of retrieval, changed requirements causing redesign, discovering that the framework you were told to use doesn't do what you need it to... (convincing management that the framework doesn't do what you need it to)
    performance problems as use and data scale up...

    Quote Originally Posted by Truename View Post
    But nobody, not even programmers, are good at estimating how much work software development requires.
    There are a few different factors there.

    Commonly people are being asked to provide estimates on too big a task at a time or without enough detail. estimating (a+b+c+d+e) without a clear idea of what it should be doing. estimating a and estimating b... (although if you go too low a level you end up with estimates blowing out as well)


    There is always something that seems like it should be as easy as falling off a log that turns out to be as hard as log rolling through rapids with termites eating through the log and piranhas in the water.

    In most projects you're dealing with some new technology and it's extremely hard to judge how long that's going to take.

    Then there are just really stupid estimates and really bad approaches that cause terrible estimates. (I worked with somebody who was working on something he'd estimated as a 1/2 day problem for 3 weeks and was convinced all the way through that it was just a couple of hours away)

    Then there was another task on the same project that I'd had to take over which turned out to be way more complex than we'd though it would be because the person looking at it had missed some interactions with how the framework did database saving. I got it working but it took me a couple of weeks for a task that had been estimated at 1 day.

    A big thing is that if you pay attention to how your estimates actually turn out and learn from them for the next estimate but this doesn't seem to happen as often as it should.

    Quote Originally Posted by Truename View Post
    Remember, it's an iceberg. In one study, 90% of projects took longer than the programmers estimated, even though they updated their estimates as work progressed*. Half of them took more than twice as long. These results are typical.

    *http://www.toddlittleweb.com/Papers/...ncertainty.pdf
    It's extremely rare that a project comes in much under time or much under budget. I've managed it in a few small projects that I've done by myself.

    As I think somebody else has mentioned there are various things that you can (theoretically) control about the system
    - quality -> how well the system does the job, this could include be how good the interface looks, how fast things work, what's required to set it up ...
    - scope -> what the system actually does
    - cost -> how much moolah it takes to make
    - time -> how long it takes to develop it

    you can't control all of them and there are obviously limits (don't matter what you do it can't be done yesterday and it won't be free)

    Quote Originally Posted by Truename View Post
    So even the best-meaning software team has a good chance of taking more than twice as long as their good-faith estimate.
    Depends a lot what they're doing.
    If they're working with technologies they've used before with a reasonably specified system they should get pretty close.
    If dealing with new technologies or with a poor specification then you've got no hope. Of course specifications are hard and always change during projects so that commonly causes overruns itself.
    Scope creep is a big issue for most projects


    Quote Originally Posted by Truename View Post
    Now for the second-biggest issue. The people hiring software teams don't understand how costly and risky software development is. When they get a schedule estimate, they think of the 10% they can see, and respond, "How it could possibly take so long?" (Remember, this is a reaction to an estimate that's almost certainly too optimistic already.) And then they put pressure on the team to go faster.
    There's a lot of truth in that.


    Quote Originally Posted by Truename View Post
    Programmers respond to the pressure by cutting corners. Here's the thing, though. The way you cut corners in software development is to be sloppy in the way you design and write source code. But sloppiness creates bugs and makes the source code harder to understand. This is called "technical debt." The net result is that if you do this for more than a handful of weeks, you actually end up taking longer than you would have if you had just tried to keep things clean.
    I'm currently cleaning up another company's technical debt...

    _sometimes_ you can end with the opposite problem. Something might be good enough but people keep trying to improve it or come up with a better solution where it isn't needed.

    Quote Originally Posted by Truename View Post
    They also respond to the pressure by focusing on the 10% of the code you can see (such as the 3D VTT demo shown when 4e was released) and not the 90% required to make it work for real. This shows progress to the business folks, but creates unrealistic expectations about how long things will actually take.
    Terrible idea but can happen.

    Quote Originally Posted by Truename View Post
    So here's how honest, well-meaning people create software debacles. This happens all the frikkin' time.
    Yep.

    Quote Originally Posted by Truename View Post
    1. Company asks software team for some software, and asks how long it will take, so they can plan their budget, marketing, and so forth.
    Made worse when people put things out to tender, always with too little detail and massively unrealistic expectations.

    Quote Originally Posted by Truename View Post
    2. Software team creates an estimate that's 2-4x too low. They think they need 9 months and they actually need 2 years.
    I'd like to believe it's not that common that it's that far off but it's more likely the bigger the project is.

    Quote Originally Posted by Truename View Post
    3. Company flips out and says 9 months is too long and too expensive. "My nephew could do this in two weeks in his spare time." Demands that the software be done cheaper and quicker.
    yep

    Quote Originally Posted by Truename View Post
    4. Software team caves and says they'll be done sooner. After all, their estimate is just an educated guess; there's no proof, and maybe they actually will be done sooner.
    and then you have the pressure when things are sent out to tender as well or you are quoting on a an external project and management says they need the project

    Quote Originally Posted by Truename View Post
    5. Team works on the 10% people can see first, to establish good will and show progress. It's also the most fun part to write.
    Really bad idea

    Quote Originally Posted by Truename View Post
    6. Company is overjoyed at rapid progress and happily signs checks. "I knew they were sandbagging us with that nine-month estimate."
    ...

    Quote Originally Posted by Truename View Post
    7. Team starts working on the remaining 90%. Company starts pressuring for more results. "You've already shown us everything working, what's taking so long?" Checks signed less happily.
    yep.

    Quote Originally Posted by Truename View Post
    8. Team takes shortcuts, introduces bugs. Work slows down. Strings company along with increasingly desperate promises of progress.
    or decide to use this amazing new product/framework etc which will fix the problem.

    Quote Originally Posted by Truename View Post
    9. Company gets more and more impatient and eventually demands to see the actual software, not the demo they got over a year ago.
    always a good idea to keep them pretty much up to date with where things currently are.

    Quote Originally Posted by Truename View Post
    10. Actual software fails in a big, spectacular way. It's riddled with bugs, doesn't work on the public Internet, and completely fails to protect company's IP. Furthermore, the source code is so badly written it's pretty much impossible to recover.
    another classic problem is that it works with a low load but fails completely when the load is increased.

    Quote Originally Posted by Truename View Post
    11. Product is cancelled, team fired, and work starts over.
    And sometimes all the steps happen the same way...

    Quote Originally Posted by Truename View Post
    There are ways of preventing this; the set of approaches I use are called "Agile software development," but it's by no means easy and most software teams don't even know they don't know enough.
    or management won't accept the idea...

  8. #88
    Join Date
    Oct 2007
    Location
    Ringwood
    Posts
    4,219
    Quote Originally Posted by Truename View Post
    This is my field. (Companies hire me to teach them how to organize and manage software development teams.)
    I'm sorry but all I get from this is that it's the developers fault from go to woe.

    At the very start if they were more accurate (and honest, come on, 'good faith', yeah I don't buy that, they're underquoting to get the job...) almost all of the follow-on problems wouldn't even exist, let alone cause projects to collapse.

    And then they compound their own problems by being sloppy and throwing more people into the mix and being dishonest to their employer by showing them a false result so as to keep them happy and themselves employed.

    Honesty, right from the get-go, would solve almost all of the issues you presented.

    Some of what you say would put the blame on the companies employing these teams but when you look at it from a business perspective, they're not asking anything unreasonable. It's the responses that the developers make that turn this whole thing into a massive exercise in fail.

  9. #89
    Quote Originally Posted by Kzach View Post
    I'm sorry but all I get from this is that it's the developers fault from go to woe.

    ...

    Honesty, right from the get-go, would solve almost all of the issues you presented.
    Sorry, that sounds like armchair quarterbacking to me. I've presented a simplified view of the situation, so it's natural you would jump to a simplistic solution. But the reality is more complex and not so easily fixed.

    More honesty would help, to be sure. But it isn't sufficient on its own. Many software teams honestly believe in their estimates. Others present a more realistic schedule, only to be ignored or shouted down.

  10. #90
    Join Date
    Jan 2002
    Location
    Rio de Janeiro, Brasil
    Posts
    12,726
    Quote Originally Posted by Truename View Post
    Sorry, that sounds like armchair quarterbacking to me. I've presented a simplified view of the situation, so it's natural you would jump to a simplistic solution. But the reality is more complex and not so easily fixed.

    More honesty would help, to be sure. But it isn't sufficient on its own. Many software teams honestly believe in their estimates. Others present a more realistic schedule, only to be ignored or shouted down.
    These remind me of building contractors. Any estimate a contractor gives you, you double the time and money and then you get nearer to the actual end result.

Quick Reply Quick Reply

Similar Threads

  1. Why did Hasbro buy WotC
    By Gundark in forum *General Roleplaying Games Discussion
    Replies: 34
    Last Post: Sunday, 21st August, 2005, 07:02 AM
  2. Wizards, WOTC, and Hasbro, Inc.?
    By Tav_Behemoth in forum *General Roleplaying Games Discussion
    Replies: 27
    Last Post: Tuesday, 2nd November, 2004, 09:26 PM
  3. WotC before Hasbro. The way we were.
    By Bluemoon in forum *General Roleplaying Games Discussion
    Replies: 23
    Last Post: Sunday, 20th July, 2003, 10:43 AM
  4. Is WOTC/Hasbro mismanaging D&D?
    By Sir Edgar in forum *General Roleplaying Games Discussion
    Replies: 130
    Last Post: Wednesday, 18th September, 2002, 03:24 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •