Software Delivery in Small Batches

You’re listening to this podcast because you want to improve. You want to become a better developer, manager, or leader. This podcast is a great start, but now I have something to help you find excellence. This is the official Small Batches Way study guide!
The study guide charts a path to software delivery excellency from the best books, ideas, and practices. The path is four parts: Understanding of TDD, Understanding of software architecture, understanding of production operations, and understanding continuous delivery.
Get it for FREE at TheSmallBatchesWay.com.

Hello and welcome to Small Batches with me Adam Hawkins. In each episode, I share a small batch of the theory and practices behind software delivery excellency.
Topics include DevOps, lean, continuous delivery, and conversations with industry leaders. Now, let’s begin today’s episode.

My team recently discussed the programming languages in our stack. This conversation can devolve into a tribal war based on personal opinions and experience.
That happens when people think individually instead of thinking about the team.
The individual side is just that: individual based on personal preference and experience. The team side is something else.
The literature shows there is zero correlation between language or technology and a team’s software delivery performance.
I’ll repeat this again: language or tech stack doesn’t matter.
The choices and way of working with the language or technology matter far more.
So in this episode, I’ll review the literature behind this assertion and close with guidelines around selecting a language or tech stack.
Also, because this is my podcast, I’ll spice it up with my hot takes on language and tech stacks.

First the evidence from the DORA reports mentioned in The DevOps Handbook and Accelerate. Both contain passages on language and tech stack.
The message is simple: practicing continuous delivery paired with trunk-based-development leads to the best software delivery performance.
That implies, at best, that language or tech stack is a proxy variable for achieving continuous delivery and trunk-based-development.
Let’s begin with a passage from Accelerate that addresses the technology choice question.
Discussions around architecture often focus on tools and technologies. Should the organization adopt microservices or serverless architectures? Should they use Kubernetes or Mesos? Which CI server, language, or framework should they standardize on? Our research shows that these are wrong questions to focus on.
What tools or technologies you use is irrelevant if the people who must use them hate using them, or if they don’t achieve the outcomes and enable the behaviors we care about. What is important is enabling teams to make changes to their products or services without depending on other teams or systems.
There you go. Focusing on which technologies is wrong. Instead focus on flow of changes to production.
Here is another passage from Accelerate. This passage discusses the characteristics that encourage fast flow to production.
It’s possible to achieve these characteristics even with packaged software and “legacy” mainframe systems—and, conversely, employing the latest whizzy microservices architecture deployed on containers is no guarantee of higher performance if you ignore these characteristics.
These “characteristics” are deployability and testability. You can achieve these with any architecture or tech stack. That’s on you. Thinking that adopting the latest technology or framework does not automatically make things better.
I’ve been on both sides of new technology. Adopting the latest technology means choosing more unknown unknowns which negatively impact testability and deployability. It’s not pure upside.
Just to repeat the point again, the technology, language, or architecture—whatever you want to group it as, does not correlate with team software delivery performance.
Here is another useful data point. Download a copy of the latest DORA report and search for language. There is only a single mention, and it’s about the language we use to communicate with each other. Mentions of programming languages are largely absent from the research. When they are mentioned, it’s in the context of allowing teams to choose which provide them the best deployability and testability.
This is what matters: achieving continuous delivery. The language or tech stack used is an implementation detail. Not the driving force.

Now, let’s consider my guidelines for leaders and management around choosing a language or tech stack.
These come from a variety of experience with different teams and stacks over the years. These guidelines aim for achieving sustainable continuous delivery across teams.
- Choose languages and tech stacks with the smoothest path to production
- Agree on two or three “gold” class stacks for the engineering team; appoint a champion for each
- Keep engineers competent inside these “gold” class stacks, investment in training as necessary; self-driven learning is great but insufficient
- Set buoys not boundaries with stacks; mark the well established path and let teams know the consequences of moving away from it
- Do not couple new product features to unproven tech stacks
- Experiment with new stacks within known domains
- Prefer components with planned release cadences that match your maintenance model (i.e. LTS releases, monthly, etc) and commit to it.

Now because this is my podcast, I’ll share some of my hot takes on languages and tech stacks.
- If the language does not have a generic map function, then I’m not interested
- If there is not a native HTTP server, then I’m not interested. I’m looking at you FGCI.
- Go and Node are a wonderful duo
- Robust test suites are more useful than type systems. Corollary: Typescript is a waste of time, your types mean nothing.
- The backend JavaScript ecosystem is a needless churn fest, approach with caution. The frontend ecosystem is even worse.
- Just don’t use MySQL. Use Postgres for anything new.
- The JVM is wonderful, Java is meh
- Prefer hosted Kubernetes over running it yourself
- Redis is not a cache, Memcached is
- Binary wire formats (such as Protobuf) are better than plaintext (such as JSON).
That’s enough of that. Flame me in the comments.
Outro
All right that’s all for this batch. Head over to https://SmallBatches.fm/94 for links for recommended self-study on software delivery performance, and ways to support the show.
I hope to have you back again for next episode. So until then, happy shipping!