Blog on SOA - Technologies and Trends

Avi Rosenthal

Subscribe to Avi Rosenthal: eMailAlertsEmail Alerts
Get Avi Rosenthal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Ubuntu Linux Journal, SOA Best Practices Digest, IBM Journal, SOA & WOA Magazine, Java Developer Magazine, SOA in the Cloud Expo, CIO/CTO Update

Blog Feed Post

Information Technology: Are You Out of Business If You're Over Fifty?

My own selling point is the ability to learn and understand quickly any new Technology, Architecture, Paradigm or Methodology

Many IT professionals aged 40+ or 50+ are without a job and the task of finding a new one in IT is very difficult. There are a variety of opinions as to why this should be.

Recently I participated in a popular discussion in the Linkedin Group "Israel High Tech" about high-tech veterans and work. Here is a quick summery of the arguments for and against.

The arguments for hiring veterans
The arguments for hiring veterans are that they have experience, Business Knowledge and Technical skills (or at least many of them have these skills). They will not quit their job for another job and they are willing to do any assignment, even if some years ago they were Managers.

If this is the case, then the sole reason for not hiring them must be Ageism e.g. Age Discrimination.

The arguments for not hiring veterans
The arguments for not hiring workers aged 40+ or 50+ are that they're simply not qualified: their knowledge is not up to date.

For example, a Manager who would like to hire Linux Kernel experts, said that he would hire 50+ people properly skilled for this task. However, he found no one. He added that if those who are talking about Ageism could send him a 50+ Linux Kernel expert's resume he would hire him on the spot.

The conclusion of those supporting this view is Ageism is not the reason for not hiring 50+ High Tech experts. It is simply a matter of the better skills, abilities or lower salary requirements of younger people.

My Take
I am 62 years old having about 40 years' experience. As an IT expert, I worked both for companies and, for many years, as a freelancer.

Many young and especially elderly IT professionals have expertise in a certain IT field e.g. Java development, ITIL, C# etc. Good professionals excel in their field and learn and update continuously.

My approach is different. I excelled in one field, namely IBM Mainframe MVS and z/OS Operating Systems; but after many years in that field, I studied many other fields. I was able to generalize the principles and methods to many other IT fields.

My selling point is the ability to learn quickly and understand quickly any new Technology, Architecture, Paradigm or Methodology.

Service Oriented Architecture (SOA) is a good example. I was exposed to this concept prior to most of the IT professionals in Israel, while working together with a team of experts from another country. They shared their opinions and Service-based Framework.

After listening to them, I learned all there was to learn about SOA. When the SOA evolution crossed the Hype stages, I was better prepared than others because I had already begun to learn and experience SOA a year or two prior to most other IT professionals in Israel.
In the next section, I depict a special technical assignment I completed successfully as a 50+worker. I have highlighted in blue the factors and behavioral aspects which are age-related.

The assignment
A client asked me to help him in fixing Assembler code problems in a tailored extension to his z/OS Operating System (Jes2 Exits). I was lucky many 50+ IT professionals do not even get the chance to work.

According to his description, after any OS upgrade, they had to perform minor code changes. It always worked properly. But this time, none of the exits were performing their tasks properly after those minor changes.

Before accepting the challenge I had to consider whether take the assignment or not. I had to take into account two major factors:

1. For about 25 years I had neither read nor written even one single Assembler Line of Code. No doubt, I could do it easily 25 years or 30 years before. I coded a lot more complicated Assembler supplements to the OS. I was no loner with Hands On as far as Bits and Bytes are concerned.

A failure in completing the assignment properly was one possible scenario.

Some of the 50+ IT workers were not able to preserve their Hands On skills, because their current jobs are less technical or due to Paradigm Shift or Technology Change their technical expertise is less relevant or obsolete.

2. It was a Fixed Price assignment. Even if I will not fail, I properly work a large number of hours to complete the task.

Young People usually complete assignments more quickly, unless Experience is an important factor.

I decided to take the Challenge.

