Cynefin Is A GAMECHANGER For Software Developers

I often describe software development as being complex and I mean it occasionally I meet someone who's a fan or at least knows about Dave snowden's kin framework and they asked me do you mean complex or complicated confusing what kind of activity software development really is is one of the biggest traps that organizations fall into all of the time and is certainly a billion doll but maybe even a trillion doll mistake kin is a tool that can help help us to avoid this bear [Music] trap hi I'm Dave Farley of continuous delivery welcome to my channel if you haven't been here before please do hit subscribe and if you enjoy the content here today please hit like as well there is a radical difference between how we should act depending on the nature of the systems that we find ourselves to be part of kfin is a complexity model that helps us to understand this problem better and provides some useful guidance for how to behave depending on the nature of the system in this case when we talk about system we're talking about everything not just the software systems that we're building but to software development as a whole as a system for making software the team structures the problems we are solving our understanding of those problems the organizations and cultures that we inhabit and that influence what we do and how we choose to do it the tools that we use the social context that we inhabit as well as the technicalities of the software systems that we create so this is already sounding complicated or is it complex the kfin framework divides the system into three groups ordered complex and chaotic it adds disordered as a category meaning we don't yet know what kind of system we're dealing with and this is where in my experience at least software projects often sit this is a big problem because if you're actually in a complex system and you behave as though you're part of a simple system you'll be doing the wrong things which will quickly migrate you into a chaotic system which is not a place that helps you to reliably achieve any good outcomes we're fortunate to be sponsored by equal experts and transic both of these companies offer products and services that are extremely well aligned with the topics and ideas that we discuss on this channel every week so if you're looking for excellence in continuous delivery and software engineering in general please do click on the links in the description below and check them out king goes on to divide ordered systems into simple and complicated for simple systems cause and effect works and is predictable the trillion dollar mistake that I mentioned at the outset is that most non-technical leaders attempt to squeeze the inherently complex activity of software development into that simple corner of the model assuming that making it a predictable cause and effect kind of activity is their goal it's my view that this can never work reliably at best they may very occasionally by dumb luck really produce something of value this way but in doing so they will have wasted huge amounts of time and effort presumably opposite of what they were trying to achieve King caused these five things domains and the newest version of this is clear complicated complex chaotic and disordered I confess the term simple to the newer framing of clear but the interesting part is really how these things work so I don't want to argue about the labels if I say simple and you prefer clear please bear with me simple or clear systems are well ordered enough that the same activities result in the same outcomes every time these are tightly constrained systems and the relationships are clear cause and effect are natural and obvious a always follows B which means that we can detect the existence of a categorize it and then respond with one of the best actions in this case b but this is only possible for systems that are sufficiently well ordered to be predictable the kinds of systems that we can build a production line for software development is by definition an Act of Creation we're not in the world world of simple systems here this is evident in lots of ways not least if you ask two different developers or even the same developer on two different occasions to create some software to solve a problem you'll get a different solution each time different answers to the problem posted so there are no idential best practices here that always optimally lead to success and that means that we can't categorize and fix what comes next in the process of building s something in software if we do the same thing that we did last time and last time was a success there's no guarantee at all that this time things will work out well there are so many variables at play here the problem may be different this time in subtle ways that we missed but that were important to the success of the original attempt the team will be different if not in terms of personnel at least in terms of their experience commitment and thinking or all of these things change over time so software development isn't a simple clear system maybe it is still ordered though so is it complicated rather than only simple in the complicated domain of systems what we really mean is that while it may be difficult to spot the relationships between the parts those relationships are still reliable and repeatable so the systems remain ordered given the same conditions which might be which might be complicated a still always follows B so if we control the variable sufficiently well we can get predictable results in system like these then what we really need is to collect relevant information analyze it to determine patterns and how things are related and then decide how to respond by applying some understanding and probably some expertise to choosing an appro appropriate response so given x y and Zed with X and Y related to zed via k14 then a still always follows B except once again this isn't how software works we can certainly gain some Advantage by moving aspects of software development into this more ordered regime but the whole thing no if I control the variable so that the same developer always works on the same component and so eliminate the variables associated with different developers working on the system then the output of that developer when working on that part of the system will be consistent won't it well no of course it won't the develop ER will learn new things so the developer this this week doesn't necessarily have the same skills and understanding as last week they may be feeling ill and so their skills might be worse or they might have learned something new and important and be doing much better than last week but software development is a creative act and so it depends on the Creator's performance on the day of creation this is practically impossible to know at a resolution of detail that really matters we've all had off days when we can't remember the details of the API that we use all the time or wonderful days when great code seems to flow from our fingers and in neither case could we ourselves necessarily know the reasons why however far we go in controlling the variables there's still variance and so no best practice here either worse than that there isn't really even any good practice because on the days when great code flows from our minds we should probably be doing different things to the days when we're stumbling over the correct syntax for a for Loop I think that most organizations fall into one of two traps they either assume that software development is simple and so end up being permanently surprised when things don't work out to plan however diligently they followed the best practices or they assume that software development is chaotic but in that circumstance usually all that they can think of doing in the midst of the chaos is to follow a plan anyway and so end up being constantly surprised because the plans don't work out in chaotic systems if you'd like to learn more about how to exert better control of your software development and avoid either chaos or the illusion of Simplicity then do check out my free tutorial on the fundamentals of continuous delivery there's a link in the description below chaos is as problematic as it sounds there's no predictable cause and effect the best response in these circumstances is to avoid trying to predict what will happen next and instead do something anything and then observe observe what happens and only then decide how to respond if you've ever found yourself trying to fix a bug and have no idea what's going on most of us in these circumstances find ourselves at some point randomly trying changing things in desperation to see what happens this is the correct response to chaos but is usually a fairly poor response to fixing bugs to be honest we certainly hope that software development as as a system is not chaotic but sometimes it is and part of the kfin model predicts this the line between clear and chaotic is different to the others it's meant to represent a cliff or discontinuity between simple and chaotic in Crossing from simple to complicated or from complicated to complex things are a little gray a little blurry it's not always exactly clear where the difference between it either of these things is but the difference between simple and chaotic is profound and clear in simple systems things are predictable and repeatable and in chaotic systems they are decidedly not do the same thing twice in a chaotic system and you get randomly different results the problem here is that one way to get to chaos is to treat a complex system as though it were simple because when you do this complex systems will change and respond in confusing ways that won't match your overs simple model and so things will seem chaotic even if they're not this is what what I mean by saying that people sometimes see development as being chaotic even though at heart software development isn't a chaotic system it's not chaotic because there are things that we can do to tame the chaos in a truly chaotic system there isn't anything that will tame it for example people often complain to me that they can't automate their testing because the system responds in non-deterministic ways except that isn't how software and computers really work they may seem non-deterministic but only under pretty specific circumstances and those circumstances are usually under our control to some degree usually what people mean when they say this kind of thing to me is that they've not controlled concurrency of their systems sufficiently to be able to run a test this may be simple to fix like avoiding race conditions by ensuring that a an asynchronous task is finished before you check for a response or it may be more complex needing you to rearchitecturing subsets of the system and so increase the system's determinism and through that testability but it is possible to control for these things if we care to do so I generally aim to avoid concurrency code mixed with the essential complexity of my own code this is one reason that I tend to like asynchronous event based systems quite so much because they make this easier to get this kind of abstraction there are five domains in the kfin model and we've eliminated three when it comes to deciding where software development systs as a practice the disordered domain means that we don't know which of the others we belong to so some team may certainly find themselves in this category but I don't think that that holds true for software development in general as a whole that only leaves us with one then complex complicated and complex systems sound very similar but they're not because in this context what we mean by complex is complex as in complex adaptive systems in comple domains cause and effect can only be deduced in retrospect because the patterns and relationships are so difficult to discern so intertwined that a change in one place causes the system as a whole to respond to adapt to the new circumstances so when you try the same thing a second time the system as a whole is now different and so we respond differently the start conditions of each attempt changed in seemingly unpredictable ways but in ways that are nevertheless still based on cause and effect the problem with complex systems is that we can only discern these causal relationships in hindsight so the correct behavior in systems like these is to probe sense and respond to carry out small controlled experiments probe use them to come up with some facts so that we can figure out how things change when we do something if if we increase response time the user may think that their job wasn't completed if they're used to waiting for a long time for the result if we add a new feature aimed at our followers on Twitter someone may buy Twitter and make it a less popular platform these things may seem random but they aren't really in that they will remain stable until the system changes again so to understand the impact of each and every change we need to monitor its results so that we can sense what's really going on we need to collect the results of our experiments to discern a plan of to proceed based on our understanding that we've now gained this is how science and engineering really work this is how successful software development really works too software development is a as a practice is a complex adaptive system we can see this everywhere that we look a change in requirements May mean that our design doesn't really work anymore and is now a poor choice even though moments before this new feature was identified it was all working fine the technical bug in the transaction boundaries of a distributed system may end up with people being wrongly convicted of Fraud and going to jail we may believe that we know the answers but however smart we are until we try our ideas out we can't really be sure but all this means is that the safe course of action for software development is to treat it as a complex adaptive system to organize our work into a process of probe sense respond which means working experimentally and that means working in small steps Gathering feedback and figuring out where each small step leaves us if you spend any time at all watching videos on this channel that should sound pretty familiar to you by now this is really the idea at the heart of continuous delivery and modern software engineering the approach that we recommend here try stuff out see what works and only then decide on what to do next build on knowledge not on guess work the process of software development is not a simple predictable cause and effect system so attempting to treat it such with Gant charts and monthlong year-long plans is doomed to failure instead we should organize our work more defensively on the assumption that whatever our guess is whether those guesses are about the nature of the problem that we solving how we should organize ourselves to do the work whether or not our designs will be secure resilient iant or fit for purpose and whether or not our users and customers will find what we are doing useful helpful or interesting then all of these guesses may be wrong so how can we tell where and how they are wrong and what should we sensibly do next when we find the mistake this is by far more the more effective more efficient way of making progress and is ultimately while continuous delivery really works and really matters thank you so much for watching and if you enjoy our stuff here on the continuous delivery Channel please do consider supporting our work by joining our patreon community there's links to that in the description below too and thanks as ever to our patreon supporters it's with your help that we're able to make this content thank you [Music]

Channel: Continuous Delivery

Views: 45,522

Keywords: cynefin, cynefin framework, cynefin framework explained, david snowden, david snowden cynefin, what is the cynefin framework, software developer, software development, software engineer, software engineering, programming, dave farley, continuous delivery, modern software engineering

Id: MRwZQGdllDY

Length: 16min 49sec (1009 seconds)

Published: Wed Apr 17 2024