Thoughts from a life in software

When we develop libraries & tools we define various means to interact with them. We do this by thinking about use cases and so we build in assumptions in how we expect our target users to typically interact with our work. In this sense everything built has an intended way of being used, a workflow.  When we want to achieve a goal, we should be asking ourselves how we want to solve the problem and looking for things which enable that approach. If we are constrained in the tools/libraries we can use, we should focus on how those tools are designed to solve the problem. The problem I've found is a lot of teams chase workflows which make no sense when combined with their tool choice. For me a great example of this was GitFlow branching strategy, because I have seen so many teams independently repeat exactly the same mistake. I'm going to take you through a bit of history to explain the issues. Trunk Based Development Before git existed, every source control management solution ...

On a Monday morning I went into work to find one of the systems down and it reminded me of one of the rules I had developed working out the 'Ops' side of DevSecOps. A lot of people gain experience in Operations, managing applications, these tend to be fairly limited in their scope (e.g. UI -> Middleware -> Database). this kind of system is typically event triggered and so changing the system and making a few calls against the UI will quickly test the entire chain of components. This allows you to immediately confirm the change was successful.  However as systems become more complex, a typical pattern I have seen in a few Open source and proprietary systems will create distributed state machines, typically there will be multiple services which require data to have certain fields with specific values. The service will then perform an action and once complete update the data object. Once you have a sequence of services operating in this manor you have a state machi...