Quote from: thedungeondelver;559789Excuse 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...)

Ok, it's about a thousand computer years old and has a text interface, but I will grant it is the other electronic product they did well.  

But that brings us right back around to upgrades.  How difficult would it be to port that over to a GUI interface?  If you give me a comprehensive list of its menus, I would probably be able to hammer one out in a week or so, and I am not a very strong programmer yet.

Quote from: StormBringer;559777No, 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?

Enterprise level software costs millions of dollars.

Hiring a couple of COBOL tech guys is a couple hundred thousand a year at most (keep in mind you need non-COBOL tech guys after the switchover so you still retain 75% of the labor costs).

So, if the software costs you 5 million dollars (a pretty small amount for this kind of software) and only saves you $50,000 a year in costs, it would take 100 years just to break even (by which time the technology would have become obsolete many times over already).

No one upgrades an enterprise level software system to save money on programmer salaries.

Quote from: jgants;559793Hiring a couple of COBOL tech guys is a couple hundred thousand a year at most (keep in mind you need non-COBOL tech guys after the switchover so you still retain 75% of the labor costs).

Much less than that, because the C++ folks aren't just working on the one project, and colleges aren't burning up with COBOL courses.  The labour pool is diminishing, and the general programmers can be tasked with other projects when they aren't maintaining the financial code.  The cost is spread out over many departments, the return is much greater overall.  The entire cost isn't sunk on the one COBOL department, or section of the IT department.

QuoteSo, if the software costs you 5 million dollars (a pretty small amount for this kind of software) and only saves you $50,000 a year in costs, it would take 100 years just to break even (by which time the technology would have become obsolete many times over already).

Which is where Estar's incremental upgrades comes in handy.  They didn't do that, so I have little sympathy for their continued bad planning.

QuoteNo one upgrades an enterprise level software system to save money on programmer salaries.

No, that is only a facet of the costs.  Maintaining legacy servers, or emulation software for the legacy code, continually dealing with the problems of upgrading hardware with legacy software, plus the intangibles like decreased efficiency.

But all anyone wants to look at is the direct dollar amounts, so everything will creak along until the entire system blows up.

Quote from: StormBringer;559791Ok, it's about a thousand computer years old and has a text interface, but I will grant it is the other electronic product they did well.  

But that brings us right back around to upgrades.  How difficult would it be to port that over to a GUI interface?  If you give me a comprehensive list of its menus, I would probably be able to hammer one out in a week or so, and I am not a very strong programmer yet.

I've been working on one in vb.net - I appreciate what the originals do but there's so much more I want out of it, too...

Quote from: StormBringer;559802No, that is only a facet of the costs.  Maintaining legacy servers, or emulation software for the legacy code, continually dealing with the problems of upgrading hardware with legacy software, plus the intangibles like decreased efficiency.

But all anyone wants to look at is the direct dollar amounts, so everything will creak along until the entire system blows up.

I'm sorry, but as someone who has been doing this for a living for twenty years, I have to tell you: your grasp of the issues involved with these kinds of projects is extremely simplistic.  If you want to be able to speak to these issues with confidence, I strongly suggest getting yourself on the project team for a major systems upgrade of this type so you can see firsthand the devil in the details.

QuoteHow difficult would it be to port that over to a GUI interface? If you give me a comprehensive list of its menus, I would probably be able to hammer one out in a week or so, and I am not a very strong programmer yet.

As we say in software engineering, if you think it's that easy, you should be able to knock out a proof-of-concept pretty quickly.

tdd, why don't you post some screenshots?  I think this would be educational for everyone.

Quote from: StormBringer;559784Yeah, 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.

No, estar means captured knowledge, by which he means the business logic, which is often not documented, and has been built into legacy software over years, of not decades.  Getting all of that out of legacy code, even reading it line by line, can be incredibly complex and validating that it's all been captured and implemented correctly in the new code is also incredibly complex.

Quote from: thedungeondelver;559832I've been working on one in vb.net - I appreciate what the originals do but there's so much more I want out of it, too...

Excellent.  I would like to see what you have in mind.

Quote from: StormBringer;559802Much less than that, because the C++ folks aren't just working on the one project, and colleges aren't burning up with COBOL courses.

I've done batch COBOL programming on a system dealing with large amounts of money transactions (as well as non-money data).

First, you don't really need to learn COBOL at a college.  The syntax and structure of most of what's going on in most COBOL programs is actually pretty simple.

