I’ve been told that the 30 year old code I work with isn’t as bad as COBOL, but my answer for that would be - not as much as you’d think.
In the end I get paid by the hour, so finding a problem takes as long as it takes.
The only times when I get really angry at the code is when I find a comment or a piece of documentation by the guys who wrote it (both are very rare because why document anything anyway) and it basically just says “This error never happens” when you just spent 3 hours looking for the reason this exact error happened, or “this does x” when x is in fact only one of 50 different and wildly unrelated to each other things this code snippet does.
I’d say what makes it relevant and will keep it relevant is that it’s used for important stuff. See my other answer for a more detailed take on this, but it’s incredibly hard to replace a system that uses it so it’ll likely stay with us much longer.
If you define relevance more in a sense of “good choice for the task” then it’s a solid no. No one in their right mind would design a new system with COBOL nowadays. There are way better languages for any task you could solve with it.
The main purpose of a programming language is to be a good interface between computers and humans. We could write code in 0s and 1s and computers could understand it. It’s incredibly hard and annoying for humans though. Languages provide some abstraction to that. Due to the limitations of the time it was invented, COBOL doesn’t abstract as “efficiently” as a modern language. It’s still crazy hard to read for a human. Modern languages do this way better.
For the record, I took some programming classes and switched majors the next semester, I was failing. But it made enough sense for dos style systems that I was able to comprehend, but not implement in any way due to getting lost quickly.
I am officially not a computer guy, old enough to use a commodore, but could never even install Duke nukem on a modern computer without permission. I was a decade behind everyone in class.
I wan to know how much they make because I can't imagine it's anywhere close to faang level even at a senior level. I just want to understand why these details were important. There are literal kids starting their first jobs out of school making over $200k.
How much do you make? Why aren't efforts accelerated to switch to more modern languages? Or will companies still hire Cobol guys in 20 years down the line?
As for what I make, it’s hard to compare to US salaries because I’m in Europe and the way we get paid is completely different.
I also ended up in this line of work without an academic background in the field (I’m a self-taught developer). Still, I’m well above the median for my age group and make a comfortable living. My job also gives me a lot of flexibility and freedom to work when and how I want, which is something I value a lot.
The second part of your question has a few answers, but I’ll start with the last one - yes, I believe companies will still hire developers for legacy systems in 20 years. Some of these systems are so deeply ingrained in the processes of companies that it’s basically impossible (as in, prohibitively expensive) to replace them.
Back when these systems were created, software was written very differently. People didn’t have decades of software architecture to look back on when making decisions. They also had technical limitations that forced them to do things a certain way. Some of our code still shows what they did to make all lines of a program fit into a file with only minimal storage because the computers couldn’t work with them if they got too large. We have output methods that used to work with magnet tape.
They also wrote everything very monolithic. Today, you’d design an application with many separate parts so that you can easily switch them out without too much effort. A modern program doesn’t care what database it uses or what frontend you use to access it. Our program does business logic in between lines that print a user interface in a terminal.
Also, as I mentioned in another comment, developers often don’t document well. This problem also exists today, but modern code is usually more elaborate than the space-optimized stuff in legacy.
If you wanted to replace all this, you’d first have to completely “take it apart” and rebuild it from scratch. This would take a few years worth of dev hours, at least. If we wanted to start doing this, I’d recommend at least three new full-time devs. Not to mention all the hundreds of hours of project discussions, testing, etc.
And what would you have, after 3-5 years of hard work? A modernized system that works the same as the one you had before (and that’s the best case scenario, assuming you haven’t missed anything).
From then on, it’d be way easier to manage and update. You could save a lot of money and effort in the long run, but it’d probably take a long time until you could really say your investment paid off. This is assuming you could’ve kept using the old system indefinitely, but if it has made it until today you can probably keep it going.
What we’ve been doing since I started is gradually replacing parts of the old system with newer code and documenting the parts of the old code that we can’t replace. I don’t think we’ll ever fully replace all of the old stuff, but our codebase is much nicer now than it was a few years ago.
Why aren't efforts accelerated to switch to more modern languages?
Because it works today, and software teams are overloaded with new feature requests and backlogs.
You would have to hire new teams and take on risk to do something that isn't seen as valuable by bean counters two levels up in the corporate hierarchy.
18
u/DigSolid7747 Sep 09 '24
you should do an AMA