Solving the Technical Problems
I did not begun my work by looking at the code: I read IBM Manual. It did not take long to discover the reason nothing was working as expected.

It was simple: Unlike other upgrades in this version IBM made significant design change to the JES2 and to its Exits structure and mode of operation. MY approach is a typical grey-haired person's approach. A young expert would probably try to fix the code first. After few days of failures he may check the manuals.

My assignment was changed from minor code changes to designing a solution based on the new mode of operation and Exits structure. After designing, I had to code a lot more than minor changes.

Coding and Debugging
I coded slowly, because I had to verify that I was reducing the number of bugs to a minimum. Whenever something went wrong, I assumed that I had made a mistake and tried to identify and solve the bug.

I faced two difficult debugging issues that I spent a lot of time solving:

Problem 1: who is to be blamed for the Bug?
You already know my answer: I am to be blamed.

However, after reading the manuals again and again and verifying that I am 100% compatible with the explanations and the syntax described in the manuals and after testing any possible scenario and after analyzing the code again and again, I finally concluded that I did nothing wrong.

It should be a bug in IBM's OS. The local technical support group insisted that it is my fault. They could not find what was wrong.

I gave them all the tests scenarios and results. In one scenario my code was perfect, but in a slightly different scenario it failed. It looks like someone in IBM missed the less frequent scenario or at least made a coding mistake in this scenario.

When the data was send to the Development Group they confirmed my claim. It was IBM's bug. I was also given a workaround which solved the problem until they fixed it.

A young IT expert would have concluded a week or two earlier that it is IBM's bug. He would save a week or two. Bear in mind that in most cases it is a customer's bug and not a vendor's bug, therefore in many other cases a young expert would waste a lot of time: he would conclude that it is a vendor's bug and apply to the vendor. The vendor will check it for a week or two or a month or two months and the answer will be: "No Bug found".

Problem 2: Young IT professionals would have loved that Bug
This bug was in a very complex routine. As it was working properly for about 20 years, I assumed that the Data Exception was my bug and that it was outside that routine code. I found nothing. I asked someone with a lot of experience to help me. He found no bug. After two weeks I looked for an out-of-the-box solution: I considered the possibility that although, no code was change

Like most of other problems, after solving the solution is simple: It was a combined effect of an old times bug (Which was always in the code) and the design Changes made by IBM.

The bug was in an instruction for moving data from one location in the computer memory to another. The instruction is fixed length instruction, which moves always 8 bytes. However, someone forgot this and code the length. Assembler is a low level Programming Language. The 8 coded in the instruction was interpreted as adding Register8 content to the address defining the data location.

No harm was caused because Register8 always contained zero. Adding zero to an address will result in the same address. After the design change Register8 contains a non-zero value, which was added to the memory address, causing the Data Exception.

Grey-haired IT professionals have no advantage over young experts in solving such problems, unless they faced a similar problem in the past.

The Bottom Line
Young people have some advantages over 50+ people, but 50+ people have their advantages as well.

It comes down to an individual question interacting with the specific assignment: One 50+ man or woman could be an excellent choice. Another could be a waste of time and money. It it also true for 25 year-old professionals: one could perform a task perfectly, while another might fail to provide any value.

There are tasks that are more adequate for experienced Grey Haired. Young people will generally, be a better fit for other tasks.

Would someone hire me for Linux Kernel assignments? Probably not. I have no knowledge and no experience.

Would I be able to perform properly Linux Kernel assignments? I think I would be able to do this, yes. I would need to spend a long time learning it (and no one will be willing to pay for this time). But after I completed learning it, my experience in MVS Nucleus changes in those old days when MVS was immature, could count in my favor.

Fortunately, I do not need (financially) and I do not want to code Linux Kernel!

More Stories By Avi Rosenthal

Ari has over 30 years of experience in IT across a wide variety of technology platforms, including application development, technology selection, application and infrastructure strategies, system design, middleware and transaction management technologies and security.

Positions held include CTO for one of the largest software houses in Israel as well as the CTO position for one of the largest ministries of the Israeli government.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.