3 ms·

> He also noted that billions of dollars would likely be needed to implement this kind of migration across multiple agencies. > You can’t just rewrite the whol

> He also noted that billions of dollars would likely be needed to implement this kind of migration across multiple agencies. > You can’t just rewrite the whole thing. Is it that bad? I guess I'm being crazy thinking I can do it single handedly in 5-10 years for a couple million.

kimi 8y ago
You have no idea. That code is "it does what it does" - no docs, no specs, no tests. Over the decades, "correct is what the procedure does", because 1. it works in most cases 2. nobody remembers why it was written that way 30 yrs ago, but there must be a reason somewhere. It's not a job for the faint of heart.
- fizixer 8y ago
  But it runs, and it shows stuff on screen, and it saves stuff in the hard-drive! I'm not saying I'll do things the conventional way. Once you give up the conventional way, it becomes a different ball-game.
  - oblio 8y ago
    Yeah, but how will you figure out the business logic? That comes from regulation, business requirements from 20 years ago, etc. It’s archaeology.
    - fizixer 8y ago
      See my response [1] to the other comment. [1] https://news.ycombinator.com/item?id=16968935 https://news.ycombinator.com/item?id=16968935
  - lucozade 8y ago
    > and it shows stuff on screen... And it has complex, undocumented connections to north of a hundred other systems. Screwing up any one of which could have hugely impactful effects on the business (or not, who knows?). So you're going to be coordinating testing with 30-40 teams in diverse parts of the organisation (and externally). And your couple of million won't pay for the redesign of all those feeds. Hopefully they won't take the testing costs out either or you'll be broke in 2 years. See, the thing with extracting these old, large systems isn't really the language they're written in, or the hardware they run on. Though those are nasty, ugly problems. It's the coupling. What will almost always defeat you, unless you give the problem the respect it deserves (and often even then) is the coupling.
    - fizixer 8y ago
      I hadn't thought of coupling, the distributed nature, so you have a point. However we can think of splitting up the system into pieces, and try to localize the update. For example, for a worldwide distributed system keep everything else the same but replace this one mainframe with modern hardware and code so that the rest of the system doesn't get effected. And so one. As for the couple million, that's for me :) But I guess if you factor in cost of supporting hardware/software/infrastructure, it's really past 5 million (maybe 10 million), just as an estimate. To elaborate on my 'unconventional way', I'm talking about using all of: - complete view of the source code, - runtime behavior on the screen (even recorded with cameras, or even better, display debug hooks) - runtime storage logging, - runtime network logging, - modern inference methods beyond parsing (semantic inference, logic programming, maybe even some statistical analysis). - But most importantly, automation-first approach (no, we're not doing things by hand. 'The Machine TM' will do the work for us). E.g., I won't be reading the COBOL code line by line. The code, plus the runtime behavior, would be the input to the inference engine, the output would be 'explanations, documentation, etc'. - and so on It would be a very challenging project, hence the 5-10 year timeframe. But I'm not convinced it's intractable. And I'm not convinced the cost is in the billions.
