Feeds

back to article Retiring greybeards force firms to retrain Java, .NET bods as mainframe sysadmins

New IT grads and Java and .NET jockies are being re-trained to run mainframes by big companies desperate to replace a generation of IT staff giving up work. That’s according to Compuware, who has released a study that says CIOs are growing concerned about the looming skills shortage in their mainframe rooms. They are concerned …

COMMENTS

This topic is closed for new posts.

Page:

Silver badge

The logical action would be to migrate these systems onto a modern platform (probably rewriting them from the ground up). But this will never happen because: (a) it requires thinking over a timescale longer than 6 months; and (b) it involves spending money over the next few years (i.e reducing this year's bonus) to avert inevitable catastrophe later on.

16
9

Building from the ground up

As Chris says, it would most likely involve building from the ground up. Many of these systems are more patched than Frankenstein. Over the years (most likely decades) functionality has been added to the basic systems, often programmed in different languages by people who left long ago.

It is a genuine nightmare for many of the larger institutions.

14
0

Actually this is being done in the financial institution I work for, but transferring the functionality of the core account system away from an old but stable solution is a MASSIVE undertaking and will take us several years. You can't just port it, you have to produce a brand new solution that does the same as the old one and takes the same inputs and produces the same outputs. There ISN'T an off-the-shelf new solution that can simply integrate with all our other systems.

And yes, the COBOL coders who look after the existing system aren't getting any younger.

17
0

migrate off mainframe

We just did it here in Irish Life ( recently aquired by great west life )

migrated all the CLOAS code over to .NET and used microfocus enterprise server to keep a lot of the old cobol packages working.

2
1
Silver badge

@Chris

I think there's most likely actually one main factor which weighs in the most: boffins who believe that maintaining the status quo (even if this means training new people) will be cheaper in the overall than doing a full migration.

And to be perfectly honest I can't really tell if they're right or wrong, it would most definitely depend on the environment and the way the company is doing. Most of all such a project would be huge (generally speaking anyway) and really demand some rock solid management and coding skills (the coding should be obvious; management to make sure it all comes together).

So from that point of view I also think there's some logic to be found in keeping things as they are. Although I do agree with you; a rebuild would bring in a lot of new opportunities.

2
0
Silver badge

@ShelLuser

You make a good point. IM(NV)HO, the time to start the migration is when your existing systems are still reasonably hale and hearty. Free prediction: within the next 5 years, a major financial institution will crash and burn because they will suffer a catastrophic systems failure from which they're unable to recover. That should focus the minds of the risk managers.

2
0
Gold badge
Unhappy

Re: Building from the ground up

"Many of these systems are more patched than Frankenstein. Over the years (most likely decades) functionality has been added to the basic systems, often programmed in different languages by people who left long ago."

Correct.

Here's the thing.

CTO "I want to scrap all our old CICS/COBOL that's been written over the last 40 years and rewrite it in C++/Java/ML/LISP/WTF is the language De Jour"

Board "Why"

CTO It'll be easier to maintain (and it'll look great on my CV. And if I can make the systems administration work as well I'll be a God)

Board "So what are the risks?"

CTO "It'll take years, (look at Nationwide migration to SAP), cost 100s of $/£/Em and cause massive disruption.

Board "And give us what we already have?

CTO "Yes."

Board "And is it likely your successor would want do the same, but with a different language?"

CTO "Yes. (To the man who only knows VB everything is a button)."

Board "I think we can can unanimously say that you can f**k right off with that plan."

They might not care what they use for their gambling qualitative trading systems but when it comes to tracking what their customers owe them on a large scale banks are very conservative

3
0
Headmaster

Re: Building from the ground up

"Many of these systems are more patched than Frankenstein"

I hate myself for it, but I'm unable to move on until I've pointed out that Frankenstein is not particularly reknowned for being patched up. Frankenstein's creation however...

9
0

migrate these systems onto a modern platform

If you research to various corporations which have Tried that "solution" you will find Lots of projects that Crashed and Burned and very few Success stories.

Of those that didn't crash & burn, the majority either took 3 times as long as promised or are Still trying to find the end of that rainbow.

It took a while, but there are very few major corporations left that Haven't already Tried that particular "Fix" and the managers who Survived are understandably reluctant to stick their necks out because many of them owe at least one Promotion to the departure of the guy who convinced upper management that "This is a Great Idea".

2
0

Re: Building from the ground up

Sadly true. The real problem is that, over those decades, both bad coing proactices and bad "Management policies" have Encouraged that Frankenprogramming.

Policies like "Change it, but don't Remove the old code until the New Code have been running for at least six months." Yes, I've Seen it. What generally happens is that no one Ever has time to go back six months later and identify the code that Should have been removed. Besides, if you DO and a mistake is made, someong gets the Axe.

I once had a single program that needed 3 very Simple Changes, the the FrankenCode was so bad that I could not get the changes to work. I had to get the specifications for the Entire Process (Thank god someone still Had them) and go through the entire program identifying all the dead code that No Longer executed under Any Circumstance.

After I removed that, I was able to make the required change in 20 minutes.

The program then ran perfectly, executed 20% Faster and the sourced code went from over 30,000 lines of code down to about 12,000.

And it only took 2 weeks to perform the Analysis of the FrankenCode to achieve the results that could probably have been done in less than an Hour if Good Programming practices had been followed instead of arbitrary practices written by a Manager who knew Nothing about Programming but Lots about CYA.

4
0
Silver badge
Boffin

COBOL

The problem with a lot of these things is that they run on System/390 (which we now know as z/OS) and use stuff that only those familiar with S390 know: CICS, TSO, ISPF, COBOL, RACF, OMVS … if you know what any of those things are, you're probably better qualified than most people in IT these days. Note that I said "you know what it means", not "know how to do stuff with that".

It also doesn't help that a lot of stuff from the mainframe's heyday was done in COBOL, which was all the rage back then in business realms up until Dijkstra rightfully slammed it and fell out of favor. (Sadly, nobody was able to do the same to Visual Basic.) Maybe the only thing worse than having to work with VB6 code or COBOL has to be MUMPS, and that language will also live for eons thanks to its usage in the US healthcare system.

Some banks have been migrating their code to better languages like Java, but some of these projects take years or decades, and even then they only get something like "now we got 40% COBOL code in our core systems". Most of them have simply made some kind of "core system" for the lower-level stuff, and simply develop middleware stuff on top of that. Because nobody wants to be the team that broke the bank's code!

3
0

Re: COBOL

And TELON....

0
0

Re: COBOL

COBOL? I never could get on with fancy high level languages like that. Stick with BAL - it is difficult to get simpler than that :~)

