Thread by @davefarley77

Dealing with "Coupling" is one of the things that makes SW a genuinely difficult activity. But I think Coupling is at least as big a deal for SW dev teams as it is for the software itself.

Here's a #Thread

1/14

Coupling is an interesting idea, and there are many dimensions to it. I particularly like the @mtnygard model of coupling described in this video, and have been quoting it for years.

2/14

At its roots the management of coupling is, I think, one of the deep fundamentals of design. Skill in this is what differentiates great SW design, from average or poor design to a large degree.
3/14

I argue in my latest book that the ability to change our SW is the defining characteristic of its quality. Sure you need more, but if you can't change the code, the only alternative is that you have to get the 'more' by being perfectly right first time. Good luck with that!!
4/14

In SW though, there are ways that help us to deal with coupling that we are more familiar with. For example, #ContinuousIntegration allows teams to work on more coupled SW, by validating that our small changes don't break things.
5/14

Types in languages allow us to know where change needs to happen between more coupled bits of code.
All this is complex enough, but for people, teams and org structures, this is an even more complicated problem.
6/14

The classic response to "scaling dev" is to divide work into specialisms: Biz, architecture, UI, BackEnd, Testing, Ops and so on.
This builds a series of silos that EVERY FEATURE must pass though, this is a lot of people who's work is dependent, coupled, to everyone else's.
7/14

Progress is difficult, I can't write the code, until I have a UX design, I can't test the code until the devs tell me it is "dev-complete" and so on.
Worse, I can't improve the design, because the plan is based on the current assumed design.
8/14

One way of thinking about what agile development, based on small, autonomous, teams is really about, is that it is about distributing decision-making - decoupling for teams & orgs.
9/14

Great dev is very significantly about reducing the scale of change. Small teams matter because they are more independent (more decoupled). Small changes matter because each change is less entangled with others (more decoupled).
10/14

If your work relies on the work of other people outside your team, before you can make progress, your dev system would almost certainly work better if it was more loosely coupled.
11/14

Managing coupling is the foundation to scaling SW well, and to scaling software development too. Autonomous teams, who are responsible for the software that they create work best to scale, *because* they are decoupled.
12/14

One aspect of many aspects of this is covered in my current video, which describes one way to decouple a common over-coupled get keeping approach to dev, through non-blocking code reviews.
Thanks to @tdpauw for pointing them out to me.
13/14

You can read more about the role of coupling as one of the 5 techniques for managing complexity in my book "Modern Software Engineering"
14/14
amzn.to/3hKezti