24 February 2019
Should teams choose their own languages and tools?
Many organisations expect engineering teams to stick to an approved list of languages and tools. This can feel strange given that the decision is such an important part of technical design. After all, you are making decisions about the capabilities and performance of the system.
Much has been said about the pros and cons of polyglot development, where engineers become expert in many languages. This allows them to pick and choose their weapons for greater flexibility and more targeted solutions. If you’re serious about building a development culture based on self-organising teams, surely engineers should be free to choose how best to tackle the problems in front of them?
Is language diversity inevitable?
Some degree of polyglot development is inevitable, particularly in cloud environments where no single language or framework suits every scenario. General purpose stacks such as J2EE\Oracle and .Net\SQL Server have been challenged by a Cambrian explosion of tools and ecosystems that address more specific purposes. The choice can be quite bewildering.
Some organisations engage with this diversity by adopting more than one approved stack. For example, “goldilocks governance” can define a stack based on Node and MySql for small projects while insisting on Java and Oracle for larger builds. This may give the impression of flexibility, but it’s not devolving the decision to the people who will be building the system.
Approved lists of technologies are often motivated by the desire to reduce complexity, manage costs and streamline development. The problem is that this can give rise to a technical monoculture where teams use the same hammer for every nail, leading to inefficient and inflexible solutions.
There is a trade-off here between flexibility and longer term maintenance. A service that remains untouched for a couple of years can suddenly become a support headache when you try to unstitch the technology used to build it.
From a management perspective, there is a concern that technical diversity can make it difficult to recruit the right engineers and maintain an appropriate balance of resources. This might reflect a world view where engineers are regarded as replaceable machine parts. A diverse stack can be a virtue if you are keen to attract inquisitive engineers who embrace unfamiliarity and aren’t afraid to take try something new.
There is a place for standardisation…
Standardisation does have a place, but it should be reserved for infrastructure and collaboration rather than languages and tools.
If services are going to collaborate then there needs to be agreement over the “rules of the road”. This includes communication protocols and security aspects such as authentication. If you want to be able to trace requests between services, there must be consensus around operational concerns such as logging and monitoring. Adopting a common infrastructure can also help to improve your purchasing power with vendors to lower cost.
Unless you take Amazon’s “you build it, you own it” approach then application delivery is not an exclusive concern of engineering teams. Operations teams should have a say in how applications are deployed and managed. Architects need to ensure that the spread of data, services and protocols add up to a coherent whole.
Standardisation can help to set expectations for the external behaviour of services. Containers can define a clear demarcation between engineering and operational concerns. If an application follows twelve-factor principles the language and frameworks used are immaterial. Nobody cares about implementation detail if a service follows simple convention.
With freedom comes great responsibility
Supporting a polyglot approach to development involves placing trust in development teams. This can be problematic for some. Engineers can be a little too keen on novelty. There’s also the ever-present fear that CV-driven development will take hold
These risks are overblown and may driven by a tendency to mistrust the unfamiliar. Senior managers are often ex-engineers who have lost touch with technical detail and have forgotten how it feels to have solutions imposed from above. If you don’t trust engineers to make responsible decisions, there issue may in team composition rather than a need for more governance.
In my experience most engineers are incredibly conservative. Any experienced engineer will have battle scars that discourage reckless decisions. Engineers often stick with the tools that have served them well in the past and are unwilling to take a chance on anything new. More often than not they have to be encouraged to adopt new technologies rather than being restrained from doing so.
This can give rise to an ossified technology culture. Systems never evolve and new ideas never get the space to breathe. Innovation requires some level of risk and you need to encourage a culture where teams have permission to try something new. They need to feel supported and know that they won’t take the blame when problems crop up.
What really matters?
An organisation should define a clear boundary for engineers. This can be surprisingly wide when you consider what really matters in the long term. You need to keep the cost of change low so you can reverse out of bad decisions. You need some agreement over how managing services in production. You need services and applications to collaborate without friction. You also need teams to embrace iterative development and automation.
None of this demands that teams use the same development languages or frameworks.