1
0
Anonymous Coward

Re: COBOL

BAL? Pfft. Languages are for n00bs. If you aren't flipping switches then hitting a "RUN" button, you're taking the easy way out.

1
0
Happy

Re: @ShelLuser

@Chris Miller

Yeah, and I bet that the catastrophic systems failure will NOT be on the mainframe side of things.

It will be caused by 'modern' systems which have been poorly designed, written and integrated in the first place.

But then, as a now happily (hence the smile icon) retired mainframe programmer (Assembler no less) who has written stuff for the banking industry and airlines with a side sprinkling of COBOL and PL/I, I would say that, wouldn't I.

I wish I could have 2 icons, as my second one would be the beer icon, which would cause the first icon, and which I have more time for these days anyway.

2
0
Silver badge

Re: Building from the ground up

Many of these systems are more patched than Frankenstein. Over the years (most likely decades) functionality has been added to the basic systems, often programmed in different languages by people who left long ago.

We regularly hear from potential customers inquiring about decompilation, as they don't even have the source code for their back-office apps.

When they do have source, it's often a vast amount of code, only a small fraction of which was actually used to produce the current set of binaries - but no one knows what fraction. There are tools to help analyze these massive legacy-system code bases (we sell some of them), but even budgeting that effort is difficult.

I think Chris has hugely underestimated the cost of reconstructing legacy enterprise applications from scratch - as in, by several orders of magnitude. And the large majority of IT projects that large fail.

2
0
Silver badge

Re: COBOL

The problem with a lot of these things is that they run on System/390 (which we now know as z/OS) and use stuff that only those familiar with S390 know: CICS, TSO, ISPF, COBOL, RACF, OMVS …

COBOL is most definitely not exclusive to IBM mainframe OSes, and never has been. CICS, TSO, and ISPF all run on multiple platforms. I'm not aware of any non-z RACF implementation, but RACF ain't that complicated; we have an implementation of the major SAF APIs and features (which I wrote) for our product line. OMVS, of course, is only of interest if you're running MVS or zOS, so I'll give you that one.

