Opinion

Developers look at the technologies that companies adopt as one main metric when evaluating a collaboration. A decision based on this is too superficial. Do we really fear the technology? Or maybe we associate the company culture with it?
I want to tell you my story and what I would have lost if I refused to work in Cobol back in 2010 when I was 25.
Big city life
After university, I started working in a big company in Milan. I was working on a private social network, using the most recent Java technology stack. It was 2010: trending technologies in a trending market and a good working environment.

Unfortunately, in my gut, I felt bad. I was born in Valcamonica (Italy), among the mountains, and the big city life was not suited to me.
I knew about an old university mate that was working for a good software company there. I got an interview and accepted the offer. They were the leaders in their market. There was only one drawback: their core business was based on software written in COBOL.

Some of my colleagues in Milan said I was crazy and my market appeal would drop during the years. Luckily, I didn’t listen to them.
Do you want numbers on COBOL?
All of us are already aware of how much COBOL is in use currently. Due to the pandemic, we had an example in the U.S. of how this old language still has a huge impact on our society.
Anyway, this is irrelevant to what I want to tell you. I don’t want to convince anyone that COBOL is a cool language, because it isn’t. It is probably the worst language that I have worked with (technically speaking).
Which are the traits that make it so ugly? Why don’t software developers like to work with it?
The Problems
Let’s try to guess which are the problems that one may fear to face. I will list some situation that I had to deal with, during my experience:
- source code files long about 70000 lines. Many of those.
- Cryptic (sometimes funny 😂 ) names of variables and procedures.
- Cluttered and obsolete UIs.
- No data structure libraries (e.g. no dynamic arrays).
- Obsolete IDE
- No testing frameworks.
- Procedural Programming.
- Atypical data types (e.g. no int, float, double, string, char etc…).
- No support for defining new data types (i.e. struct in C).
- No functions with local allocation scope.
- Proprietary and obsolete persistence.
- Should I continue? I think you got the idea 😅
Change your perspective
Before asking yourself "where did I end up?", stop, breathe and look at that list from another perspective.
Those are problems only if they come together with the following sentence:
Here, we have always done in this way
This sentence is the only thing that you have to keep out of your working life. It is the symptom of the fear of change.
But if you work with people that embrace change, the points of that list are not problems. Those are all opportunities! And are so many!
The green field

The image above represents how I see a legacy project, owned by people with a good mindset. An old house, in a good environment, where your contribution will be appreciated. And you have so many ways to contribute.
No dynamic arrays libraries? You can build one! How many of you had the chance to put in production a dynamic array library? I did and it is referenced 23954 times in 1918 source files (and it is open source).
Obsolete IDE? A colleague of mine created a VS Code extension. Since then, the whole team adopted VS Code and it is way better than the official old IDE.
A list of some relevant topics that we had the chance to challenge:
- a library for dynamic memory scoped allocation (garbage collection)
- a new high-performance storage
- error handling design
- local API provider
- design of common functionalities for grids
- the adoption of versioning tools and then the transition to git
- the transition to agile methodologies
We always have to keep in mind that the limits are of the instruments. Not ours.
COBOL has low support from the community. Then, instead of asking "which framework/library/tool am I going to use?", the question is "which framework/library/tool am I going to build, and how?". In a certain way, it is more relaxing than diving in the framework jungle of modern days.
I had a dream
During university, I specialized in Computer Vision. I was dreaming of creating products for this field. But I also wanted to stay in Valcamonica, which is not exactly Silicon Valley.

Well, in the end, this is exactly what I did.

We have satellite products around the main COBOL software. Those are mostly written in C#. One of those performs automatic data entry from a particular kind of scanned documents. It has always been a strategic product for the company, but its production was external. It had a very high cost, and the supplier was, let’s say, "problematic".
My bosses decided to re-write it from scratch, internally. The activity was assigned to me.
That was an incredibly crazy… oh sorry… brave, decision. If we failed, we would have lost a strategic position in the market.
Luckily, we succeeded. The success of that operation was not because I built software good enough. I would have failed if I was alone. That was a team result.
We were substituting a product with a very high recognition reliability, also in case of bad documents. During the pilots, there were so many problems, but no one ever blamed me. My teammates absorbed the external strokes and put me in the condition to fix the problems, one after the other. With "teammates", I mean also managers, POs, help-deskers, and obviously other developers.
If I had refused to work with these people because of COBOL, I would have lost the opportunity of doing what I love to do, where I love to live.
Conclusion
The company continues to grow exponentially, we have new shiny offices, so many new colleagues, and international partnerships. I traveled Europe, started speaking in English daily, went to conferences, experienced many tech fields, and had much fun with colleagues.
Let me tell it straight so that I’m sure to send you exactly the message that I have in mind:
don’t focus on technologies, focus on people. You may be surprised!
Thank you for reading.
P.S.
One last thing… trust me… it is always better than Javascript 🤣! (Please no flame 🔥 , it is only a joke. I love to work also in Javascript 😜 )
Update 01/04/2021
I have been invited by Michele Riva to join his InferencePodcast on youtube. We spoke about Cobol, the array library, and the Test-Driven Development approach. Go to take a look if you are curious 😄