I had a fascinating experience recently that really highlighted how far software development has come, and how some things haven’t changed at all. It began, as many of my days do, with trying to resolve a conflict between two technical teams who weren’t seeing eye-to-eye.
Normally, getting everyone in a room to clarify dependencies is straightforward enough, but this time, something unusual was at play.
On the surface, it seemed like a typical methodology clash: one team heavily leaned toward waterfall approaches, while the other embraced agile development. Easy enough, right? Just find common ground between methods and move on.
But as the discussion unfolded, it quickly became apparent there was more to the issue. Both teams, despite their methodological differences, consisted mainly of younger developers with around ten years of professional experience. And yet, the deeper we dug, the clearer it became that struggles to understand each other’s challenges was rooted not in methods, but in the technologies they were using.
One team was working with a cloud-based service UI, a modern SaaS environment where flexibility is the norm. Defining and changing fields in such systems is almost effortless: you can quickly roll back changes, validation updates automatically, and code provides clear flags and warnings. Fields are disposable, easy to manage, and quick to modify even at the last minute.
Contrast this with the other team’s world, developing for a mainframe system that has been around for more than three decades.
Here, field definitions are anything but flexible. Fields are strictly limited in length, difficult to modify once provisioned, and changing field types after the fact is practically impossible. In some cases, the system demands pre-provisioning fields en masse just to have some flexibility later, making every change a monumental effort.
This stark difference in environments had created a disconnect. Each team was frustrated, not realising the other’s technical constraints. The cloud-based team couldn’t comprehend why changing fields could be such a big deal, while the mainframe team couldn’t understand why the cloud team kept pushing changes that seemed careless and that made assumptions.
It was fascinating because usually, this kind of misunderstanding happens between technical and non-technical teams or between business stakeholders and developers. But this was a rare case of two technical teams misunderstanding each other simply because their platforms and experiences were worlds apart.
For me, it was a powerful reminder: integration specialists and project managers today don’t just bridge business requirements and technical execution, they also need to bridge knowledge gaps between entirely different technological eras.
It’s not enough to understand the technology you work with; you have to grasp the challenges faced by those working on completely different platforms, sometimes from a completely different generation of computing.