if you know what any of those things are, you're probably better qualified than most people in IT these days

Well, yes. Better-looking, too.

COBOL, which was all the rage back then in business realms up until Dijkstra rightfully slammed it and fell out of favor

Dijkstra's "How do we tell truths that might hurt?" screed is hardly a sensible commentary on programming languages. The man was a fine computer scientist, but that piece is pretty much the feeblest essay he ever wrote; it's nothing more than an extended rant, with no actual argument to make. Nearly every one of his points is an absurd generalization that fails to hold up under any sort of rational consideration, much less be supported by empirical data.

And COBOL did not "[fall] out of favor" in 1975 when Dijkstra wrote "truths that might hurt". It remained the preeminent business programming language for at least another couple of decades. 4GLs and similar DSLs, though they played a role as far back as the '60s, didn't really gain traction until the early '80s (note that's when the term "4GL" was coined). Some other business programming languages such as RPG and PL/I had significant market share, but nothing like COBOL's. Visual BASIC and Java both appeared in the 1990s.

the only thing worse than having to work with VB6 code or COBOL has to be MUMPS

There are more things in Heaven and Earth, Horatio.

Some banks have been migrating their code to better languages like Java

OK, I'll bite. What makes Java a "better language" than modern COBOL?

1
0
Silver badge

in a free market there's no such thing as a skills shortage

> CIOs are growing concerned about the looming skills shortage in their mainframe rooms

Merely an unwillingness to pay the salaries that supply and demand indicates as the going rate.

Having said that, there does come a time when the cost of employing specialists becomes greater than the cost of "de-specialising" and replacing the niche kit with more generic solutions that the new generation of cheap, trained and plentiful staff have the knowledge to support.

Knowing when that time is and planning for the eventuality is one of the basic jobs of senior IT management. However, when the CIOs and their direct reports keep their heads in the sand, spend all their time focused on the immediate and not the strategic, this is the inevitable consequence. That's just the cost of being out of touch with market trends.

17
1
Silver badge

Re: in a free market there's no such thing as a skills shortage

This.

6
1
Silver badge

Re: in a free market there's no such thing as a skills shortage

Unfortunately it takes more than 6 month to train a skilled sysadmin able to make _real_ iron work reliably.

11
0
Bronze badge

Re: in a free market there's no such thing as a skills shortage

While I understand the sentiment, since the IT sector in general is known for not always offering competitive wages because the posts and skills are undervalued by management, there certainly can be such a thing as a skills shortage.

If there are no people, or only a very limited number of people, with the skills you are looking for then that's a skills shortage.

An extreme example is, for instance, if you wanted to employ someone who could speak a language like Arawá, Aka-Bo or Esselen, you'd be out of luck since there's no-one alive who speaks them any more.

More realistically from an IT and mainframe point of view, the number of people with knowledge and experience of these platforms is dwindling. Certainly there are people alive who know them, but many of them have retired and have no interest in being employed again.

Of the ones that are working, some of that number may not wish to leave the job they have, salary is not the only motivation to take a new job or leave a current job.

5
1
Bronze badge

Re: in a free market there's no such thing as a skills shortage

Except the problem here is not dying languages. This ancient technology is often documented a lot better than its modern counterpart because it dates from a time when technology was sufficiently expensive you could afford to employ technical writers. COBOL, CICS or JCL are not really hard things to pick up from the manuals.

The real problem is that the business processes are not properly documented and the fact that, say, there's logic resulting from a merger back in 1987 that means the third digit of the account code results in special processing ever third tuesday is lodged firmly in the heads of the support staff and nowhere else.

That means you can neither accurately rebuild the systems from the ground up, nor solve the support issue by simply retrotrending the IT staff. It also means that exactly the same problem will occur in 25 years time with all the newfangled Java and .NET code - or much likely a worse problems as there won't still be dusty manuals on the shelves to remind you, when the online documentation is long gone, exactly when the Validate() method of that System.IdentityModel.Selectors.X509CertificateValidator object gets called.

34
0
Silver badge

Re: in a free market there's no such thing as a skills shortage

>in a free market there's no such thing as a skills shortage

There's no such thing as a free market.

And if it takes 5-10 years to train up the next generation of specialists, you can offer as much as you want and still not find the people you need. Especially if your current systems have so many undocumented features you have no way of knowing what they actually do - certainly not to the point where you can consider replacing them.

