When we say that software is in a golden age, we are usually speaking in awe of programs that allow us to create images of anything, just with words, or software that can beat us at games we’ve been playing for thousands of years.

Those in the industry will also no doubt acknowledge that it’s a golden age for tools, as well. And that doesn’t just mean the majestic Kubernetes; alongside it we have an embarrassment of applications, languages and services that make the life of any developer easier…and dare we say it? More fun.

But in some ways the richness of thinking about software development is also indicative of a golden age of processes. (It might even be argued that many of the software breakthroughs we have seen in recent years were only possible because of improvements in process.) We are seeing not only a growth in ideas and concepts, but a fertile interaction between them as those ideas and concepts overlap.

A great example can be seen in the book Team Topologies.

The general thrust of the book is that you should decide on a product’s architecture first, and then structure your teams in order to build it.

It’s a simple idea, and is based on cheekily taking advantage of Melvin E. Conway’s adage that an organisation will always create products that reflect its internal structure–instead of being victims of this law, the authors Matthew Skelton and Manuel Pais urge us to make use of it, by flipping it on its head in an activity they call a ‘reverse Conway manoeuvre’.

If this idea was the whole show, then you’d barely need a blog post, never mind a book. But what the authors do exceptionally well is to look at best practices for software architecture and then present various team structures and modes of communication that would help to implement those practices.

This is exciting in itself, but the reason I feel we are entering a golden age of practice is that many of the approaches to team structure and communication presented in the book align perfectly with ideas from Domain-driven Design. Instead of trying to sell us the latest snake oil and then moving on, the Team Topology project consciously builds on established ideas from DDD, showing how they can be manifest in real teams, working on real projects, building real products.

And it doesn’t end there. The book contains concepts from Kanban, refers to DevOps science by way of the excellent Accelerate, brings in SRE-thinking and platform engineering, and much more besides.

If we are to do justice to the riches we developers have at our fingertips–by creating great products–we will need to make it easier for many, many more people to get involved and be immediately productive. As a consequence, processes and team-building will be an important area for the next phase of product development, making it crucial that new ideas in this space both integrate, and build on others.