Quote from: StormBringer;559694It seems like no one wants to invest in updating their software infrastructure.

Those ROI calculations are nowhere near as simple as you might think.

Quote from: StormBringer;559694It seems like no one wants to invest in updating their software infrastructure.  I would not be surprised in the least if the virtual table was ultimately held up because of some Java incompatibility issue, because they are using a much earlier version.  Rather than looking a bit ahead and building a Flash application and now trying to implement something in HTML5, they will stick with the ancient, creaky technologies that were barely sufficient for the tasks to which they were put 20yrs ago when they first came out.

Nice segue; I really didn't think you'd manage it.

Quote from: daniel_ream;559718Those ROI calculations are nowhere near as simple as you might think.

No, I would imagine not.  Banks aren't still using COBOL because they are lazy, obviously.  But for smaller organizations, the switchover doesn't seem terribly onerous.  And Microsoft would be more than happy to help, I am sure.  I tend to place these decisions into more of a 'tech blind spot' than anything, with managers having no clear idea what benefits and upgrade provides, only seeing the overall cost.  As long as they get their numbers, they don't really care how.

Quote from: Bobloblah;559735Nice segue; I really didn't think you'd manage it.

:hatsoff:

Quote from: Bobloblah;559735Nice segue; I really didn't think you'd manage it.

:hatsoff:

Quote from: StormBringer;559742No, I would imagine not.  Banks aren't still using COBOL because they are lazy, obviously.  But for smaller organizations, the switchover doesn't seem terribly onerous.  And Microsoft would be more than happy to help, I am sure.

The tech industry suffers from fads the same way the fashion industry does, and software engineering as a discipline is still in its infancy.  If a company, large or small, is entirely dependent on their IT infrastructure, then changing it needs to be seamless and cheap (or at least worth the investment given the projected lifetime of the new system).

Realistically, it's almost never either.

(Aside: Microsoft is not, in fact, happy to help; they don't do consulting.  They'll refer you to a local VAR).

Quote from: daniel_ream;559751(Aside: Microsoft is not, in fact, happy to help; they don't do consulting.  They'll refer you to a local VAR).

Actually they do provide combined consulting/training, for example, Sharepoint for the Cal State system, but it has to be a big project.

Quote from: CRKrueger;559753Actually they do provide combined consulting/training, for example, Sharepoint for the Cal State system, but it has to be a big project.

I was going to make a similar response about them dealing directly with software OEMs. So, yeah, they do, and a lot. You just have to be worth their time. And this is still fairly off-topic for the VTT.

Quote from: daniel_ream;559751The tech industry suffers from fads the same way the fashion industry does, and software engineering as a discipline is still in its infancy.

I'm looking at you, Java.  

QuoteIf a company, large or small, is entirely dependent on their IT infrastructure, then changing it needs to be seamless and cheap (or at least worth the investment given the projected lifetime of the new system).

It's likely not an easy argument to make, but ease of maintenance should be factored in there somewhere.  Having to find one of the handful of COBOL programmers out there and pay them blackmail money has got to be far less attractive than setting up an off-the-shelf commercial database like MSSQL or Oracle or something.

Quote(Aside: Microsoft is not, in fact, happy to help; they don't do consulting.  They'll refer you to a local VAR).

Well, yeah, not the heavy lifting part.  Getting their hooks into the banking industry's software, though?  Balmer has got to be messing his pants over the thoughts of that.

Quote from: Bobloblah;559755I was going to make a similar response about them dealing directly with software OEMs. So, yeah, they do, and a lot. You just have to be worth their time. And this is still fairly off-topic for the VTT.

Not entirely.  There are plenty of ways to get technology implemented, although it may not be as inexpensive as the bean counters like.  It feels like WotC (and TSR before them) just went with whoever called them first without looking around.  The independent programmers making their own virtual tables attests to that.

There is some degree of inertia behind still having COBOL on minis in the banking world, but part of it is also that they haven't had the cost for maintenance exceed the projected costs for upgrade yet.  Gods know why not, IBM must be charging them out the ass for maintenance contracts.  But WotC doesn't have (literally) tons of legacy hardware to worry about.  Console games cost tens of millions to produce, but as I understand it, most of those costs are on art assets like cut-scenes and voice over work.  The actual game engines are not what generally pushes the ship date back.

Quote from: daniel_ream;559751The tech industry suffers from fads the same way the fashion industry does, and software engineering as a discipline is still in its infancy.  If a company, large or small, is entirely dependent on their IT infrastructure, then changing it needs to be seamless and cheap (or at least worth the investment given the projected lifetime of the new system).

Realistically, it's almost never either.

(Aside: Microsoft is not, in fact, happy to help; they don't do consulting.  They'll refer you to a local VAR).

I have to agree with Daniel. Pretty much every job I've had over the last 15+ years has involved trying to upgrade from one technology paradigm to a new one. They have all taken 4x or longer than originally estimated, cost at least twice as much as originally estimated, and always have a huge productivity/usability loss that lasts years after the changeover. 50% of them failed completely (meaning those guys are still using the old technology they were trying to get away from years ago).

My current gig involves a transition of our CRM software from an old AS/400 system to a Windows/Browser-based VB.NET system. It took 4 years just to go live and that's with some huge productivity/usability losses. From a productivity/usability standpoint, it will be another 2+ years before we get back to where we were in 2008.