At some point the industry is going to have to stop building clockwork breaks-when-you-look-at-it IT and start building smart adaptive IT. But that's at least a couple of generations away, and we probably won't have banks or other institutions in their current form when it happens.

5
3
Bronze badge

Re: in a free market there's no such thing as a skills shortage

This portion of your last paragraph needs some editing, which I offer below:

However, when the CIOs and their direct reports keep their heads in the sand up their asses, spend all their time focused on the immediate bettering the next quarter's numbers and not the strategic, this is the inevitable consequence. That's just the cost of being out of touch with market trends.

FTFY!!!

Hey El Reg, where's the NO SHIT, SHERLOCK icon???

12
0
Bronze badge
Linux

Re: in a free market there's no such thing as a skills shortage

"the new generation of cheap, trained and plentiful staff have the knowledge to support"

Thanks to Microsoft, anyone can claim they are a Systems Administrator because they can click the mouse button.

10
1

Re: in a free market there's no such thing as a skills shortage

Bingo!

1
0
Silver badge

Re: it takes more than 6 month to train a skilled sysadmin

While true, it doesn't mitigate the primary premise: if managers had been valuing the skill they now find to be in short supply, people would have been training for the mainframes.

Here's the thing. I was in high school when the Sinclair and TRS-80s were being released. A friend of my mother's worked at IBM and passed along manuals for some of their stuff to me. Mainframes and minis. At the time people were predicting the demise of mainframes. It still hasn't happened. I don't work on the big iron myself, my area of specialization is on the micros. But I don't foresee the death of mainframes even after 10 years. There are some things they just do better than anything else out there. And the people who are migrating from "old iron" to "modern platforms" will discover that to their dismay.

11
0
Silver badge

Re: in a free market there's no such thing as a skills shortage @TheOtherHobbes

caveat, I've no experience in banking however

> And if it takes 5-10 years to train up the next generation of specialists

That's a damn big 'if'. I don't buy it.

Now in particular this

> Especially if your current systems have so many undocumented features

and from @Warm Braw

> say, there's logic resulting from a merger back in 1987 that means the third digit of the account code results in special processing ever third tuesday is lodged firmly in the heads of the support staff and nowhere else.

This, if true, would indicate a TOTAL FAILURE OF PROCESS and therefore A TOTAL FAILURE OF AND BY MANAGEMENT. Where you have tens or hundred of billions of £££ in your care, you don't hack like a garage startup.

1
2
Silver badge

Re: a TOTAL FAILURE OF PROCESS

If all you have is a college degree in business management (or the equivalent), I can see where you'd believe that. All it takes is a couple years of real world experience to disabuse you of that notion.

The big bosses have all agreed that because of the way the balance sheets work, the merger should go ahead. None of them have a clue about the incompatibility of the systems, but the guys they hired tell them there are technical solutions to those problems. And the deadlines are unrealistic with no one hired to write the documentation (I know I worked in exactly that field before I moved to break/fix deployment side). So you find the inelegant but workable hack that binds the systems together and maybe even have good intentions of coming back later to fix it properly. Except that the next big merger has come along and you're back in the same fix again next year.

Two jobs back we had a kludge of a system one of our divisions depended on. It was written in Delphi 2.0 using the Borland Database Engine 5.03 with some Crystal Reports 7.02 something or other I don't remember any more (not a programmer, just the poor schmuck installing the crap). The sexy language at the time was an early iteration of Visual Studio .Net. Now, we could get the BDE installed without too much trouble (well document on the install and two patches) and even the Delphi 2.0 wasn't a problem. Crystal Reports however turned out to be rather a problem AND rather a serious sticking point. The bit that I can't remember was a very, very, specific version of Crystal. From it you could select a subset of functionality that could be run from the network without actually requiring a Crystal install on the desktop. Apparently the next letter revision undid that bit of uniqueness. But the specific letter revision didn't run on the developers machines when we migrated from Windows 2000 to Windows XP. So we patched it. And 8 months later started getting reports about problems with inconsistencies from the user community. It turned out that whenever a developer updated a module with the new version of Crystal, it broke the inter-operability of that shared store on the network. About 30 employees were using the system, but it was tracking hundreds of millions of dollars in research money that was being distributed by the government to various medical research groups. Yeah, not pretty. They brought in a bunch of people who were going to port the data to a new program they were writing in a modular mode with modern software. About 6 months later I was part of a 50% RIF in the IT department. But the last I heard, the new program wasn't nearly as functional as the old one, and still had issues with inconsistencies in the reports.

