The biggest issue with the new Character Builder:

[Truename]

To be clear, the alternative to not being able to do a work breakdown structure is not being willing to do a work breakdown structure.

There are legitimate, successful approaches to software development that don't involve a work breakdown structure.

I'm not defending WotC's software development approach, which does appear dysfunctional, and I'm one of those that has let his subscription lapse. But you're drawing conclusions from insufficient data, based on a narrowly-specific view of software development. It's unbecoming. Particularly the character assassination part.

 

[Lokiare]

This is getting ridiculous. How long before someone starts checking WotC staff credit records?

Good idea!

 

[Lokiare]

There are legitimate, successful approaches to software development that don't involve a work breakdown structure.

I'm not defending WotC's software development approach, which does appear dysfunctional, and I'm one of those that has let his subscription lapse. But you're drawing conclusions from insufficient data, based on a narrowly-specific view of software development. It's unbecoming. Particularly the character assassination part.

Are you serious? can you name a few? Without a WBS you can't readily estimate how much time it will take to work on a project, you also can't tell when you need to re-allocate resources to get a part that is lagging behind up to schedule.

One of the things this points to is that they used one of the so-called "agile" programming methods. Which pretty much allow the developers to break rules and make judgement calls which can throw a project wildly off track and behind schedule.

 

[TheClone]

Everything is blatantly obvious when you only base it on one portion of the story.

You are right. But we do not get any message from "the other side". WotC is again leaving us in total darkness (maybe they are drow?) and is revealing absolutely nothing voluntarily. So we are up to speculation at some point and it's the only thing we can do to release your anger. So maybe WotC is learning soem day that PR is not only about saying nothing and releasing crude products but about dialog with the customer? Then we can see both sides of the story and understand why things are they way they are. This will happen most likely. It will only not happen if the problems their digital products have are really based on severe mistakes on side of WotC and the digital studios. And if that is true the anger will never stop and is more than understandable.

 

[Truename]

Are you serious? can you name a few? Without a WBS you can't readily estimate how much time it will take to work on a project, you also can't tell when you need to re-allocate resources to get a part that is lagging behind up to schedule.

I don't come here to argue about software methods, but this is my area of expertise as an author and international speaker. In a nutshell, there are many ways to estimate.

• For traditional phase-based projects, McConnell's Software Estimation describes many ways of estimating projects without using a WBS.

• Some Lean and Kanban variants use "Disney-line planning," in which they measure the average amount of time it takes to finish a single feature, then extrapolate a "it will take you xx days to finish items at this point in the queue" estimate.

• And Scrum and XP (two examples of the Agile methods that you dismiss so readily) predict release dates by estimating stories and comparing the total in the team's backlog to the team's measured velocity. The more sophisticated teams adjust their predictions for risk and revise the scope of their projects every week so they can hit a predetermined release date.

This doesn't even get to the heart of the issue, which is that hitting predefined scope/date targets is tangential to shipping successful software, but I'll stop here since we're way off topic as it is.

 

[Lokiare]

I don't come here to argue about software methods, but this is my area of expertise as an author and international speaker. In a nutshell, there are many ways to estimate.

• For traditional phase-based projects, McConnell's Software Estimation describes many ways of estimating projects without using a WBS.

Well since I don't have access to that book can you summarize a few of the methods mentioned?

• Some Lean and Kanban variants use "Disney-line planning," in which they measure the average amount of time it takes to finish a single feature, then extrapolate a "it will take you xx days to finish items at this point in the queue" estimate.

Since features differ in scope and time this method would yield variable numbers that wouldn't match the actual time needed. A work break down structure breaks the work down to its smallest part and then allows you to estimate each part, when added up they give you a very accurate view of how long it will take.

• And Scrum and XP (two examples of the Agile methods that you dismiss so readily) predict release dates by estimating stories and comparing the total in the team's backlog to the team's measured velocity. The more sophisticated teams adjust their predictions for risk and revise the scope of their projects every week so they can hit a predetermined release date.

Estimating stories? seriously? for this to be even remotely accurate they'd have to compare projects and assignments that were almost exactly the same in scope and time to find out how long it would take. This would be really inaccurate. Updating predictions is not a planning model, it is part of the process of working in a team/project environment (if your smart). They can still update a WBS every week, so basically that part doesn't change anything.

This doesn't even get to the heart of the issue, which is that hitting predefined scope/date targets is tangential to shipping successful software, but I'll stop here since we're way off topic as it is.

The heart of the issue? It is not tangential to shipping successful software. It is essential! unless of course the management doesn't care if they have to work their developers 24/7 for the last few weeks to try to hit a deadline because the project wasn't properly planned and the developers abandoned tried and true methods to try a shortcut that then turned out to be a long cut...

To summarize my point: When using an agile method an exceptional group of developers can put out decent software on time. A standard group will invariably fail. Using a factory method both the exceptional group and the standard group will put out decent software on time.

I'm also not insulting "agile" development. It has its place. Things that need to be out in a short time, that will never need updates should use "agile" development. As far as the software WotC is developing is concerned they will constantly have to update the rules system and add new ways of doing things as long as they keep putting out new books, so a factory model would be a much better way in the long run...

 

[Oldtimer]

When using an agile method an exceptional group of developers can put out decent software on time. A standard group will invariably fail. Using a factory method both the exceptional group and the standard group will put out decent software on time.

This is simply, in my experience, untrue.

I'm also not insulting "agile" development. It has its place. Things that need to be out in a short time, that will never need updates should use "agile" development. As far as the software WotC is developing is concerned they will constantly have to update the rules system and add new ways of doing things as long as they keep putting out new books, so a factory model would be a much better way in the long run...

I think you are confusing Agile methods with that ninties fad called Rapid Application Development. Agile is actually much more suited for a system in heavy flux than a more traditional Water Fall method.