There has been a lot of hype about Non Fungible Tokens (NFT) in the crypto space. Conceptually, fungibility applies to software engineering skills as well– I will explain that soon, however before that we should establish the meaning of fungible versus non-fungible.
Fungible: Means the thing/product/item is replaceable by an identical item. A classic example are the dollar bills. A one dollar bill is the same as another in terms of value and where/how it can used though they are physically different pieces of paper.
Non-Fungible: Means unique and not replaceable. An example is a Derek Jeeter signed home run baseball caught by a fan in a game. It is unique and there is no other thing like that in the world.
How do the above concepts apply to Software Development within a company? Software Engineers (not as people since everyone is unique) being fungible means that they are able to to develop software capabilities across many areas within the company quickly. Friction points for quick quick delivery comes from the tools, process and subject matter expertise. While the subject matter expertise takes time to develop, tools and processes are easier to standardize/automate to make Engineers fungible across the company.
Software Engineers develop code, unit test, deploy software, run tests, and configure monitoring/alerting for abnormalities. There are multiple tools for each of these activities. If the tools they use for the work are different in each team, they have to learn the new tools and processes when they make changes in another team’s codebase. This adds to their ramp up time and reduces their productivity. Large tech companies invest in developer tools to take away this variable. Having the same tools and process combined with automation allows Engineers to get their changes out to production quickly, making them fungible and far more productive contributing to increased velocity of delivery.
Most companies outside of the big tech companies don’t invest in developer tools. They get too hung up on the tactical ROI/business case instead of thinking of the long term. Engineering leaders should continue to beat the drum on the long term benefits and do it incrementally demonstrating the value over time.