Live data from Hacker News

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

reuters.com

311–320 of 361 posts

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

#311

Earlier quoted context omitted.

> As of the 2010 census, the ethnic makeup and population of San Francisco included: 390,387 Whites (48.1%), 267,915 Asians (33.3%), 48,870 African Americans (6.1%), 4,024 Native Americans (0.5%), 3,359 Pacific Islanders (0.4%), 53,021 from other races (6.6%), and 37,659 from two or more races (4.7%). > Atlanta 2010 census: 211,365 Whites (38.4%), 28,071 Asians (5.1%), 286,126 African Americans (54.0%), ... So you me…

What are those percentages religion-wise, and in relation to the one-party state that the South calls governance?

One party state? Louisiana historically has been fairly left leaning. Democrat governor and Democrat senators/congress. Recently that went conservative with Jindal, but I'd hardly call the region one party. With the exception of South Louisiana, most of it and Arkansas (exception of liberal little rock) are in the bible belt, so things tend to be very old school (votes tend to go red).

Religion wise, the South is mostly protestant with the exception of Catholic south Louisiana.

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

#312

Earlier quoted context omitted.

As a developer who recently turned thirty, I think about this a lot. I like working in startups, but its not going to fly forever. I'm already the old guy in the room. Would learning 'ancient' technology be a good career move? These systems aren't going anywhere, right? But the people who know how to maintain them are. Which means that maintaining these system, which already pays well, will pay even better in the fut…

No, the stuff you know will be ancient soon enough. I would recommend keeping up with the new way of doing the same ole shit though.

I can't upvote this enough. Your tech stack will be obsolete even though the replacement will be mostly the same and possibly worse. Looking at it differently, imagine being a common lisp diehard starting in the 80's. Every 5 years you look around for something better and mostly anything would be a step back. Your dog died, your kid is in college, you're middle aged, Perl, VB...etc have all come and gone and you're still using lisp lol.

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

#313

Earlier quoted context omitted.