I don't think anybody anywhere along the chain had bad intentions. But the end result was a serious problem at a midsized company (less than 500 employees, certainly nowhere near the Fortune 10000 in terms of market share). In a company with even longer lines of communications, I don't see things improving any.

5
0
Silver badge

Re: a TOTAL FAILURE OF PROCESS @Tom 13

> a couple years of real world experience

I have a lot more than that. I maintain such failures are management issues.

> None of them have a clue about the incompatibility of the systems

management failure

> but the guys they hired tell them there are technical solutions to those problems

They had better have good, solid, technical reason to believe these guys they hired, else they are bullshittees who hired bullshitters to lay on the bullshit in thick, soothing layers. In which case, management failure.

> And the deadlines are unrealistic

Who set the deadlines? Management failure

> with no one hired to write the documentation

guess what? :)

This is all management failure at one level or other, or multiple levels. This may be down to stupid short-termism of the stock market, but that's another matter.

On to your description of woe, there's not enough info there for me to try and allocate a blame. In that case there may not be one (just maybe). However,

> but it was tracking hundreds of millions of dollars in research money that was being distributed by the government to various medical research groups. Yeah, not pretty

suggests that this core piece of dosh tracking code was seriously underfunded. If so, who was to blame.

I'm familiar with a lot of this kind of crap. I've been in it before. I do sympathise. In one job a few years ago they got very excited when I mentioned I had delphi 5 because it turned out their product was based on D5 and the only D5 compiler + library install they had was on the programmer's development laptop (nope, no install disk). Disaster waiting to happen. So I gave them mine (Embarcadero refused to give them D5 under any circumstances, even if we paid the full price for the latest delphi (8 I think it was)).

Management failure in not having all the software their business depended on? You tell me.

> I don't think anybody anywhere along the chain had bad intentions.

Sometimes management failure is inherited from previous management but however the penny lands, 'no bad intentions' <> competent planning. The fact that that's how the many organisations operates, just on on the edge of disaster, doesn't change the fact that this is wrong.

Yes, the real world depresses me often because I have to live in it.

5
2
Silver badge

@BlueGreen

They had better have good, solid, technical reason to believe these guys they hired, else they are bullshittees who hired bullshitters to lay on the bullshit in thick, soothing layers. In which case, management failure.

I'm not usually in the room when those decisions are made. But I had a bird's eye view once. The guy making the decision wasn't a bullshitter. He was in fact, the sort of boss I'd like to work for if all bosses were like him. He wanted to find reasonable technical solutions to business issues, pay everyone a fair salary, and have everyone get along. His technical skills were rusty but he knew his stuff in the day and sometimes it still came in handy. They weren't shiny because he'd been placed in a position where he had to deal too much with people who didn't have his outlook on the business. We interviewed three people for a Help Desk Manager position. One of them bored me to tears and I couldn't remember a thing about him. Governmental functionary type but his accomplishments resume looked good. Another one was bright, energetic, and marked off a couple boxes on the quota sheet. In a different environment I would have hired her in a heartbeat. One problem with her stood out. We didn't have a lot of documented processes. What we had was learned by apprenticeship. And while management was trying to move us more toward an ITIL model it was a hard slog. For almost every question she referred checking the documented processes. She wouldn't have lasted two weeks in our environment. The third person was the one I liked. Sounded like he had come from an environment that started like ours, but made significant progress on documenting the processes and was leaving the company in a better place than he'd found it. He'd survive our environment and might even be able to fix some stuff. The Boss hired the first guy. His thinking was he'd be better able to handle some of the contentious office politics than the other two, and what he really needed was someone to offload that work to so he could focus on the other stuff that he really needed to. His rationale wasn't bad. And during the second interview his skill set sounded like it was going to be a decent fit to where we expected our company to be in a couple of years. I was RIFed about 6 months later (made sense from a purely business perspective, no need for the assistant to the manager when you only have half the people). Through the grapevine I heard that a couple months after that the guy broke his leg skiing, and 6 month after that found himself a new job. Yes, after the hire was made it turned out the guy was a really good BSer. But I don't think my boss was looking to be the bullshitee. And while I'm usually fair at smelling the BS, I didn't recognize how much of it he was laying on myself. It's not necessarily bad intentions, sometimes it is just a bad result.

