This week, I came across an interesting post: Do You Know Cobol? If So, There Might Be a Job for You. The general idea is many big finance companies still use the systems that are developed in
Cobol, which is an ancient programming language. Currently, there are few people who master
Cobol, and even worse, most of them will or already retire. IMHO, this article gives an good example about companies and personal engineers’ dilemma brought by “outdated technology”.
Let me tell two stories first:
(1) I once worked in HPE for nearly two years, and
HPE has its own
Unix Operating System: HP-UX. Actually, my team did
HP-UX related work before I joined in, but at that time, all team’s work was already switched to
Linux. Why? Because
Linux had dominated the servers market then. To earn money, more and more resource should be invested in
Linux area, and for
HP-UX, basic maintenance and development is enough. As fat as I know,
HP-UX is still the backbone of many critical services, such as banks, telecommunication Operators, etc. But even for
HP-UX‘s priority becomes very lower now.
(2) There is a service which was launched in mid-1990s. It is a 32-bit program, written in
C programming language, and stable enough to serve the people all over the world every day. About
~20 years later, one engineer noticed Year_2038_problem because the program definitely use
time_t which is
32-bit long. He began to discuss with leader to transform the program to
64-bit, but both of them knew it was not as simple as adding only
-m64 compile option. After
~20 years, the code had become “mature”, what I mean is the code repository was very large; about
~40 engineers had ever committed code, and some modules had changed into a total “black box”, what I mean is no one knew the logic behind it, but it really worked as a charm! To transform it into
64-bit program, maybe the compilation can pass, but no one know whether it indeed work! It needs careful code review and sufficient testing, but seems not worth cause it is a problem which will occur
~20 years later. Therefore, this task lies in “Todo” list year by year. Every one pray the service should be shut down by
These examples all narrate one fact, most “outdated technology” are not too “bad”, such as
32-bit program, but for some reasons, they are not main-steam now. For most companies, the overhaul of services which are constructed by these “outdated technology” is not accepted: besides the notable time & person cost, one glitch can bring catastrophic result, even can let company close. But at the other side, the amount of engineers who master these “outdated technology” also become smaller and smaller, so the companies can only explore the potentials from their internal staffs mostly.
For engineers, there is also a dilemma. You can pick “outdated technology” as a hobby, but there is a huge risk to adopt it as a full-time job. Maybe one day, you need to find job again, and many biased companies will reject you just because they deem you don’t know some “hyped technology”, and can only tame dinosaurs. Ridiculous! Isn’t it? But it is the reality we must adapt to.