I think Integration Tests can some times be things that are written because they make people *feel* safe, but don't necessarily provide the gurantees of safety they appear to (you can't usefully write a test against someone severing a cable with a backhoe, after all). Our unease with ambiguity is perfectly understandable, but it often trips us up. One of the ways it does so is a tendency to want to shift questions into the techincal arena, that are predominantly human ones, rather than learn to live with them.
Maintanence of contracts is a human issue, and not something we ultimately have control over, especially if there are third parties involved (hard to avoid, and by now we should know that people can, and have, done crazy things). I think this points us in two directions. For the first, for the things we do control is to push leftwards, reducing implicit coupling, making code habitable, all the good things you have been talking about. In the other direction, I think we have to learn to accept that the only way we can know something is actually working, is to observe it doing so (i.e in production) and try to build something that can tell us when it isn't.
My first contact with that Shigeo Shingo quote was in the context of manufacturing. The example there is often that of a separate 'inspection' team hunting defects before material entered subsequent work steps. An inspection removed from both from where the defect is created and where it impacts.
So initially I was confused by your interpretation in the context of code. I would not have put the system boundary of the defect creation at the writing, but at the deployment of code. A great provocation, in the sense of 'thought-provoking'. Prior to your post I would have not gone beyond shrinking the boundary from 'deployed' to 'committed'.
You've previously discussed with me how the 'refactor' step of 'red-green-refactor' is essentially an aesthetic one. The 'red' is driven by the product, the 'green' by the 'red' but the 'refactor' is driven by these harder to grasp things in our heads.
I am hopeful that we can hone these senses regarding coupling. Since you've worked with us, our team has definitely started noticing and addressing coupling a lot more. We've started to listen for symptoms such as shotgun-surgery being needed to change something.
But is is often still only after broken tests inform us of coupling that we see it. So looking forward to see which language, perspectives and thought patterns you can unearth that shorten the feedback loop.
To make a completely opposite example that smells like design up front, you made me think that a big part of Domain-Driven Design is to use Ubiquitous Language(s) to make (de)coupling explicit without touching the code just yet: is the Customer in this Invoice the same Customer as in this Order, or do they follow different rules?
I think Integration Tests can some times be things that are written because they make people *feel* safe, but don't necessarily provide the gurantees of safety they appear to (you can't usefully write a test against someone severing a cable with a backhoe, after all). Our unease with ambiguity is perfectly understandable, but it often trips us up. One of the ways it does so is a tendency to want to shift questions into the techincal arena, that are predominantly human ones, rather than learn to live with them.
Maintanence of contracts is a human issue, and not something we ultimately have control over, especially if there are third parties involved (hard to avoid, and by now we should know that people can, and have, done crazy things). I think this points us in two directions. For the first, for the things we do control is to push leftwards, reducing implicit coupling, making code habitable, all the good things you have been talking about. In the other direction, I think we have to learn to accept that the only way we can know something is actually working, is to observe it doing so (i.e in production) and try to build something that can tell us when it isn't.
My first contact with that Shigeo Shingo quote was in the context of manufacturing. The example there is often that of a separate 'inspection' team hunting defects before material entered subsequent work steps. An inspection removed from both from where the defect is created and where it impacts.
So initially I was confused by your interpretation in the context of code. I would not have put the system boundary of the defect creation at the writing, but at the deployment of code. A great provocation, in the sense of 'thought-provoking'. Prior to your post I would have not gone beyond shrinking the boundary from 'deployed' to 'committed'.
You've previously discussed with me how the 'refactor' step of 'red-green-refactor' is essentially an aesthetic one. The 'red' is driven by the product, the 'green' by the 'red' but the 'refactor' is driven by these harder to grasp things in our heads.
I am hopeful that we can hone these senses regarding coupling. Since you've worked with us, our team has definitely started noticing and addressing coupling a lot more. We've started to listen for symptoms such as shotgun-surgery being needed to change something.
But is is often still only after broken tests inform us of coupling that we see it. So looking forward to see which language, perspectives and thought patterns you can unearth that shorten the feedback loop.
To make a completely opposite example that smells like design up front, you made me think that a big part of Domain-Driven Design is to use Ubiquitous Language(s) to make (de)coupling explicit without touching the code just yet: is the Customer in this Invoice the same Customer as in this Order, or do they follow different rules?