I work in a IT company that is deeply specialized in projects made with old and outdated technologies.

The biggest projects are usually a mix of Cobol (the oldest versions, not the most modern) and Java 4 (at least 60 projects on this stack), but we also have projects in Java 2 (less than 5), Java 3 (a dozen), Java 4 alone (at least 30) and Java 5 and 6 (usually translation without any refactor on architecture or logics of projects in older Java versions). We usually don’t use any Java frameworks (such as Spring, Hibernate, etc.), mainly because when the projects begun these frameworks did not exist. We also have assembly, assembly - Cobol, assembly - Cobol - Java (usually Java 4), C, C++, Fortran, Visual Basic projects (and probably a few other languages). Our software projects often don’t have any graphical interface; when one exists is in Cobol or in JSP displaying tables (CSS is barely used and there are only a bunch of projects that use vanilla Javascript). Our projects usually last from 3 to 5 years, but we also have projects that have lasted for 20+ years (as far as I know this is very very uncommon in the IT world).

We CANNOT change the stack of the projects and the language used because these are choices of the clients. We work with multinational/worldwide banking and insurance groups that widely use these languages. For example: a worldwide bank and finance group has all its internal systems (not only batch, but also the ones used by operators in branches) in Cobol on mainframes. The only part of the system not in Cobol is the home banking site, that in fact is not ours.

People working in my company, according to HR statistics, remain on average about 6 and a half years (another thing that in IT is very uncommon), but we have colleagues working here for 20 or 25+ years (maybe on the same project or on the same kinds of projects). Our salary is well above average (HR statistics, speaking with friends in other companies and simply comparing our job listings with those of others), for a senior could be up to the double of competitors.