suggests that this core piece of dosh tracking code was seriously underfunded. If so, who was to blame.

No one. When it was written it wasn't known that it was going to last as long as it did and that 15 years down the road it would be handling that much stuff. It was expected to last the length of a smallish five year contract and that it did quite well. But it got re-used because it existed, and more and more contracts were won and added to it. And until the switch to XP it all just kept on working. Keep in mind were talking about a company trying to make money managing government grants. The government regards that as more of a public service than something a private company should make money from, so margins are always razor thin. It's all well and good to argue that good management would have had a code review every time a contract was added and that all risks would be identified and factored into the cost of the contract. The reality is there are always unknown risks.

If there are no real-world examples of success, it is time to give up on the ideology no matter how right it feels.

I'm not saying I haven't gone off on the exact same rant you are when I've had a bad day. And God it feels good to rant like that. But if good management as described by you succeeded we'd see a hell of a lot more of it than we do.

5
0

Re: in a free market there's no such thing as a skills shortage

"...a mis-applied software patch from a team in India, and came after the bank had cut hundreds of IT staff to help cut costs....."

Date: 1950

Place: electric company.

Issue: bill to millions of customers for their electric service.

So, imagine 10 million customers, and each one must get a "reading" by a rep, then the rep's reports must be received, added to each customer's file (in file cabinets). Then each month the file must be pulled, the numbers added, the bill written, mailed and stamped. Then the bill must be received, the check read, the file pulled, the check amount added in, the file returned. Also, files must be checked for customers that failed to pay that month.

For each 1000 customers, there must be at least one clerk. So for 10 million customers, there are 10,000 clerks doing the work of reading, file pulling, writing bills, receiving payments, and so on.

Fast forward to 2014.

Same electric company.

Same 10 million customers. Same rates, reading meters, billing, receiving payments.

But now it is all automated.

Instead of 10,000 clerks, there are 20 programmers.

Imagine!

But wait. The management thinks that they pay too much to the programmers. The programmers are squeezed, and five are let go. Now management can boast that they "saved" a million dollars by firing 10 programmers.

No, the programmers "saved" the company 100 million dollars by automating the billing.

Seems pretty stupid. But then, it is a management decision.

Lesson learned: DON'T SKIMP ON PROGRAMMING! ! !

4
0
Silver badge

Re: @BlueGreen @Tom 13

> If there are no real-world examples of success, it is time to give up on the ideology no matter how right it feels.

Hmm. I've seen abundant failure due to clear deficiencies due in turn to bad management. So many it hurts. When I see problems grow expensively because someone didn't do the right thing earlier sometimes as little as a few days earlier, when it is known good practice to do X, and X wasn't done due to the boss, it's bad management.

I've been through too much to accept what you say. Favouritism in hiring an promotion, outright nepotism, underpayment of good staff so they left (despite having the money to pay), childish tantrums at staff cos they had a row at home with hubby, lack of process, lack of automation, disregard of the opinions of professionals, psychopathic bullying, failure to evaluate technical alternatives because they (bosses) weren't technical guys so didn't understand the pros and cons so assumed they didn't matter (common), also - my favourite - rating people's worth by how much you pay them rather than what they contribute (familiar?).

I don't accept what you say, sorry.

