Banks scramble to fix old systems as IT 'cowboys' ride into sunset

Post by SmellTheGlove » Tue, Apr 11, 2017, 1:40 PM UTC

throwaway_374 wrote: post #151

sanguy wrote: post #52

Been working on accounting systems in RPG and COBOL since ~1992. I also know C/X86ASM/Pascal/Delphi/VB/Fortran. Never bothered with C++ that much; played with Java a bit but Oracle irritates my bowels so moved away from that. As mentioned in the article it's good work; but it is also not easy work. You tend to go through cycles of being pushed out to brought back under extreme emergency at any costs to get stuff work…

I think the question everyone is failing to ask is: what's the interview process like? Do they put you through 4 rounds of whiteboard coding bullshit followed by a coding assessment followed by a pair programming session? If anything, I'd argue the interview process for such a nice role should be the most rigorous because you can't rely on auto-complete-by-stackoverflow.

Post by philipov » Tue, Apr 11, 2017, 1:45 PM UTC

mikehollinger wrote: post #185

z3t4 wrote: post #128

Earlier quoted context omitted.

all features and edge cases should have a test. if possible also have tests for all the bugs ever found in the old system. it helps if the tests are not too coupled with the code and are well documented. a test could be making an entry where deb and cred dont match. or trying to enter an extra decimal. and if the system adds two decimals corectly.

>all features and edge casss should have a test. Yeah, but the interesting problem is what happens next. Let's say a test case reveals that there's a flaw in the next-gen system. You fix it. It later turns out that the same flaw exists in the legacy system. What do you do? Do you revert the fix, or leave it in place?

Post by nraynaud » Tue, Apr 11, 2017, 1:51 PM UTC

Post by pc86 » Tue, Apr 11, 2017, 2:00 PM UTC

jerguismi wrote: post #95

Joeri wrote: post #86

Earlier quoted context omitted.

> Companies never think of the old guys as the ones to implement the new system - that's a job for the "enterprise experts" Exactly this is why rewrites fail. The challenge of a rewrite is not in mapping the core architecture and core use case, it's mapping all the edge cases and covering all the end user needs. You need people intimately familiar with the old system to make sure the new system does all the weird stu…

What about not doing a rewrite? What about instead refactoring, documenting etc the old system.

Post by SmellTheGlove » Tue, Apr 11, 2017, 2:03 PM UTC

defined wrote: post #81

jfoutz wrote: post #69

Earlier quoted context omitted.

Unix has a few tricks up its sleeve from when it wasn't the top dog. I hesitate to ever recommend perl, but pack [1] and unpack are pretty sweet for this kind of stuff. I only learned about them when a state sent me files in EBCDIC [2]. As with all things perl, you can convert from that to ASCII as a one liner. Or, rather, i helped someone much smarter than me do that, 20 years ago. [1] http://perldoc.perl.org/functi…

Please don't remind me. I had to convert the expat XML parser to compile on z/OS and work in EBCDIC, and found that round tripping between ASCII and EBCDIC was sometimes impossible because of the existence of not two, but THREE line terminator characters: CR, LF, and NL (0x85). Not to mention that you cannot test for uppercase or lowercase like the ASCII `ch >= 'A' && ch <= 'Z'` because they are not contiguous in EBC…