> it is quite expensive (I have heard figures quoted like USD 5000). A bit of correction, I'm afraid. That's the cost for mid-shelf copy of Visual Studio 2009 or so. It's not expensive at all for corporate purposes at any company I've worked at. Top-shelf Visual Studio was set for 10,000 for a long time (some checking of current costs suggests they've redone their pricing model). Expensive software for functioning co…

Expensive for whom? Yes, for a large corporation USD 5,000 is easily affordable. But consider someone like myself. My job isn't focused on mainframes. I very rarely have had anything to do with them at work. Even though my employer could easily afford USD 5,000 to buy me a zPDT if there was a business case for doing so, they won't because there isn't really one–in the last five years, I've only once had to help a cus…

I totally agree that this is a problem for the mainframe, and I personally have tried to talk to IBM about this (and obviously haven't gotten anywhere). This is a huge missed opportunity for them. I regularly encounter folks that would like to learn the platform, even at a hobbyist level, but it's simply not accessible.

FWIW... I know it's not exactly what you're looking for, but IBM does host a Master the Mainframe contest each year. It provides free access to current z/OS systems for a while (few months, I think) and a project consisting of a series of challenges that guide you though learning the environment. IIRC... you must be an enrolled student to actually win the prizes, but anyone can sign up and perform the activities. One of the mods on /r/mainframe helps coordinate the contest if you're interested in learning more about it.

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

#314

Earlier quoted context omitted.

A 50k LOC program serving a critical business function without a test suite or requirements documentation can be quite a chore to replace, especially if you let it go until you have neither staff experienced in the language or with experience with the background of the specific application.

I've converted such programs from one language to another. It is not necessary to understand how the program works, only how the language works. What you do is function by function, convert the language by duplicating what it does in the new language. Resist any and all urges to fix it, refactor it, improve it, etc. Just translate.

One semi modern language to another language is one thing. You could probably transpile the damn thing.

Converting batch based, RPG systems to a whole different paradigm, without a test suite covering the edge cases and 0 documentation is another.

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

#315

Earlier quoted context omitted.

No, the stuff you know will be ancient soon enough. I would recommend keeping up with the new way of doing the same ole shit though.

I can't upvote this enough. Your tech stack will be obsolete even though the replacement will be mostly the same and possibly worse. Looking at it differently, imagine being a common lisp diehard starting in the 80's. Every 5 years you look around for something better and mostly anything would be a step back. Your dog died, your kid is in college, you're middle aged, Perl, VB...etc have all come and gone and you're s…

"LISP programmers know the value of everything and the cost of nothing."

- Alan Perlis

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

#316

Earlier quoted context omitted.

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.

$800k/year is possibly unusual, but these are unusual people. I see nothing unlikely about a highly skilled contractor with 30 years of experience, a good network and in the right location to be pulling down $800k/year.

Do you know anyone who does? "Without working too hard"?

The chance that the OP is billing $800k/yr is vastly smaller than the chance that the OP used a bad figure of speech. The number of technology professionals who can sustain $400/hr billing for a full year is tiny. The number of technology professionals who are bad at communication is huge.

Bayes' Theorem is relevant here.

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

#317
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…

Sounds like you should start an "enterprise expert" consultancy that knows what it's doing. Seems like a good opportunity.

Go for it, if you like death marches that will just fail.

The real trick to software consultancy nirvana is to find the big whales paying big money for what are just kiddie apps.

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

#318

Earlier quoted context omitted.

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.

Doubtful. I'd bet a lot of the people who can do this work wouldn't be interested in a whiteboard interview. If you're fishing in a small pond for people that can maintain your legacy code, there's going to be a lot less bullshit in the process. Whiteboard interviews have their place, I'm sure. This isn't one of them.

I'm pretty sure with these kinds of systems, if you can repeat about 10 nouns relevant to working within a mainframe environment like this, you're hired.

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

#319
post #231

I worked for years on the modernization of a critical banking infrastructure system. The problems are manifold. The biggest problem is overall architectural impedance mismatch - switching from a batch system (most of those old COBOL mainframe apps are batch systems) to a service-oriented architecture. This makes incremental replacement extremely difficult. But a cutover? On a system that moves more money in a day tha…

At a certain point you reach a point where continuing to try to move elephants around is going to get you no where.

Death is a necessary component of change. In fact, renewal could not come without death.

Existing legacy systems bring with them assumptions about how things ought to work, and debt about expectations -- expectations that slow down your ability to change away from existing paradigms.

True innovation requires this breakaway.

So honestly, IMO the best move for a bank that is facing this kind of software nightmare is to maintain existing legacy support for the old system, but do a complete breakaway (NOT REWRITE) that is explicitly NOT dependent on the old contracts of functionality that the old system would have imposed. Make the rules change, acknowledge the old system will break with the existing system, and plan for a data migration over where ever possible.

Accepting defeat and moving on is a saner path. Migrating the data will become possible once it's realized that ultimately data is easier to change over than behaviour.

I say this too as someone who is very against rewrites generally. It's a fallacy to believe that old systems can accomodate new.

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

#320
post #231

I worked for years on the modernization of a critical banking infrastructure system. The problems are manifold. The biggest problem is overall architectural impedance mismatch - switching from a batch system (most of those old COBOL mainframe apps are batch systems) to a service-oriented architecture. This makes incremental replacement extremely difficult. But a cutover? On a system that moves more money in a day tha…

> When I see people in the startup world rolling their eyes at the "incompetence" of the enterprise world, I take it to mean they've never actually worked on a truly hard problem in their lives. I worked in a related field in the past. I don't claim that the problems are easy - where I tend to roll eyes rather is: - Bureaucracy: A lot is required by law, I know. But there is a difference between "just following the r…

Part of this comes from an inability in the early years to truly respect engineering as both a craft and as a form.

I know your startup mindset well and I carry with it with me too. I came into a legacy fintech company the same way and pushed for faster decision making processes.

I didn't realize the cause for conservatism until I was given a story about how the company needed to manually call and refund thousands of customers... all because one developer fucked up and double charged people.

When you deal with MONEY and you experience getting burned like that... you realize how mantra's like "move fast and break things" only work as convenient motto's for startups who have nothing to lose.

Post reply on HN