In the last 5 years (and even more from last 2 years) we are facing enormous difficulties in hiring new developers, especially juniors to mid level ones. A lot of our job listings for those positions receive a ridiculously low number of applications and even less are the people that show themselves interested in our outdated projects after the first interview. How can we reverse this trend?

  • 12
    How large is your company : a few dozens of people, or at least several hundreds of developers? That matters a lot! Commented Jul 4, 2018 at 15:45
  • 11
    This seems too broad - just about every recruiting technique, employee perk (even if retention isn't your problem - people talk and look for different things in a job and it makes your job description more appealing) and thing that improves the company image would apply here. Commented Jul 4, 2018 at 17:35
  • 8
    Do you include benefits like Remote?
    – WernerCD
    Commented Jul 5, 2018 at 2:19
  • 9
    @LeopoldT May also be worth adding a country tag to this, as it's possible suggestions might differ by locale.
    – berry120
    Commented Jul 5, 2018 at 15:33
  • 9
    I think it is unhelpful to the community that questions like this should be put on hold as too broad. The question itself is very specific. They have a problem that they need to hire for retro technology. But this problem demands creative suggestions of potential solutions from a wide range of viewpoints. There may in fact be one very specific and superior answer out there and you cannot know there is not.
    – Sentinel
    Commented Jul 9, 2018 at 7:19

25 Answers 25


20% Time + Open Source

You've probably heard about Google's 20% Time policy. In essence, any employee can ask to use up to 20% of their time on pet projects.

I suggest that you implement something similar.

The problem of working with antiquated technologies on maintenance projects is dual:

  1. Technology skill obsolescence: the technologies learned in the course of the project do not open any door; this means gambling on retiring prior to your experience no longer be needed.
  2. Creativity death: maintenance, especially on high-stakes projects, often require the most surgical changes possible. There are a lot of important skills here, but I would NEVER work in a job where large-scale improvements are impossible.

This is where 20% Time comes into play!

On their 20% Time, encourage your employees to have fun. I would personally suggest participating to Open Source projects, as it has multiple benefits for both your company and them:

  1. It promotes your company: look, those people are paid to develop on X, Y, ...
  2. It helps employees develop skills in the area they are interested in: from kernels to JavaScript/CSS frameworks, with everything from graphics, machine-learning, big-data, etc...
  3. It gives employees a creativity funnel: don't go wild on the COBOL codebase, there's likely an Open Source project out there who'd like people to come up with advanced design ideas!

And best of all, when one of your client decides to move to Big Data Framework X (I hear it's all the rage), with luck you'll be able to boast: "Do you know, we just happen to have 3 contributors to the project on our team with all the expertise you could need to help you design your application!".

Paid royally to work on cool Open Source projects of my choice?

Well, now that's a cool offer!

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Jane S
    Commented Jul 17, 2018 at 0:55

If you advertise looking for someone with COBOL experience, tough luck. So who could do this job? Someone less than ten years from retirement, who can afford to switch to a dead end technology, and who is willing to learn a new / old language. I learned Swift just recently. Compared to that, COBOL is primitive (I know it, took a two week course in 1979). No problem to learn it whatsoever. Advertise for someone with experience who has seen it all, offer an excellent salary with several years of job prospects, and tell them they are expected to learn COBOL, not know it.

PS There are development environments that I wouldn’t put up with, so that might be a problem.

  • 20
    The way I've seen other companies go about it is to offer this to underserved groups of people, e.g. people out of jail or recovering addicts. They're likely to have fewer options and more likely to jump on something like this.
    – Magisch
    Commented Jul 4, 2018 at 12:54
  • 41
    @Thorbjørn Ravn Andersen "Dead end", not "dead". And that it is. There are no new commercial projects using COBOL. And the maintenance will only be needed and paid for until the companies eventually move to more modern tech.
    – Kakturus
    Commented Jul 4, 2018 at 15:51
  • 122
    and tell them they are expected to learn COBOL, not know it. is probably a key here. Even if I wanted to start a career in COBOL today, I would consider it impossible since I would think every company requires 10 years of experience in the language. Maybe don't even title the job opening "COBOL Developer" but rather "Software Developer" so more people will look at it and actually consider it.
    – wavemode
    Commented Jul 4, 2018 at 21:41
  • 13
    You don't have to be a COBOL Developer to work in COBOL. And having worked in COBOL does not make you a COBOL Developer, it just means you have some (mostly useless) experience with COBOL. However the job will probably be quite boring and with no real chance for advancement (as you get when working on modern technology), and you should expect to have to compensate developers for that. Commented Jul 5, 2018 at 0:25
  • 49
    A senior person, not too far from retirement? A junior developer, willing to Learn COBOL? Staff with a technical background, who may have been laid off as redundant? Looking to top up their retirement funds? Hey, that's me! Where is this job listed...? Commented Jul 5, 2018 at 5:01

This is the issue with mounting technical debt and sticking with aging tech - the amount of people familiar with the technology declines slowly at first and then quickly as they age and leave the workforce.

Eventually, the people who understand the tech will be rare as hen's teeth and will command high salaries if the tech is sufficiently essential to the business. At the same time the number of businesses which require people with these backgrounds is vanishingly few.

The name of the game in the modern IT environment is career security. If you keep getting stuck with one aging technology stack, eventually you will find it harder and harder to get a new job. This is why junior and mid-level developers don't want to join you - it could be a death sentence for their careers.

Best thing you can do is to start regularly updating your current applications and core technologies to modern standards. This will mean rewrites of almost everything - potentially completely from scratch. This will be time-consuming, difficult and more than likely costly. This is how you get new people on board - by telling them you are updating to modern standards using the latest technology stacks.

Otherwise you will eventually find when some business essential application or service eventually breaks that there is nobody who can even attempt to fix it.

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat. Commented Jul 6, 2018 at 23:29

Maybe be more prepared to hire older people eg those that are returning to the workforce after being stay at home parents or carers.

My general experience is the IT industry is incredibly ageist, often to their own detriment.

  • 28
    This looks like the most rational answer by far. I know several very experienced developers treading water in contemporary software environments, feeling frustrated as they're surrounded by bearded dudes who think they know it all but won't listen to the people who INVENTED the systems they're using! It's worth noting, too, that the majority of these deprecated geniuses are women. (Computing used to be a job for the girls, in case the beardy guys missed that.) So advertise for older experts. Maybe even ask a few of them what would incite them to apply - and consider targeting women. Commented Jul 5, 2018 at 3:29
  • 9
    +1 A pension with a short vesting period could also help attract older experienced programmers, and as another suggested, don't require them to know the languages, be willing to train.
    – SeraM
    Commented Jul 5, 2018 at 14:58
  • 1
    Practically, this means things like: part-time or job-share type positions, working remotely (part or all of the time) with support (i.e. hardware, furniture, etc), childcare provision, generous sick leave / child sick leave, good insurances, relocation packages & spousal support, good pension. Using an age & gender blind recruitment process (and advertising thats what your doing) will also help signal support to potential applicants. Commented Jul 6, 2018 at 15:32
  • An acquaintance of mine, a mechanical engineer, is now working on COBOL at a bank. He says 64% of the world's banking systems still work on these stone-age languages. He's one of the many less-ambitious engineers in India who find it difficult to get a job in the right stream, and soon has a family to feed. So they'll get into any job that has less competition and gets them a monthly pay for long enough to sustain a family. Even without special benefits, they will do their work without complaints for as long as you need them to.
    – Nav
    Commented Jul 8, 2018 at 12:50
  • One of my college lecturers (don't know how old he was, but he was grey and balding) knew COBOL, so people who do know it still exist - they aren't in a retirement home just yet.
    – Pharap
    Commented Jul 15, 2018 at 11:16

You're finding out painfully why so many developers specializing in old languages are making serious bank right now.

As a young developer, it's a losing proposition to adopt these technologies now - best practices and capabilities are so far from where they were back then, and software development is such a fast moving field, that if you don't work with the latest & greatest or at least most widely used technologies, you're gimping your own career hard. They'll have to expect that in 20 years so few people will be doing stuff like fortran or COBOL that their newly acquired skillset will be useless - a bleak proposition.

So do what you must - offer on the job training to people who otherwise wouldn't get hired anywhere, explicitly mention you'll hire people with prior convictions for criminal offenses (if you can square that with insurance), offer a more then competitive salary, better benefits.

The crux here is you're asking new devs to sacrifice their future career prospects, so you have to compensate adequately for it.

  • 2
    Comments are not for extended discussion; this conversation has been moved to chat.
    – user44108
    Commented Jul 6, 2018 at 5:50
  • 2
    I take issue with the word "painfully" here. There's no indication that OP's company's revenue, or profit, is suffering. In fact, since their customers are multi-national banks, enjoying peak profitability, the OP's company is likely thriving also. It's not that they can't pay, they just don't want to pay. And it's awful that billion-dollar companies whine about increasing labor costs that might reduce margins by a % or two, while real people out there struggle to afford healthcare, or get a first raise in 5 years, or rent for life because they never caught up to exploding house prices.
    – ExactaBox
    Commented Jul 13, 2018 at 11:18
  1. Remote development. Let them choose their cost base and lifestyle.
  2. Flexible time. Let them work when they want.
  3. High salary. Let them know their craft is appreciated.
  4. Stability. Let them know this is a long term prospect.
  5. Fun. Let them know the technical challenges are just as interesting as they ever were.
  6. Collective. Organize a club feel around this retro infrastructure maintenance.
  • 14
    I'd add freelance. I imagine many retired engineers would be keen to freelance for fun or extra cash, and many mid-level or junior engineers would be willing to do this as a side-hustle if they're developing experience in another main language. Commented Jul 5, 2018 at 7:20
  • 1
    These are all good things to attract people in every company and environment, but it doesn't apply particularly to the challenges of this question.
    – gnasher729
    Commented Jul 5, 2018 at 19:45
  • 3
    @gnasher729 It precisely addresses the challenges of this question.
    – Sentinel
    Commented Jul 5, 2018 at 20:34
  • This answer is relevant to the question because it is a solid list of benefits that can be used to attract people to work on very old and outdated technologies.
    – TehShrike
    Commented Jul 7, 2018 at 15:20
  • @GustavBertram absolutely! It's amazing how much more people can accomplish, or are willing to try taking on, if they have some flexibility - especially us older folks :o) Commented Dec 21, 2018 at 10:32

You need to offer a high enough salary to compensate applicants for the negative effect on their career which specialising in outdated technologies will have.

If you have too few applicants who want to take the job once they find out about it, the salary you are offering is too low.

Alternatively: can you amend the job spec so that people in the role spend no more half their time working with outdated tech? That could ameliorate candidates’ anxiety that they’ll end up stuck with worthless skills.

  • 16
    "negative effect on their career" is a good point to bring up. Some developers won't want to work on projects strictly because of the work, but because of what future employers will see on their CV. Commented Jul 4, 2018 at 18:28
  • 1
    Working with legacy programming languages can also be a benefit. I have to deal with IBM JCL and Fortran 77 daily. However, I am doing things I didn't think was possible, they are actually very versatile. I am a better programmer due to introduction to those languages.
    – Donald
    Commented Jul 6, 2018 at 6:49
  • 1
    And give the clients a projection for the increasing cost of maintaining their legacy systems together with an offer for refactoring it.
    – user29390
    Commented Jul 13, 2018 at 7:44

No JavaScript, no CSS, no obscure Annotations, just plain Java... That alone does surely catch my attention...

Increase the reach of your offer

Try to participate in University events. At my University there was a week where Companies would come to the campus and give speeches about what they did and why they were a good working option. Then they would gladly collect CV's of interested students. You may even receive a paid grant to get to know each other from the inside.

Catch their attention

Nowadays there's more frameworks than programmers and it's cool of you're using the latest framework which saves you from typing a semicolon at the end of each line...

So, why would a programmer be attracted to an old technology stack? No JavaScript, No CSS, just Java would be a good enough catch phrase for me (not related to any film).

Salary is one that's already been mentioned. What about pride? This job is not suited for everyone, you need to be a capable developer because you can't simply browse SO for the solution... Maybe this job offers intellectual challenges that will make you love it.

When you post a job offer on the Internet, give the feeling that the company is not dinosaurs with computers (I'm sorry, but it's the first thing that comes to my mind when I read COBOL). Are there any activities your workers perform that the attendees may join if they're hired? Laser games, maybe?

Does the job offer allow you to work some days a week from home after the onboard stage?

Keep them interested in your offer

For some people salary may not be what catches their attention, but something that keeps them interested. Another typical one is training: I highly appreciate jobs that sponsor official (out of the company) certificates.

If technologies are uncommon or rare, your candidates may want some job stability. Do you offer a long-term contract? Also, what are the chances of internal promotion?

  • 18
    +1. There are people who actually enjoy solving ugly problems with poor tools. I'm one of them. They're a minority but they exist. You have to come up with a "marketing strategy" that will reach them and draw them in. University mathematics and science departments are a good place to find them. Plenty of people there are quite happy working with FORTRAN or even assembly, and are probably getting paid a small fraction of what you typically offer.
    – Artelius
    Commented Jul 5, 2018 at 5:44
  • 2
    "No JavaScript, no CSS, no obscure Annotations, just plain Java... " Say what??? You do realize that javascript and java have absolutely nothing to do with each other? Commented Jul 5, 2018 at 16:32
  • @ChrisStratton Of course, only Annotations are directly related to Java. However, they're usually part of the same technology stack.
    – Bernat
    Commented Jul 5, 2018 at 17:44

I worked for a company (as a consultant) that was technically a private entity, but was exclusively allowed to work for the local city's governmental branches.

As is custom with government software development (in my experience), the projects weren't great. I worked on a 25 year old undocumented social security platform that was once written in COBOL, ported to VB by unsupervised interns, ported to VB.Net with no refactoring unless it broke the build, and several generations of underskilled development teams working on it with no sense of ownership and leaving the project undocumented and more fragmented than it already was.

There were many other projects like this. About 80% of the work was focused around keeping outdated and spaghetti-code-infested codebases operational because the government couldn't spare the budget to improve it.

Long story short: the developers started leaving en masse. The only ones left behind were those who didn't know (or try) any better, which only compounded the issue further.

When the company got a budget increase for one year, they decided to refactor the company in order to retain its younger and more experienced employees. And they succeeded.

What they did is (privately) acknowledge the shitty projects, and offered a massively increased work/life balance:

  • Tasks are assigned the 1st of the month. You are expected to deliver them at the end of the month.
  • Anything that happens inbetween those dates is your call. Work from home when you want to (all you had to do was put it in your agenda).
  • Management does not set deadlines. The developer (random selection for poker session, much like jury duty) set the deadlines themselves, and the customers signed off. The company did not (to my knowledge) ever force the developers to lower their estimated hours.
  • The offices were changed to flex spaces. Some floors had extra tables (for those who often do ad hoc meetings or conversations), other floors only had small one-person tables (for those who wish to work in peace and quiet).
  • Other than being present for meetings (usually one every two weeks), no attendance was required.
  • Work was evaluated based on the end result, not time spent.
  • The company intranet was put online, making it possible to work from anywhere with an internet connection.
  • Other than the code repository (internal TFS), all tools (including email) were available on every PC with an appropriate login.
  • Should you not be able to deliver, you either get your project manager's approval to push your deadline, or you can go and convince the customer directly (note: most developers would already be in contact with the client directly anyway). As long as either the company or the client signs off, it's all good.
  • Leave application are approved virtually regardless of scheduling (note for internationals: we have paid time off here, and the amount of (paid) leave days is known by you and your employer).
    • Anecdotal: I had to ask for a three month absense once (due to work reasons, not holiday). Without speaking, the PM turned to his laptop, opened a spreadsheet, put a 0 in three columns, and that was the end of it. No discussion.

Did this improve the quality of the projects? No. There still wasn't budget nor time to redevelop these applications.

But the company started retaining the good developers, and the easy going work environment gave them more than enough slack to offset the otherwise unenjoyable project work.

Before, the company was choking on unskilled (or unwilling) employees who weren't effectively contributing but were creating more work in an attempt to look busy. It's very hard to get rid of these employees when they outnumber the "skilled" developers.
Maybe it's not applicable everywhere, but that "create work to create job security" mentality is something that is stereotypically attributed to government workers here. It's very common.

Because the company gave the employees an almost criminal amount of freedom, employees felt free enough to not bother looking busy anymore. Work was being graded based on the end result, not on time spent working.

I've read other cases where companies experimented with a "free leave" system, i.e. the employees were free to take as much leave as they wanted. And, as it turned out, the average leave taken did not significantly change from the rigid leave system they had before.
Some abuse happened, but many employees felt free enough to take leave when they wanted to, that they became less insistent on the specific leave days they were alotted.

Personally, I heralded the downfall of the company, but I have to stand corrected. While the quality of the work hasn't improved, they've managed to offset the horrible projects with an amazing work/life balance.

  • 1
    Fascinating. It sounds like they've made an environment in which excellent application of software development principles could gradually (very gradually) bring about actual improvements to the codebase itself. (As noted in the book I've linked, the first target is just to get the codebase to a point where it's getting better over time rather than worse over time. But, also as noted in that book, the real first target is to have developers who want things to get better.)
    – Wildcard
    Commented Jul 5, 2018 at 20:40
  • @Wildcard: In the 2 years after the change that I still worked there, not much improved codewise though. The company merely stopped haemorrhaging developers. There was little incentive from the client (including budget) to improve things, so I understand that the company wasn't going to pay for redesigning something without documentation with an active 24/7 service contract. But that's more related to the government as a client, than the company itself. However, I do agree that it was a bold move that has paid off against most people's expectations.
    – Flater
    Commented Jul 5, 2018 at 20:51
  • 2
    Right. But redesigning would be a mistake, and a waste of money, when the existing system does work and does fulfill the real world needs. The chapter of that book that is most useful and applicable here is Refactoring is About Features.
    – Wildcard
    Commented Jul 5, 2018 at 20:59
  • @Wildcard Keep in mind that governmental frameworks are in a continuous state of development due to changing legislature. These aren't build once tweak later applications. Not refactoring is effectively cutting a manday down to less than 4 hours.
    – Flater
    Commented Jul 5, 2018 at 23:16
  • I can't quite interpret the intent behind that comment, but did you read the article? I think we're in agreement. :)
    – Wildcard
    Commented Jul 5, 2018 at 23:33

I work in a IT company that is deeply specialized in projects made with old and outdated technologies.

The biggest projects are usually a mix of Cobol ...

Consider changing your company's mindset and approach. Instead of requiring simply Cobol expertise (and your coder to code just in Cobol), also ask for static source code analysis expertise, and hire people able to use or even develop static source code analysis techniques (perhaps even some in-house semi-automatic code transformer/analyzer). That market is more attractive (technologically). Of course you'll need to offer competitive salaries (and you would perhaps hire PhD level developers).

BTW, I know a few companies (specialized SMEs) doing static source code analysis (and semi-automated code transformation/refactoring) on decades old Cobol code.

A person having worked a few years on source code analysis of Cobol is likely to find some other interesting job later (e.g. would move to another company doing source code analysis of Java). A person expert in Cobol (only) has to stay in that world (and is gambling that there would be still some other job in Cobol). Of course, source code analyzers are often coded (the tools themselves, not the code they are analyzing) using fancy technologies (e.g. Ocaml, Haskell, etc...)

Of course, you would then also sell to your clients the service of refactoring (perhaps even rewriting partly) old Cobol code (so convince them that technical debt is a worry). And that is not cheap.

BTW, if you know some H2020 or future FP9 European project proposal where such a work -static source code analysis of Cobol, not manual refactoring of Cobol code- could fit (but, in july 2018, I don't know any) -or if you want to propose a direct industrial contract with my employer CEA, LIST-, don't hesitate to contact me by email to [email protected]. I am working in a lab with static source code analysis skills (but our current tools are not targetting COBOL; we could adapt them for COBOL -not sure that makes technically sense-, or develop COBOL static analysis tools, if and only if we are funded for that; my naive opinion is that your market might not be large enough for that: developing static analysis tools is expensive and takes time. But if your company -or client- can afford a million € project for 4 years, please contact me; more probably you'll better -and that is difficult- network and find several other companies willing to share the risk and cost).

My naive opinion is that the skills you are after are costly, but not that much. In a few years, they could be even more costly and rare, and then a static analysis and semi-automated refactoring approach would make much more sense. Your company could bet on that and start building its own static source code analysis of Cobol code. And yes, that takes years and costs a lot. There is No Silver Bullet.

  • 3
    +1. I've actually thought about this problem before, and I came to the conclusion that transpiling from a more modern language to an older language may be a way to get out of this. You would have to develop the technology, but it would be extremely valuable since so many large financial institutions have exactly the problem described by @LeopoldT Commented Jul 5, 2018 at 7:18

TL;DR: You shouldn't expect juniors for these roles.

There are some very excellent comments, and I can't list the source authors effectively, but those points are basically this:

You're asking someone to go into a dead-end job and risk being unemployable.

There's only one best-case scenario listed: The person working on these old stacks retire before the stack does.

For a junior, we're talking about 30-40 years... you really do not expect to work at a place for this length of time, especially if you will be unable to get another job after working there. If I gain 5 years of experience in all the tech you worked with, what exactly will that do for my next job? Would it even add to my employability or subtract from it?

I don't think you can realistically expect juniors to go for these positions. This is a career track that is extremely risky, and unless you offer up some sort of massive early-retirement pension, the risk is extremely high... they join your company, work for 5-10 years, get married, have kids, and then suddenly become unemployable.

You have to accept what your business model is and consider whether hiring juniors are even realistic.


I am a junior developper working in a company with the same constraints and languages as yours and I disagree with people saying to update your technologies or expect an aging population. The technologies choice is out of our hands but we are sure Cobol won't die soon. New projects are unlikely, but the maintenance domain is very large. My answer is maybe lacking insights of what the "real" market is like, but it is how and why I got into my company. What my company decided to do might be France-specific, but I'm sure you will find comparable solutions in your country.

First of all, we take interns and pay them twice as much as the standard. We take care not to have too many interns, juste a fine number that we can care for and handle (one per group ie one in roughly 12 people). Then, we try to systematically offer a position at the end of the internship, or a part time learning (sandwich course I think we name it in English). The idea is to look as attractive as possible to juniors, and offer them what they need (experience, stability, good money or just an internship). Make sure to tell them you have maintenance contracts for the decade, and that they can progress in the company as they get more experience. I do not guarantee you will keep them for 10+ years, but 3 or 4 out of 10 might stay for 5+ years.

We also have a strong partnership with schools and faculties around. The idea is that our juniors might have a good experience and share it to their friends/colleagues, the university finds a way to make sure their students find a job and we have a recruiting pool. We also offer cooption (you get a bonus if you suggest a recruitee that is recruited).

When I was applying, my colleagues showed me they had a nice work environment without going in the whole Google like workplace. It can be simple touches like offering flexible time, activities with colleagues or a massaging seat.

We are not afraid to hire people from different walks of life. Many of my colleagues are former researchers in biology and physics. We also have a partnership with the national unemployment agency. Lately, we have won a contract with them in exchange of the hiring of 14 unemployed persons selected by them. We have formed them for 2 months, them let them work for 3 weeks to see how they were doing, and they are now all hired.

  • 6
    @leftaroundabout, your criticism is more than a little over the top. Where's your answer? This answer coherently disagrees with the "dead-end" description applied to Cobol and describes a real world strategy that is actually being used to keep a Cobol project staffed and maintained.
    – Wildcard
    Commented Jul 5, 2018 at 20:44
  • 1
    @Wildcard I upvoted gnasher's answer: programmers who actually have lots of experience would at least be sure to know how to keep the project in a maintainable state. Whereas from the legacy projects I have been involved in, I know how much the problems can be exacerbated if maintenance issues are tackled by inexperienced programmers with hackish patches. (Admittedly, those people I have in mind weren't really programmers at all but physicists, which certainly didn't help...) Commented Jul 5, 2018 at 21:35
  • 3
    ...If I had to give a suggestion to the OP, I'd say to invest first of all in building a new unit-test suite written in a modern language around the old code. That doesn't interfere with any customer “requirements”, can be used to attract programmers targetting the testing language, and can only improve robustness. Also it paves the road for actually migrating the working code, without however committing to such a move. But, this doesn't really answer the question, and it's certainly not feasible for all codebases. Commented Jul 5, 2018 at 21:35
  • 1
    @leftaroundabout, that's actually quite a good suggestion. I think it does answer the question, in a way: attract programmers to work on the test suite, which will be in a modern language. If you posted it as an answer I'd upvote it.
    – Wildcard
    Commented Jul 5, 2018 at 21:43
  • 1
    in my experience modern systems (apps! games! rofl www!) tend to be, in general, very sloppily thrown together, with high technical debt.
    – Fattie
    Commented Jul 7, 2018 at 16:46

As I said in comments, this is the sort of job I would like (though I work mostly in science & engineering, not business apps), and I don't think I'm alone.

So how do you attract me? First, be willing to hire older* people. I think there are plenty of people out there who have a lot of experience in these languages, and who actually enjoy programming, especially if the project is inherently interesting to them. Offer part time work, flexible hours, and telecommuting. Good pay helps, but it doesn't have to be spectacularly so. Frankly, at this point in my life, I don't need to work (unless the current President totally screws up the economy, in which case we all may be going back to farm labor :-(), but neither am I interested in being "retired".

*Or other people from non-traditional backgrounds, as for instance a friend of mine from university with a lot of good experience that's ~20 years old, because she decided to be a full-time mom. Well, the kids are grown, and she's bored, but everyone wants either new grads or people they've headhunted from other companies.

  • 1
    Although your suggestions are sound, they are basically a subset or repeat what stated in other answers, like this older answer and the ones mentioning to target older devs. Please remember that we have a Back it up policy. Anything new you wish to contribute in your answer?
    – DarkCygnus
    Commented Jul 7, 2018 at 0:43
  • @DarkCygnus: I think my answer differs from the one you linked in a couple of IMHO important ways. First, it's more than just a list of bullet points. Second is what it leaves out. IMHO the last two bullet points of that answer would not help to attract the sort of employees the OP wants. For me, they're actually rather negative.
    – jamesqf
    Commented Jul 8, 2018 at 4:05

I would suggest looking for people in their early 30s to mid 50s especially those who are thinking about getting out of IT because they are no longer into the brogrammer scene. Settled people with children especially women who can't work the ridiculous hours of some start-ups. Retirees whom no longer need to keep up with the Joneses.

Offer things attractive to this group like paid daycare. No overtime. Lots of vacation time. Flex hours. Remote working. Part time. Retirees especially might like the part-time part as they are not going to want to work full-time and aren't going to care as much about staying current.

See if you can offer projects that are a mix of some with older technologies and some cutting edge stuff. Or offer 20% time to work on projects using any technology they want to learn.

  • People in their 30s are old relics looking to retire or get out of programming?
    – Dan
    Commented Jul 16, 2018 at 14:38

This question has answers I totally agree with, but I believe they are missing a few minor nuances.

I don't believe you're selling your entry-level positions as apprenticeships very well. Try using a combination of modern code-writing practices (pair programming, some version of agile) with the old technologies you're working with, and getting junior-mid level guys who want to take the next step up interested by saying, "Hey, these old guys know COBOL / etc. like the back of their hands. That will help you code in easier languages much better."

Because that's the truth. Offer entry-level guys the opportunity to inherit knowledge of dozens of languages / sub-languages that will die, but leave a huge footprint behind that needs maintenance and someone who can understand the code for upgrading.

Also: update your tools and use the best you can find. Automated build systems connected to source control, cloud servers if you can manage them, etc. If you have a modern-looking programming environment that does something old-fashioned, you may get both more productivity out of your existing employees and be able to attract whippersnappers like you want.

  • 1
    Truth be told, I do not really see the issue of working with COBOL during an apprenticeship, especially if you add a decent amount of Java to the mix. Sure, Java has changed quite a lot over time, but it still is Java.
    – Seth
    Commented Jul 5, 2018 at 10:22

As with any "how to hire programmers?" question,

for better or worse, there is one and only one answer.


OP is basically saying "We're finding it incredibly hard to hire { a certain type of } programmer..."

But wait. It is incredibly hard to hire ANY particular type of (good) programmer at the moment.

  • 4
    If there are any two programming jobs available it is not sure that any given programmer will always pick the best paid one. Maybe the ones who really are brainwashed since they were small kids that bunkering up loads of money is what life is about... those are the ones you can get for sure by making sure to pay highest salary. Commented Jul 6, 2018 at 8:12
  • 4
    The entire, total aim of life is to do as little work as possible so you can live your life and enjoy your family. The one and only way to "do less work" is to "get more money". Less money == slavery and work in to your old age. Making less money means you 'want to work' - you are 'choosing work'.
    – Fattie
    Commented Jul 6, 2018 at 14:03
  • 2
    Don't worry. They probably won't seek you out for any opportunity to work for you anyway. Commented Jul 7, 2018 at 12:18
  • 1
    Anyone who has "work as little as possible for as much money as possible" as a life motto and takes a job with a salary, seems to be missing the entire point. All the people who really think that are either expensive consultants or own a business, and won't be drawn to a salaried job.
    – Erik
    Commented Jul 15, 2018 at 14:09
  • 1
    Even if you are able to work less you will still spend a substantial amount of your day at your workplace. Choosing a place of work where you have less fun and are constantly in a bad mood just to retire a little earlier or work a few hours less per week feels insane to me. I rather have 40 hours of fun work than 37 hours of shitty grind and 3 hours of free time.
    – tritop
    Commented Jan 28, 2019 at 12:57

Demphasise technology. Put accent on learning universal skills.

Bascialy: "learning how to learn".

Lots of people here point out that learning COBOL is a "dead end", touting as example to the contrary eg. Spring. That's quite unreasonable. Spring is merely 15 years old today. It's unsafe to assume that something can last you a lifetime. What you need is to shatter this erroneous preconception and educate candidates that their job security doesn't rely on any particular technology, but on their ability to adopt any technology necessary at a given point. Wrap it into some cool, marketable term, like "cross-language agility".

Also, you can emphasize on long-term hob security. High turnover rate in IT is not a goal by itself, it's merely a tool to increase salary. If you offer good salary from the start, 6+ years average is a good thing. "A job where you'll want to stay".

However, when one switches jobs, especially a junior, the general skills are not as important as immediate experience in given technology. To address that concern, you should offer courses, workshops, side-projects and open source involvement, etc in modern technologies. Basically, a side-project to keep tabs on current developments. Something that your employees could write in their resume to not appear as 100% dedicated to IT archeology. For me, it would be most interesting to rewrite an existing project with new tools just to see if it would do any better - but it should be something for your people to decide.

The final issue is the current state of the job market. Everyone has openings, but there is not enough people to fill them. Even in modern jobs like mine, we got like 2 reasonable respondents to a posting. Most channels yielded exactly 0, the only responses we got came from a FB group. Maybe try that, instead of trying to convince mass-produced graduates to COBOL, look for people who already are curious about programming history (or low level) and train them into programmers.


Diversify your client base. You claim you cannot change tech stacks because of your clients, but you can change clients.

Your current trajectory has two concerning end points:

  1. You cannot hire new developers, therefore cannot fulfill the clients' needs, and you lose all your clients.
  2. Your clients update their technology, and your current staff is unable or unwilling to go along, and you lose all your clients.
  • As well as clients updating their tech, they can also go bankrupt (or merged, or whatever) or change to a competing "old-tech" company. Commented Jul 6, 2018 at 15:41

Coming at the problem from a slightly different angle:

Noteworthy is that a lot of people who see a job posting that says "COBOL" will just look the other way, because it's a new (to them) technology that they have certainly had no exposure to. Likewise, Java 4 (or pre-4), and so on. I think the most important thing here is to advertise, upfront and openly, that you are not expecting people to come in with ANY COBOL experience WHATSOEVER, and to live true to that. Having personally gone through a bunch of interviews, there were a lot of companies who said in their phone screen "yeah, we use that technology but we don't expect people to actually know it, you can learn on the job" and then the interview was all specific questions on the minutiae of that technology. This is not cool, and unfortunately too many companies do this so "we don't actually require this in our skill set" on the job posting holds little weight with applicants, imo.

What might be more helpful is, in your job posting, explain how applicants are expected to learn these old technologies at the company, to prove that you don't actually expect them. Then, during the interview process, keep your questions as general and technology-agnostic as you can: be aware that probably nobody you interview actually has the skill set you're looking for, but if they've applied then they're willing to learn it; this means that asking questions about those technologies during the interview is likely to be a red herring and give you a lot of false negatives, i.e. people who are good developers but don't know your tech stack (as has already been established, nobody knows your tech stack except you, because of your niche business).

The other thing to consider is, who are your applicants? Off the top of my head, I think you can probably divide a good applicant to your company into one of two buckets:

1) People who are extremely smart, extremely talented, for whom life at Google is rote and mundane, who are looking for a bigger challenge in a niche market. When you say you pay double your competitors, are you considering Google as a competitor? Because for these people, your competitor is Google, Amazon, Twitter, Facebook, etc, i.e. the tech giants. These are people who could go work anywhere they wanted, but they're choosing you because they think your company provides a particular interesting challenge to them. However, these people want to be compensated for what they're worth, and you should expect to be paying them what they're worth or they're not going to be interested.

2) People who have no other choices; their skills with modern technologies suck, so they're going with you because "might as well give it a shot". These people have much lower expectations, but they are generally much worse developers, so it's debatable if you want to be targeting them aggressively. If you do, though, posting on job boards is probably not where you want to be; these people have already looked through job boards, applied to hundreds of postings, and are sick of the grind. For these people, you should contact recruiters/headhunters. These applicants may be waiting for a headhunter to call them with whatever new and shiny job description is on the table, and you want that to be yours. The important thing, though, is that job boards are not going to get these people; if they wanted a job from a job board, there are many companies they could apply to that don't require (or look as though they require, even if you don't in reality) knowledge of COBOL and Java 4.

There is a third group, which is developers who are so old that they grew up on COBOL and Java 4. The reason those developers aren't under discussion is because they are close to retirement age; even if they were to join your company en masse, you would only be delaying the problem you currently have for maybe 5-7 years, and then you'll be in the same position all over again. Targeting these people is not the solution you're looking for.


One sign of a good company is that they anticipate their manpower needs and have a plan to meet those needs regardless of what the current stock of unemployed developers has to offer.

The opposite approach is to rely on luck. Only fools do that.

Your hiring practices should depend on identifying people with the aptitude for software. It's a bonus if they know the specific language(s) that match your needs, but a lack should not be a show-stopper.

Your on-boarding training program should include a boot camp for the specific skills you require.

My own company's flagship product is coded in COBOL. We hire entry-level talent and teach them COBOL. We also code products in C++. We hire entry-level talent for these products, and teach them C++. Ditto for C#, SQL, JavaScript, VBScript, etc.


Offer the roles part time

Those around retirement age, particularly if they have been COBOLling for decades, are more likely to be looking for part time roles than younger workers. The median hours worked for 56-75 y/olds is less than half that of 26-55 y/olds in these IFS statistics, even as both vary.

It may seem counterproductive to get part time employees as you'll get less work per hard-to-recruit employee, but you may be able to convince them to add hours after they've joined.

Accept second jobs

If I were to see such an opportunity, the only thing that would persuade me to apply would be the possibility of simultaneously doing work on up-to-date technology. If I could work on my skills in new technologies (at sub-median pay) whilst simultaneously doing this job (at high pay), that would be an acceptable compromise.

Or mix the role

If you have a part of the business which does work on new technologies, offer a mixed role in which above-average pay gets the employee both new experience and the higher pay of the old technology.

Most small-business development roles involve a degree of new mixed with a degree of maintaining the (in)glorious old; sometimes, you accept you'll spend a week fixing something that came out of the ark, just because.

Offer a very family-friendly environment

There is a huge hole where there should be jobs which work around the family schedules of skilled-but-family-orientated people. A role which combined the above opportunities to learn/use up-to-date technology, paid decently well, and was thoroughly flexible, would be an absolute gift. I have a family, I would love to be able to work between picking up the kids, with a couple of days at home, doing extra work in the evenings or when sitting outside the ballet lesson.


Per LeopoldT's (OP) comment:

As far as I know my company is the biggest in the country for these kind of projects. And the only one so specialized in these old technologies. Another factor is that for clients is very difficult to move to competitors after 20, 25 or more years with us: the amount of knowledge to be transferred is simply tremendous (also for money to spend)

If your company is still doing well (i.e. with enough resources), then an effective solution to attract the younger generations may just simply be:

  • assign X hours of the current developers time to build up courses on those technologies;
  • create contracts which include a paid tutoring period of time based on these courses;
  • add clauses to the contract that will require the recruit to work certain amount of time after taking the course (not a legal expert: this might not be possible or it may need adjustments);
  • advertise in universities with those same courses highlighted (possibly only requiring a bachelor's degree and basic programming skills for the screening tests), mentioning something similar to: "We are the largest company developing with [programming language/technology] in [country] and a stable career progression might just be waiting for you with us!" (not the marketing expert either... some adjustments might be needed).

Collect talent, train talent, secure talent.

This won't be cheap, but you probably knew that already. The good news is that you have a unique opportunity in centralizing resources for deprecating technology.

First and foremost, collect talent. Get the best developers in your fields that you can. Relocate them from wherever. You can probably get an unshady H1B for this to import developers. This becomes your backbone.

You'll need to advertise that you have talent to spare. Social-friendly blogging is probably your best bet. You want to get as many of your best and brightest out in the public eye in hopes that one or two of them become a minor celebrity. The marketing people will appreciate the exposure, but your real goal here is posturing in the development community. You want the other A-players to see people they know and respect. It'll draw more resumes and create a virtuous cycle of collecting talent.

Next, train talent. The top tier of college graduates is off limits to you. Sorry, but that's life. You want to screen the leftovers. Get HR in touch with state agencies to find out who's doing retraining. You'll probably be able to set a curriculum, have them trained on the state's dime, and pay barely half their salary for the first 3-6 months. Set appropriate expectations for them: this is an internship position with the rare possibility of hire, but you'll pay them more money than most of them have ever thought possible if they work hard and succeed. Do career fairs at community colleges and take their best and brightest. Be a sponsor of some of those self-paced online learn-to-hire programs and snag yourself some strong self-starters. Give people who have a portfolio but no resume a chance (and probably stick them in with the career change interns for safety). If you have to, recruit the bottom half of CS graduates, but I'd avoid it if I could. Then you train them using a mix of your collected talent and the best available standardized curriculums.

Finally, secure talent. Once they've made it past your probationary period, you do not lay anyone off for any reason ever. You make this abundantly clear in your interview and recruiting processes. A job with your company is a job for as long as you follow the rules and produce results. If you've done a good job collecting talent, you'll become a valuable asset for enterprise customers because you already hired nearly everyone they'd want. You can also do it at scale because even though individual clients come and go, you should have a big enough pool of clients to keep all the bills paid. That part is marketing's problem.


A lot of our job listings for those positions receive a ridiculously low number of applications and even less are the people that show themselves interested in our outdated projects after the first interview.

Your company sucks. The job you are offering sucks. The pay sucks. Don't fool yourself in thinking it's the applicants' fault, or the interviewees' fault. It's you. Nobody even wants to apply for your jobs, the few that do, don't even want to continue to interview after a first meeting. You are not just failing to attract candidates, you are actively driving them away. (You're also in the midst of a period of lowest unemployment in American history.) You need radical change.

Our salary is well above average, for a senior could be up to the double of competitors.

Highly unlikely. Let's get real about salaries. Don't imply with hints and coded language, and make me guess. I don't know what your basis of comparison is. Tell me what you're paying. Are you paying people $350k+, 425k+? That would possibly be double. What's a "senior" at your company? 5-10 years out? Then how is that relevant to applicants or interviewees? What's the Xmas bonus -- 15% of salary, or is it a $50 grocery card?

We CANNOT change the stack of the projects and the language used

Which means you need to "buy" (i.e. hire) a scarce resource -- the people willing and able to work on older, outdated tech. Basic economics says a scarce resource will cost a lot more.

Now, there are people who would be happy to do this work. But, as other people have stated here, you need to 1) pay them a lot (i.e. more than what is comfortable for you) and 2) be ridiculously flexible with hours, location, vacation time, prior experience / willingness to train, acceptance of part-timers, older workers, and 3) publicize this -- like I said, don't make me guess what you're paying or whether I can work from wherever I want. And keep in mind, the people most qualified and competent are going to be the ones most able to demand higher salaries and least willing to accept rigidity like specific hours -- because generally, they are skilled, smart people who have had successful careers for a long time.

We work with multinational/worldwide banking and insurance groups

That's a big plus. They've got plenty of money right now.


To get someone to take a job, they must believe it is a good job for now and either:

  • Truly believe it will be a good job for the rest of their working life
  • Or believe it will not stop them from getting their next job

As no one can predict the following:

  • how long a company will be in operation
  • whether the company will be bought over and/or the work moved to another country
  • whether the employee will be forced to leave due to a bad boss
  • if an employee wishes to relocate due to a relationship etc

Most people are sensible enough not to believe a job is for life, unless they are only planning to work for a few more years.

The bottom line is this. Most employers expect people with up-to-date experience in the systems they are using... hence there is nothing you can do to attract and retain candidates, without giving them some work on modern systems.

Therefore you may need to take on additional projects that allow you to train all staff in modern systems and give them the experience while having them spend a few months a year on the "outdated" technologies.

Or maybe you can become the best employer in town for training, with everyone knowing that when someone has worked for you for a few years, they can get jobs with lots of other companies. You can also offer flexible contracts, free workplace childcare, part time work arrangements, the list goes on. Essentially making you the only employer in town that fits well with some peoples' lifestyles.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .