Monday, August 5, 2019

When Four Should Be One

There's a piece of wisdom that runs by the name "Conways Law". Conways Law states that organizations (or rather, communication structures in those organizations) will constrain software architectures so that your organizational structures turn into your software architecture.

For the moments when I was thinking we were somehow less impacted, with our relative success of having an internal open source model, I realized that while the architecture may not follow the manager-assigned organization, it still is very much impacted by communication flows and power structures that exist.

Our system test automation structures, however, don't fight the Conway's Law at all. Someone drew four separate organizational units, and at worst, I can go find four slightly different duplicates of similar tests. This post is my pamphlet to going into a war against these forces, when I really just probably should be making the organization pull a inverse conway maneuver and changing how the teams are structured.

I work in a situation where I have four, but I should have one. I believe that this would change by first changing the way we visualize the four, now as one. It would immediately follow on getting the three and the one most separated together. And then the hard work of introducing a new model of understanding what is an application test, what is a product test in a way that is not product team specific.