Continuous Confidence in Software Development

There. I have said it. This is the elephant in the room. For years, we as Dev Ops professionals, and as an industry have been talking about how to up our game using Continuous Integration.  We talk about our Software Development Life Cycle (SDLC) or how we need to improve our QA Processes and deliver faster and with higher quality. We start implementing Continuous Integration and we try to implement Continuous Delivery and or Deployment. And you know what happens? We fail to do it the way others did. There are some examples that we try to wedge ourselves into. We try hard to mimic what others have done. And so we fail over time. Some of us, we get to where we want to be, but others...yeah...let's not talk about it! So what should we be doing? We should be talking about Continuous Confidence. We should be talking about what processes and what things are we doing that will help us get better confidence in our product. What will give others better confidence in our product. When...

Are there any of you out there who have attempted Continuous Integration, Delivery, or Deployment, and had it fail? Have you ever just given up because it was over complicating things? People were not happy? Believe it or not, this is very common. I have heard many stories where organizations have failed at implementing CI. So first and foremost I want to say: it's ok! We all recognize the value of what we get from doing CI, but in reality, in practice we need to be more practical and pragmatic in our approach. May I offer some counsel. Implement Countinuous Confidence This may seem strange at first, and probably expected since this blog is all about Continuous Confidence, but really, truly, this is he first step. Focus on your confidence points.  Generally, when I see failure in the CI world, it isn't the methodology, but rather the lack of confidence in the process that is causing the problem. Generally speaking, I see people wanting to implement CI in here organization becau...

Have you ever wondered why we have QA? I know, that's a weird question. When we look at what QA does, we are really asking them to do something we haven't done for ourselves: we ask for their vote of confidence. Consider the situation we put them in. We ask QA to review our application and tell us if there are any issues with it. We don't necessarily always tell them what we changed. If we tell them what we changed, hey don't always know how to test it properly, so instead, our founded confidence in them becomes, what I call, Bottleneck Confidence. Bottleneck Confidence Bottleneck Confidence is really just that, confidence that is restricted and not complete. This means that our confidence is throttled and limited to what we truly can achieve. So the question becomes: why do we need QA? Well, if we continue asking them to work in the same vein, then, we don't need QA. If we ask them to fill a different role, and allow us to reach our full potential, then they ...