That said, WotC has no hope if they can't create digital products. It is the future. The future for selling ever-diminishing returns of yet-another-edition of expensive print books is rapidly running out.

So basically, their options are to either keep doing what they are doing and squeak out a few more years, or convince Hasbro to make a huge investment and spend the next several years working on digital products (either by investing in in-house talent or outsourcing to consultants).

Quote from: StormBringer;559694It seems like no one wants to invest in updating their software infrastructure.  I would not be surprised in the least if the virtual table was ultimately held up because of some Java incompatibility issue, because they are using a much earlier version.  Rather than looking a bit ahead and building a Flash application and now trying to implement something in HTML5, they will stick with the ancient, creaky technologies that were barely sufficient for the tasks to which they were put 20yrs ago when they first came out.

What people don't realize that installed and running software represent captured knowledge. Particularly in Vertical markets like the one being mentioned in earlier post.

A rewrite is something you do as a last resort and only when the payoff is many times the amount invested in the work. It because once you rewrite software everything is out the window in terms of reliability.

Obviously you can't sit still so what you do is refactor your software. You first write a test framework that verifies your software is operating correctly. You run this framework after every change is committed using your pre-existing setup. Note you haven't done anything new with the current system other than your normal maintenance cycle.

Once you have that working you can then start altering your system to a new design. Doing it in logical increment and running your test framework after every change.  If you do this then the project will be left in a working state after every change. So when shit happens, and it always does with legacy system, you not left with your pants down.

I successfully maintained a CAD/CAM metal cutting software since the mid-80s by following this philosophy. It started on a 68000 based HP Workstation, went to MS-DOS, then Windows 3.X, then to Windows 32-bit and now in the midst of going over to .net.

Quote from: StormBringer;559756Having to find one of the handful of COBOL programmers out there and pay them blackmail money has got to be far less attractive than setting up an off-the-shelf commercial database like MSSQL or Oracle or something.

I'm not exaggerating in the slightest when I say that the latter will be orders of magnitude more expensive than the former.

Back to the topic at hand, outsourcing the VTT project probably would have been the right way to go if WotC had no in-house expertise at managing software projects.  Realistically, projects like that rarely have more than a handful of people working on them and the loss of a single major contributor will always tank the project.  Look at what happened with reiserfs.

Quote from: daniel_ream;559774I'm not exaggerating in the slightest when I say that the latter will be orders of magnitude more expensive than the former.

No, I get it.  Initial costs are going to be high.  But will they be that much higher than, say, fifty more years of using COBOL?

Quote from: estar;559771What people don't realize that installed and running software represent captured knowledge. Particularly in Vertical markets like the one being mentioned in earlier post.

Yeah, that makes sense, but you could also call that captured data, right?  Data is pretty easy to transfer around.  Building the program structure around it again, well...  That's not going to be simple.

A rewrite is something you do as a last resort and only when the payoff is many times the amount invested in the work. It because once you rewrite software everything is out the window in terms of reliability.

QuoteObviously you can't sit still so what you do is refactor your software. You first write a test framework that verifies your software is operating correctly. You run this framework after every change is committed using your pre-existing setup. Note you haven't done anything new with the current system other than your normal maintenance cycle.

Once you have that working you can then start altering your system to a new design. Doing it in logical increment and running your test framework after every change.  If you do this then the project will be left in a working state after every change. So when shit happens, and it always does with legacy system, you not left with your pants down.

I successfully maintained a CAD/CAM metal cutting software since the mid-80s by following this philosophy. It started on a 68000 based HP Workstation, went to MS-DOS, then Windows 3.X, then to Windows 32-bit and now in the midst of going over to .net.

That's the kind of plan I was referring to.  At this point, the financial industry has passed up so many opportunities for incremental upgrades, their only choice is a hugely expensive re-write.  They can't justify that cost, and there are no incremental changes because the software is so old, they are stuck with the inertia of having to use the original software.

WotC doesn't actually have that problem, however.  Whatever happened with the most recent virtual table, they were starting from scratch, and so could have picked whatever technology they wanted.  They appear to have chosen poorly, along with the contractors who were writing it.  That is the part that is really baffling.  Tech companies are stuffed with rpg enthusiasts, because that was the hobby when programming was getting into full swing.  How do they manage to keep finding the ones that don't seem to have the first clue about rpgs?  Hell, buy one of the current independent VTTs and keep them on as programmers.  Or get some new folks, as the current offerings are largely open source anyway.

Quote from: StormBringer;559683I guess the puzzler for me is why a large-ish company like WotC with presumably decent resources behind them from Hasbro can't get their shit together for a virtual table.  Back in the TSR days, when computers were still carved of a piece from oak trees, it is more understandable.  But they still managed to put out the Core Rules CD and the Dragon Archive CD.  Both of which are far, far superior to anything they have done since.  Hell, the character generator that came with the first printing of the 3.0 PH should have been a no-brainer, but they fucked that up, too.

Excuse me, TSR did put out a decent electronic gaming tool: the Dungeon Masters Assistant Vols. 1 & 2, done by Jim Ward and a handful of guys from SSI.  Covered every OS you could buy for a computer at the time, ran on everything from a vanilla Apple-II all the way up to and including fully tricked out Amigas, and did all the heavy lifting a DM could ask for.

Up until I went 64-bit, I could run it in any flavor of Windows I had, too, using the VDM.  Now I just use DosBox to run it.

(Speaking of which, I need to cook up some stuff for tonight's game...)