DevOps: Build Bridges not Silver Bullets
I've lost count of the number of times I've had or heard a conversation along the lines of:
Bob: I have this problem to solve, I've had it before quite a long time ago and I know others infrequently experience it too, or something like it.
Alice: Sounds like a candidate for automation.
Bob: I know, but when I have the problem I'm always under pressure to get past it - I can't really spare the time to automate it, even though I know it will be useful in future.
Alice: But if it's going to help others too, surely that's enough to justify taking the extra time now?
Bob: Other people don't have the exact same problem and I don't know enough about what they need to build something that would help them.
The final exchange tends to go one of two ways:
Alice: Oh well, I guess if you just need to fix it then fix it - maybe you'll be able to do it properly next time - or someone else will in the meantime?
or
Alice: Just worry about solving your problem, once people know what you've built they'll be able to tweak it to solve their variation with much less effort than if they had to start from scratch.
Building a system that solves even just 10% of a problem is a worthwhile endeavour, but it's often easy to defer such plans until you have time to solve more of the problem space or even just to know what that remaining 90% actually is!
I don't say this simply because the 10% delivers more value than doing nothing (though obviously it should!), but because I believe that the mere existence of the system is the long-term value. It does more to encourage others to use and improve it than the value they derive from the 10% solution itself. Each such contribution notches-up the direct value from the solution itself and spreads the knowledge across more people.
I find this is particularly true with automation systems. Much of the effort of building a robust automated process is not necessarily in the automation that addresses the problem itself, but in the plumbing and processes that tie it all together and allow it to be easily used and maintained. This can be compounded when such plumbing may touch technical areas that an individual is unfamiliar with, despite otherwise being well-placed to solve the actual problem.
This is the 'barrier-to-entry' problem and is why many things don't ever get automated.
By understanding the psychology of these situations, if you're someone who is comfortable with automation 'plumbing' then don't be put off from doing something just because you can't solve the whole problem - there are likely many others who will gladly collaborate once they see that a foundation has been dug.
Given the title of this post, it might seem a mixed metaphor but the bridge in this context is the one connects the world of this 'plumbing' (concerned with having effective, maintainable automation) with the world of a particular problem domain. Once joined, each world can now see the contributions of the other and hopefully broaden their horizons so they can build their own bridges in the future - and so the virtuous circle continues (hopefully!).