Second, there are a lot of things that COBOL programs do and don't do that a lot of C++ programmers don't learn in college.  Examples?  Don't use floats and doubles to store currency values.  Don't try to read a million records into memory at once so you can manipulate them.  I once wrote some pseudo-code of how to do an update using two sorted data streams on a white-board and had several good software developers look at me with bewildered expressions and ask, "How do you know that works?" to which I replied, "Billions of lines of COBOL work like that."

Third, there are actually benefits to COBOL over C++ for certain things.  For example, one would have to go out of their way to store currency as a floating point number and it's a lot easier to read a COBOL core dump when a program crashes at 2AM after processing a few million records to find out why it crashed than it is to read a C++ core dump.

In fact, one of the people in my gaming group is a CTO of a division that manages retirement funds and he deliberately asks for mainframe experience on his job requisitions, not because he has a mainframe or even an AS/400 but because he gets people with mainframe experience who understand how to handle money properly and formally test their code.

Quote from: John Morrow;559843No, estar means captured knowledge, by which he means the business logic, which is often not documented, and has been built into legacy software over years, of not decades.  Getting all of that out of legacy code, even reading it line by line, can be incredibly complex and validating that it's all been captured and implemented correctly in the new code is also incredibly complex.

Come on, this isn't like decrypting RSA messages.  The business logic can be recreated, and it's probably a good time to get rid of a bunch of cruft and streamline the processes anyway.  Hell, I would wager at least 30% of the core code functions haven't been used in decades anyway.

At any rate, this little nitpicking "prove StormBringer wrong" session is fun and all, but WotC has none of these problems.  It really doesn't matter if it costs a bank $33trillion dollars to install a CD drive, or if COBOL becomes the only computer language in existence tomorrow.  But these last few posts are demonstrating that inertia appears to be a much larger problem than programming languages or legacy systems.

Quote from: daniel_ream;559837As we say in software engineering, if you think it's that easy, you should be able to knock out a proof-of-concept pretty quickly.

I worked for a semi-technical manager who was convinced that rewriting some complex stored procedures in a database to make them run faster should be easy so one weekend, he took them home and said he'd have them rewritten by Monday.  He never did manage to rewrite them, even after consulting with a database expert.

Quote from: StormBringer;559848Come on, this isn't like decrypting RSA messages.  The business logic can be recreated, and it's probably a good time to get rid of a bunch of cruft and streamline the processes anyway.  Hell, I would wager at least 30% of the core code functions haven't been used in decades anyway.

Exactly how do you know what's cruft and what some customer is actually still using unless you actually take the time to understand it all, first?

Quote from: StormBringer;559848At any rate, this little nitpicking "prove StormBringer wrong" session is fun and all, but WotC has none of these problems.  It really doesn't matter if it costs a bank $33trillion dollars to install a CD drive, or if COBOL becomes the only computer language in existence tomorrow.  But these last few posts are demonstrating that inertia appears to be a much larger problem than programming languages or legacy systems.

I would say that WotC's problem is that it's not easy to make sure that you have good programmers who actually know how to solve the problems they are being given correctly and scalably and it doesn't help that they are in the same city with a huge company that has much more to offer the best programmers in town than they could ever dream of matching.  There are a lot of people out there who call themselves programmers who should really take computer programming off of their resume.  Companies often find that out the hard way, if they ever figure it out.

Quote from: John Morrow;559851Exactly how do you know what's cruft and what some customer is actually still using unless you actually take the time to understand it all, first?

Of course!  What I was suggesting is taking completely inexperienced programmers and turning them loose after you fire all the people that had been working on the system previously and deleting everything down to bare metal!  It's best if you make sure the new programmers have absolutely no financial background whatsoever, though.

I mean, holy shit.

Quote from: daniel_ream;559837As we say in software engineering, if you think it's that easy, you should be able to knock out a proof-of-concept pretty quickly.

tdd, why don't you post some screenshots?  I think this would be educational for everyone.

Here is a proof-of-concept.

I mean, fuck.  Spend a little less time figuring out why things can't be done and a little more figuring out how to do them.  Programming is problem solving at its heart, right?  How is coming up with page after page of why a problem can't be solved in any way helpful?

Quote from: StormBringer;559853Of course!  What I was suggesting...

No, the problem is that you are assuming that the task is far easier than it actually is, even if you have all of the software and the legacy programmers (who are, of course, always highly motivated by the fact that when the software they maintain is replaced, they'll be out of a job).