Architecture choices for cultural factors
I was having a discussion with one of my team members. He questioned some of our early decisions which predated his involvement on the project. I began to give him a bit of history of the choice and realized, while I was explaining, that some of the benefits were never realized. We made other choices which limited our ability to leverage those benefits and over complicated certain areas which eliminated efficiency gains which were expected.
This particular example related to a set of templatized ETL integration jobs. We took concepts of code re-usability and modular design, which are good practices, and wielded them like silent weapons to carve out smaller scopes of responsibility.
Our team’s imbalance of responsibility can be seen in our templates which turned into a way for engineers to minimize their scope of work to guarantee success while burdening the heroes with the responsibility of the common components and overall functionality of the templates.
This created an environment where no one ever felt 100% responsible for the successful execution of their own integration, in the production environment. Development decisions based on team pain-points brings the risk of blending cultural or managerial issues into the technical choices.
In part 2 of this series, I wrote about the need for design reassessment after walking down a path of incremental change. Our current reality is a Frankenstien’s monster compared to the original vision of the templates and has caused a large portion of the team to not even understand how the processes run. Others, such as the person whom I was speaking to when I realized this, were wondering why we are making our own lives so hard when simpler methods are readily available.