SmellyGeekBoy 8y ago
Bear in mind that the COBOL system isn't a static target - it will be constantly added to in that 5-10 years.
vorg 8y ago
> I can do it single handedly For every 1 programmer working on a Cobol system who would and could rewrite it, there's another 3 who actively resist rewrites to keep their jobs and put bugs in the system to generate overtime-paying after-hours callouts. There's yet another 6 programmers who don't have the aptitude to program but who somehow managed to get into their job and are just productive enough to avoid being terminated. And perhaps they bring one of their kids to work for the day every now and then. You don't get to do a Cobol rewrite single-handedly when there's 9 others on the team working against it happening.
- fizixer 8y ago
  I agree. But that also means the major roadblocks are sociopolitical and not technical (not saying technical challenge is not there, just that it's not the biggest issue).
wycy 8y ago
This is kind of my thinking too. I would think that you could just boil down the requirements for what the system needs to do and just build that rather than bothering to wade through the COBOL and translating it. I would also think the resulting code would be far smaller than the legacy COBOL, probably by an order of magnitude or more.

kimi 8y ago

You have no idea. That code is "it does what it does" - no docs, no specs, no tests. Over the decades, "correct is what the procedure does", because 1. it works in most cases 2. nobody remembers why it was written that way 30 yrs ago, but there must be a reason somewhere. It's not a job for the faint of heart.

fizixer 8y ago
But it runs, and it shows stuff on screen, and it saves stuff in the hard-drive! I'm not saying I'll do things the conventional way. Once you give up the conventional way, it becomes a different ball-game.
- oblio 8y ago
  Yeah, but how will you figure out the business logic? That comes from regulation, business requirements from 20 years ago, etc. It’s archaeology.
  - fizixer 8y ago
    See my response [1] to the other comment. [1] https://news.ycombinator.com/item?id=16968935 https://news.ycombinator.com/item?id=16968935
- lucozade 8y ago
  > and it shows stuff on screen... And it has complex, undocumented connections to north of a hundred other systems. Screwing up any one of which could have hugely impactful effects on the business (or not, who knows?). So you're going to be coordinating testing with 30-40 teams in diverse parts of the organisation (and externally). And your couple of million won't pay for the redesign of all those feeds. Hopefully they won't take the testing costs out either or you'll be broke in 2 years. See, the thing with extracting these old, large systems isn't really the language they're written in, or the hardware they run on. Though those are nasty, ugly problems. It's the coupling. What will almost always defeat you, unless you give the problem the respect it deserves (and often even then) is the coupling.
  - fizixer 8y ago
    I hadn't thought of coupling, the distributed nature, so you have a point. However we can think of splitting up the system into pieces, and try to localize the update. For example, for a worldwide distributed system keep everything else the same but replace this one mainframe with modern hardware and code so that the rest of the system doesn't get effected. And so one. As for the couple million, that's for me :) But I guess if you factor in cost of supporting hardware/software/infrastructure, it's really past 5 million (maybe 10 million), just as an estimate. To elaborate on my 'unconventional way', I'm talking about using all of: - complete view of the source code, - runtime behavior on the screen (even recorded with cameras, or even better, display debug hooks) - runtime storage logging, - runtime network logging, - modern inference methods beyond parsing (semantic inference, logic programming, maybe even some statistical analysis). - But most importantly, automation-first approach (no, we're not doing things by hand. 'The Machine TM' will do the work for us). E.g., I won't be reading the COBOL code line by line. The code, plus the runtime behavior, would be the input to the inference engine, the output would be 'explanations, documentation, etc'. - and so on It would be a very challenging project, hence the 5-10 year timeframe. But I'm not convinced it's intractable. And I'm not convinced the cost is in the billions.

SmellyGeekBoy 8y ago

Bear in mind that the COBOL system isn't a static target - it will be constantly added to in that 5-10 years.

vorg 8y ago

> I can do it single handedly For every 1 programmer working on a Cobol system who would and could rewrite it, there's another 3 who actively resist rewrites to keep their jobs and put bugs in the system to generate overtime-paying after-hours callouts. There's yet another 6 programmers who don't have the aptitude to program but who somehow managed to get into their job and are just productive enough to avoid being terminated. And perhaps they bring one of their kids to work for the day every now and then. You don't get to do a Cobol rewrite single-handedly when there's 9 others on the team working against it happening.

fizixer 8y ago
I agree. But that also means the major roadblocks are sociopolitical and not technical (not saying technical challenge is not there, just that it's not the biggest issue).

wycy 8y ago

This is kind of my thinking too. I would think that you could just boil down the requirements for what the system needs to do and just build that rather than bothering to wade through the COBOL and translating it. I would also think the resulting code would be far smaller than the legacy COBOL, probably by an order of magnitude or more.