A meme that tends to ricochet through Civic Tech Circles involves criticizing volunteers or consultants for using a new programming language or library that the existing organization is unfamiliar with. In some cases the organization has a programmer or two on staff, in other cases none at all. The well meaning criticism implores people to adapt to the environment they are helping in and “meet folks where they are.” Unfortunately it ignores the needs and motives of the helpers. The trade-off organizations face is not “pick a programming language” but “accept help or do not execute on the project.”
Why It Matters
As a leader you need to understand the trade offs and options when embarking on a software project. Especially one that is run by volunteers or a new group of consultants. How much trouble are you actually signing up for by having apps written in multiple languages? How big of a factor is this in short or long term success?
Many Experienced Programmers are Polyglots
Technology, especially software, does not stagnate. Programmers will have their favorite tools the way George Harrison has a favorite guitar, but rare is the software engineer that has not had to code in an unfamiliar language or library. The ramp up time is going to be much higher to work in the unfamiliar, but many of the general principles are the same. It’s not insurmountable. In a large number of cases the cost of learning how to code or fix an existing program is going to be less than rewriting it in a familiar language. Do not let people convince you that programmers cannot learn more than one language or library.
It’s Not a Mess, It’s a Micro-services Architecture
Much of the pain of transitioning between languages and tools has been mitigated with the rise of DevOps, specifically tools like Docker. Docker lets you programmatically write and document what libraries and type of computer you need to run an application on a server or for development. Where apps previously require a lot of setup to work, Docker (when used properly) provides a shortcut to save you the research. When done well
docker compose up is all you might need to run something. Even when written in different languages your app probably communicates using HTTP, has a REST API, and stores data in a SQL database. Regardless of language, web applications should be deployable to the cloud and able to communicate with each other. Where other folks see a mess, I see a micro-services architecture.
The Benefits of Standardization Accrue at Scale