Why are there so many IT jobs?

Thirty years ago, I embarked on a journey into software applications and product development in the banking world. What began as work on one of the world’s most successful banking products soon evolved into a career filled with rapid technological advancements, each reshaping how we built and delivered software. Today, as I reflect on the evolution of this industry, I’m struck by how far we’ve come—and how some aspects of the software development process have remained curiously similar.

When I joined, our company already had a strong banking product, but it was rooted in old technology: Business Basic, flat file databases, character-based screens, and hardware setups that seem primitive by today’s standards. These systems ran on “dumb terminals” with only keyboards, no processors or hard drives, and no graphical interfaces. All the code resided exclusively on the server.

As GUI-driven systems, relational databases, and object-oriented programming began to emerge, our team decided to reimagine and build a new product with Smalltalk and VisualWorks and GemStone object database . However, after an architecture review from consultants from the western world, our management decided to pivot to Oracle Forms and Oracle Database—a wise choice that would propel the product into the global banking software spotlight.

At the time, client-server was the dominant architecture. The client application ran on the user’s desktop, while the server housed the database and core business logic on a local network. The architecture, though limited in scalability and demanding in network bandwidth, was workable for our needs. Amazingly, this setup allowed a 40-person team to develop the core banking product on specifications like:

• Client: 32 MB RAM, 2 GB hard drive
• Server: 256 MB RAM, 12 GB hard drive

With such modest specs by today’s standards, today’s average smartphone has more computing power than our entire infrastructure did! My phone now has enough hardware for a 100-person team of yesteryears. To cope with bandwidth limitations, we relied on technologies like Citrix, which allowed users in one country to access data housed in a data center on another continent. Integration with upstream and downstream systems was supported, though online integrations were nowhere near as advanced as they are today.

Today, I no longer code, but when I see development estimates, they often seem to be 10 times what was required 25 years ago. Have back-office banking product processors changed significantly? I don’t think so—I am not referring to customer-facing applications accessed over the public internet. Back office applications have largely remained the same - they run on the intranet and have a bunch of user interfaces for transactions, complex programs for processing interest, charges etc, some customer outputs like advices and statements, some reports - maybe more APIs. 

This begs the question: what’s driving this exponential increase in development time and resources? Here’s my take:

1. People: Talent and skill levels may not have changed significantly, though specialization is now more common.
2. Infrastructure: Despite the limited infrastructure, we worked around it. For example, many of us coded between 9:00 p.m. and 1:00 a.m. when the servers were faster. I recollect complex screens could take over an hour and a half to load and compile and though a bug fix just took 5 minutes to fix, it took around two hours to start to test it. 
3. Process: Development processes are largely unchanged, though they have been rebranded as sprints, user stories, CI/CD, etc.
4. Work Culture: Back then, work was exclusively in-office, with long hours and sometimes late shifts due to limited infrastructure availability. People probably worked for longer hours (including weekends) but then how much harder - the day had 24 hours and the week had 7 days then too.   
5. Technology and Tools: The software industry has mastered the art of creating “FOMO” with new frameworks, languages, and tools emerging constantly. Modern applications now require an arsenal of technologies, increasing the effort needed to develop and maintain them.  Back in the day, our tech stack was relatively simple. Development involved desktop a IDE, a single database, manual testing, and version control with tools like PVCS. Builds were generated using Unix and Windows scripts, and documentation was managed in Word and Excel. Today, a ton of technology components and another 3 tons of third-party libraries and new tools for code coverage tools, security scanning, CI/CD pipelines, and other specialized software—have enhanced capabilities but also introduced new complexities on unimaginable scale. At the end of the day, we need armies to manage all of this.

Years ago, I read that the total computing power used to send Apollo 11 to the moon was less than what’s in an average laptop. Reflecting on my own career, I understand this hunger for hardware as technology evolves. Not just hardware but also people - closer to 10X number of people! That's hard to digest.

Interestingly, it is said that over 70% of the world’s business transactions run on COBOL. Now, that is something to ponder about!

Thank you for reading this . It is my first article on such a topic - I hope you found it insightful. I would like to thank by first and only employer, work colleagues and the one and the only Ramesh Srinivasan - my supervisor, guide, colleague, friend and the GOAT of banking technology. All of us who worked with him owe a lot of our abilities to him. He was 10X 25 years back and a conservative estimate is that today would have been 100X. Sadly we lost him 18 year ago.

Before I miss out, I need to thank ChatGPT for helping me in articulate my writing much better than I could have.