Interesting story you gave and you make a good point, sometimes the boss isn't to blame. Here's mine: I had an excellent boss, a real good guy (one of the very few I've ever had). A reasonable guy that, quite reasonably, expected his staff to behave reasonably. Well, there was some office politics that I got caught up in that was seriously damaging a critical project which he'd put me in charge of. It nearly sank this project which most likely would have bankrupted the company. He did his best but in the end he just could not stop a few guys trying to bust my work (some weird professional jealousy, and looking back I handled it badly too). He just could not sort out that situation because these guys were not going to be reasonable or rational. The main troublemaker could not be sacked for reasons I can't give; he was effectively untouchable.

We got it done but it was close and a scarring experience (and we got it done because he fought to get me the resources he could when I asked for them. He was a good guy).

BTW this guy's competent, professional attitude to management in other areas showed me what could be done by good management. He was my "real-world examples of success", even if a large chunk was in adversity.

> The government regards that as more of a public service than something a private company should make money from, so margins are always razor thin.

The government as procurer squeezing too hard thus putting a valuable service at risk - does that sound like bad management to you? Note that my definition of management here may be going further than yours, which is where we may be crossing wires.

1
0

Re: in a free market there's no such thing as a skills shortage @TheOtherHobbes

"Where you have tens or hundred of billions of £££ in your care, you don't hack like a garage startup."

Oh yes you do.

4
0

Re: @BlueGreen

What does RIF stand for in your comment?

None of the definitions I can find seem to fit...

http://acronyms.thefreedictionary.com/RIF

0
0
Silver badge

Re: @BlueGreen

Reduction in Force (workforce). These days you usually see it as "right-sizing" the company or redundancies.

0
0
Silver badge

Re: @BlueGreen @Tom 13

I've been through too much to accept what you say. Favouritism in hiring an promotion, outright nepotism, underpayment of good staff so they left (despite having the money to pay), childish tantrums at staff cos they had a row at home with hubby, lack of process, lack of automation, disregard of the opinions of professionals, psychopathic bullying, failure to evaluate technical alternatives because they (bosses) weren't technical guys so didn't understand the pros and cons so assumed they didn't matter (common), also - my favourite - rating people's worth by how much you pay them rather than what they contribute (familiar?).

Yeah I've seen all of that too. And given the rants here on the board, smart money is on most of the rest of the posters here have too. But that's the problem: with so many of us seeing so much bad management out there and so little good management it moves from anecdotal to data. If the data say the Darwin is favoring "bad" management, there must be something to it. I don't know what. And I suppose for the people that I know, its good for them that I act on what I've described as your "ideology" even as I question its validity.

I'd probably like you as a boss. And my personal beliefs mirror yours on this issue. But we sure don't seem to be winning the war so I have to start asking "Why?"

0
0
Silver badge

Re: @BlueGreen @Tom 13

> I'd probably like you as a boss

Wow, that is indeed a compliment! Whether I could live up to it... I really, really don't know. But thanks!

> so I have to start asking "Why?"

That's a difficult one and I have a view that's unsatisfactory but it just might have some validity. I'll think it through and post tomorrow, maybe.

In the meantime I by coincidence picked up this and am currently reading it (and this is the first ever management book I've read, it just caught my eye 2nd hand) http://www.amazon.com/The-Effective-Executive-Peter-Drucker/dp/0887306128 which is making me think hard, and may prove very valuable. It is also blessedly short and free of bullshit. It may prove useful to you too, and may go some way towards answering your question.

0
0

Re: in a free market there's no such thing as a skills shortage

. . .the third digit of the account code results in special processing ever third tuesday is lodged firmly in the heads of the support staff and nowhere else.

This is, indeed, the biggest problem I've encountered in a 30-year career. Worse, no matter how many times someone fails or forgets to tell a new IT hire some crucial detail, almost never is that detail added to internal documentation or training materials (assuming either even exists).

In my admittedly very personal opinion, and recognizing there are numerous exceptions:

It's a scathing indictment of the IT industry that with all the amazing developments on the "T" side, we fail so miserably at communicating the most basic "I", both to each other and the end users we support.

We can not blame non-IT management or budget cuts alone for IT professionals' continued problems communicating effectively with each other, nor repeated failures to document critical processes and procedures, then actually follow them.

I hesitate even to comment on the extent to which egos and territorialism have contributed to these problems. However, there is no doubt certain "historical" attitudes continue to bedevil us, and negatively affect others' overall impression of IT and those who labor in the field. Sadly, in far too many cases, IT staff have only themselves to blame for the lack of cooperation and support they receive from the non-IT side.

Certainly there are times when a business must change to meet the needs of an increasingly technological world. However, IT must move away from the attitude that the "latest and greatest" is always the best, or that business "should" or "must" alter itself to fit that technology. The emphasis of IT should always be the safety, integrity, and usability of Information, without which there would be no need at all for most of our shiny Technology.

1
0
Silver badge

Re: in a free market there's no such thing as a skills shortage @TheOtherHobbes

> say, there's logic resulting from a merger back in 1987 that means the third digit of the account code results in special processing ever third tuesday is lodged firmly in the heads of the support staff and nowhere else.

This, if true, would indicate a TOTAL FAILURE OF PROCESS and therefore A TOTAL FAILURE OF AND BY MANAGEMENT.

Welcome to the real world. We see this sort of thing all the time.

Where you have tens or hundred of billions of £££ in your care, you don't hack like a garage startup.

Oh, and you were doing so well, too.

1
0
Silver badge

Re: @BlueGreen @Tom 13

Ok, to try to answer your question "so I have to start asking "Why?""

People will accept crap, indeed demand it, if said crap is what's hot for the moment.

People will typically buy the cheapest, often through ignorance, sometimes even if they know better ("buy cheap pay twice" never takes root in their head, as my otherwise decent landlord is finding out).

People demand short term results. This is often said about the stock market - cash now, screw the future. That's a recipe for short-term thinking.

Conclusion - end consumers are in a sense managers, and collectively, rather poor ones. Their sheet quantity is perhaps the predominant driver.

To a more specific comment of yours "If the data say the Darwin is favoring "bad" management, there must be something to it".

Yesss... there is. People are getting what they demand (see above). In the short term (less than a year) this forces the creation of short term thinking. Long term investment seems to be discouraged.

But your mention of Darwin is a bit misleading I think. Darwinian evolution as you mention it seems to suppose vertical transmission of beneficial attributes, but organisations are highly porous and valuable components (ie. people) come and go in decades or years or sometimes months, which makes me think their existence has a lot of what looks like horizonal gene transfer (Horizontal gene transfer). Therefore good attributes (people) are not be preserved (they leave) and bad attributes can seep in (get hired). If the environment of a business is poor, good stuff gets diluted out almost osmotically unless much care is taken.

The analogy is flawed but it seems to have some truth, I think.

Well, that's my take and it may be crap but it's my best shot. Even if it has explanatory value it doesn't tell you how to fix the problem. It's pretty bleak in that respect. Sorry.

Also see cordwainer 1's post for an interesting take.

(On a somewhat less bleak note, we do have some control. I note that the personality types that create businesses sometimes tend to the arrogant, power-hungry and slightly sociopathic end of the spectrum (this is *not* a criticism, just an observation). Reasonable, measured, people like many posting here are not the types to bull ahead think the world owes them so we tend to end up being employees. Well, personally speaking, I'm trying to set up a business because I've had enough working for others. I may fail - failure *is* an option - but I'm damn well going to try. How about you?

Wish me luck).

0
0
Silver badge

Re: in a free market there's no such thing as a skills shortage @TheOtherHobbes @Michael Wojcik

> Welcome to the real world. We see this sort of thing all the time.

Yes, it's my world too. You may not believe this but recently I was ***explicitly*** told not to document a complex data structure. By the boss. You could not make it up.

> Oh, and you were doing so well, too.

:(

0
0

Re: in a free market there's no such thing as a skills shortage

I can offer one example of where the problem gets Magnified.

An acquaitance who absolutely Loves the C Family of languages because it is very Easy to write code that you CANNOT tell what it does from reading the source code.

He gleefully explains to anyone who asks him WHY? that:

"If it was hard for me to Write, I want it to be even Harder for the next guy to understand."

He's a Big Fan of the Obfuscated C Code Contest.

0
0
Silver badge

Literally

I know I know, grammar sniping is the lowest form of commentardery, but-

It’s the mainframe that often holds customer accounts – it’s literally where the money sits

sorry and all that.

3
2
Bronze badge

Re: Literally

You are complaining about the meaning of words, that has nothing to do with grammar.

And dictionaries now say that "literally" means "figuratively", you have already lost the war, move on.

1
4
Bronze badge

@Jim 59 Re: Literally

Besides, in this case, the classic application of the term is correct. In modern banking institutions, most of the money is nothing more than a digital representation which is literally stored and secured on their mainframes.

1
0

Re: Literally

Well, when so much "Money" is now nothing more than an Entry in a Database with no actual Physical existence, the word "Literally" is Correct.

Unless you don't count the Hard Drives where the database is stored as part of the Mainframe.

0
0

Funnily enough, I've just been having a conversation about how to make COBOL and attractive option for recent graduates as without new blood to fettle the old code there's going to be a very expensive re-write coming down the line. 20 years convinced that COBOL would be retired before I was, now I'm not so sure.

3
0

right on

There was quite a bit of interest around that time of Y2K but that quickly died out.

The situation has not improved since then - quite the opposite. This will be an expensive "upgrade".

3
0
Silver badge

> how to make COBOL and attractive option for recent graduates

Rename it to object.Cobol and start writing games in it.

We already have a trendy language (Python) that is following the 1960's FORTRAN mistake convention of making whitespace significant. Sexing up COBOL shouldn't be too difficult,

5
0

Page:

This topic is closed for new posts.