Culture Challenges + Software Solutions = Technical Debt

Over the years I've been on various teams that closely interact with engineers that are not software engineers, but need to embrace software practices or tools to some degree due to their project goals. Often this comes in the form of writing code, packaging and version control. I've also had conversations many times about the layers of abstraction we build on top of these tools or practices to help make it "easier" for non software engineers to use. For instance if we create a template test setup (test discovery configured, test directory setup, example test in place) everybody will write more test.

More often than not what I've seen is that the team ends up maintaining these templates and abstractions with very little engagement, but consistent maintenance to make sure these tools are aligned with the teams latest practices and in changes in the language ecosystem tool chain.

What seems to go unrecognized is that this isn't a technical problem to solve with software. The tools (and hopefully documentation) exists. This is a culture and education problem. Every time I've seen this happen the target audience for these abstracted tools and templates are very intelligent individuals fully capable of using the tools. However, that doesn't mean they want to use the tools. Solving skill gaps is done through education and hands on experience. However, if people don't want to use these tools, or do this kind of work ("I'm not a software engineer, I just write algorithms not test") that's a culture problem, how you handle that will differ per person and organization, but recognize trying to solve these cultural challenges with software will likely on lead to cost and maintenance for your team that is likely a net negative on resource commitment.

Work through cultural challenges through personal engagement and change mechanisms, not with software. Culture Challenges + Software Solution = Technical Debt.