And as long as you fit the "correct" demographics for living in the south.
Banks scramble to fix old systems as IT 'cowboys' ride into sunset
191–200 of 361 posts
Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset
#192Earlier quoted context omitted.
I expect he meant the high range of 100K-200K. It's a colloquialism I hear periodically. I took it to mean $180K-$200K.
How can "high 6 figures" mean high 100-200k? Ugh, I hate english.
i feel like the terms quarter- or half-million (or million itself) are what people would use to describe salary once they've busted the "6-figure" descriptor where the first figure is implicitly "1".
"half-million" is much more impressive sounding than "mid 6-figure" salary.
Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset
#193$100 an hour, so $208k a year (assuming no time off), for a guy with 30+ years working on a critical system in an industry where floor traders can make 7-8 figures, and huge bonuses are paid to "analysts". I have plumber buddies that make more than that per hour (and with a crew can make more a year). That's why a couple years ago when I had access to a zseries, and was hearing about how "desperate" the banks were I…
Do you really think they quoted the high end of what they make to the reporter for this story? I'm sure that's the very low end of what people make (think "junior" devs in this particular niche). I'd bet the higher end people easily make 2-4x that amount.
Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset
#194Earlier quoted context omitted.
How can "high 6 figures" mean high 100-200k? Ugh, I hate english.
It can't. This is not reasonable English, it's (presumably) a misspeak by the OP. People make these kinds of mistakes in every language. It is highly unlikely that that the OP is making $800k/yr consulting as a programmer. That's $400/hr sustained for more than a year of fulltime work.
This isn't your average developer banging out Rails or Swift apps. This is extremely specialized knowledge of huge and arcane systems that are decades old. Entirely different ballpark in terms of knowledge and skillset.
Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset
#195Earlier quoted context omitted.
I smiled at your last comment. You're clearly a charming individual :-) Out of interest, what's the solution here? With your experiences in mind, what are the banks doing wrong from a technological perspective? I get the impression banks should almost start again on the side, building a completely new bank they then (manually?) move customers over to, or just use to take in new customers whilst waiting for the previo…
You can't wait for customers to "die out" as their mortgages will go on for decades. You definitely need a customer's old data in the new system. Now you have to maintain and develop two systems - bugs, banking regulation require constant work. Often the clock is ticking for old systems and asking vendors to provide and maintain ancient tools can be expensive or impossible. You can't "manually" move customers over, y…
While mortgages do go on for decades (typically), people will frequently re-mortgage based on new interest rates.
e.g. in the UK it's typical to sign up for 2-10 year deals, with the interest increasing after these offer periods, meaning people will likely switch to another deal.
So there will be a certain amount or organic churn.
Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset
#196Earlier quoted context omitted.
They don't use "mid-teens" in the UK?
Yeah, we do. "Mid double figures" might make sense in the context of use, but my first evaluation of that phrase isn't a value less than 20.
Sounds like it was clearly a mistake, but as you mentioned in a very specific context, with a specific range of likely values (temperature near sea level on Earth) I could see how it could make sense.
Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset
#197I dealt with something similar when I was a programmer. We had inherited a PDF publishing module written in 3B2 from the late 90s. (Google that language and you won't find much. Wiki article here: https://en.wikipedia.org/wiki/Arbortext_Advanced_Print_Publi...)
The most I've personally seen a contract was for hiring a consultant to help fix bugs in this 3B2 language that nobody knew. The cost for bug fixing and onsite training was $5000 CDN, per day. That was back in 2010. The day was 7.5 hours so this guy's rate was $666/hour (Now that I look back, maybe that rate was an inside joke or something).
We ended up hiring him for 5 days ($25K contract) as that was all that was needed to keep this module going, and we crammed a bunch of programmers in a room with him to see if we could learn a thing or 2 - the end result was negative. Nobody could learn it because we just didn't want to touch it.
It took another 5 more years to kill off that module and move to an open source solution. Now before anyone does any straight math do see how much this consultant made per year, you have to understand that work was very limited, and eventually, everybody wanted this language and publishing software to die off.
Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset
#198Earlier quoted context omitted.
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…
I did the same to enable XML messages to flow over MQ between an RS/6000 based front office FX options system, and a back office S/390 system. IIRC there were six (!!) different EBCDIC codepages that could be in play. I had a code generator that would crank out C or Java bindings that could martial between the expat results and the COBOL data structure. 20 years ago now!
Not sure if you remember but sendmail used to require a certain amount of m4 knowledge and hackery. Emboldened by that and reading the dragon book I was very impressed with myself when I wrote a COBOL parser in a mix of C, lex and YACC that automatically generated the needed 'C' structs and Sybase database layout to load data fed from a System/36. I made the data supplier put his code in the first part of the magtape, read and parsed that and then read the rest of the tape.
These days I consider it more of a "what was I thinking" facepalm-worthy sort of thing but at the time I was very proud of it. The "what was I thinking" part is more about the fact that some poor bastard had to come along after me and support that mess.
Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset
#199Earlier quoted context omitted.
It's not unheard of. But you must understand that these are people that have a pretty decent job security in an often huge codebase that has been aquiring cruft for 30 years in language most people don't understand. I would like to be able to claim that the code is good, but some of the people writing it in the first place were not programmers. It is not strictly bad, but some parts are just mine fields. A bit relate…
Best story I've heard is one of the old programmers commenting his COBOL code in latin . It was a different time...
"Mea culpa" over and over?
Re: Banks scramble to fix old systems as IT 'cowboys' ride into sunset
#200Earlier quoted context omitted.
What about not doing a rewrite? What about instead refactoring, documenting etc the old system.
Because COBOL is the PHP of the 60s, and mainframes are slow and expensive. Also, too many of the talents are stuck in a blocked I/O mindset somehow. Some are wizards though, writing assembly and making raspberry pi sized systems blazingly fast. OK a couple of raspberry pi:s
Our mainframe is expensive but it isn't slow. It's not exactly sitting on the same hardware from the 70's.