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...

Continuous Confidence is an ideology, a process that changes and is different in each development shop. When we want to implement it, we need to flip our thoughts around and start by asking the question: Why do we release code? The Essential Question This question is the most essential question we can answer. This will ultimately drive our implementation. Some might answer this question with the easy route: to make money! Some might answer this with the statement: to rule the world! Whatever the answer is to this question, be honest and fair and precise. Answering this will show where the motivation is. Whatever the response, we find that we cannot do this without the customer. We find we cannot do a release without other departments and roles. We find that, in reality, we are far more impactful on others more so than just the development team. So we start to ask more questions from our experiences. How often should we release? Each software that is created is different. We mig...

At the very heart of Continuous Integration and Continuous Confidence, is the automated test. Why do we write a test? If for whatever reason we write a test just to pass, then we are doing it wrong. Let's explore that for a moment. Superfluous Testing When we write a test, do we test a getter and a setter? If we answer yes to this question, then let's ask: why, followed by do we have to? Now, these questions need to be answered by each organization, as each requirement is different, but we want to look at something different. We want confidence in our code, and in our release. If we were to draw a line from left to right and say on the left is 0 confidence and on the right is 100% confidence, how much confidence do you gain by testing that a better or a setter worked? Put another way, would we ever write a test that simply returned true? Now, there are some getters or setters that have logic in them, points where decisions are made and a code bran is taken. That's o...

Quality Assurance has always been a conundrum since the day the first QA engineer came into existence.  We can imagine how they came to be. In The Beginning A bunch of developers were writing code. They all realized hat they needed to have some tests written and so they elected a specific developer to just write tests on their code so the others could keep going. Over time that poor developer lost their perspective and their knowledge of the code base. Once an engineer finished their work, they would pitch it over the wall and expect a report back by the end of the day, even if the end of the day was in 15 minutes. So over time, QA became viewed as a substandard position, a dead end for a career. Recently, that has started to change. Misunderstandings We want to focus for a moment on what QA is really doing, and perhaps we can find a better definition and role. Remember, in Continuous Confidence, we want to use people to their full potential and thus we will redefine what pe...

When we first started down the Automated Build and Testing scene, we became very addicted to that wonderful thing: the green build. We installed tools like Jenkins or later GoCD or even rolled our own, but we loved the power of that green build. We said: ship it! Let's get that code out in the wild! Look it passed all the tests! Why Mythical? So we shipped that code and something broke. People in our company didn't like us too much. Whether it was customer service or whether it was sales for us breaking stuff in the middle of their demo. But all we could say was: it was green! So, evidently, when you have 100 tests on a 200,000 line code base, there just isn't a lot of confidence that something isn't going to break. So what does a green build really mean? That is why it is mythical. We have no real "green build" if the tests are not effective and have the "area coverage".  When we write tests, we need to cover areas of the code, not code cover...

Have we ever asked ourselves "Why are we doing continuous integration/delivery?" A weird question right? It Makes Sense Almost every shop we know of says we need to go faster and deliver more content at higher quality. We grind and toil to make that happen. We learn that we can automatically build and test code. Tests pass and we are good! We are happy. We pass the hard work over to QA and expect them to give our code the final blessing. Sometimes, let's be honest MOST of the time, it comes back and we have to work on something to fix it. The final OK is given and we send it to DevOps/IT and it is released to the wild. We are proud. We got it out. And yet, there is sometimes a sense of impending doom. A little voice in the back of our heads saying: just wait. Or saying "What did we miss?" If It Makes Sense, Why The Doubt? So if all the effort to do continuous integration is worth it then why do we have doubts? Why do we find doubts in other parts ...

Over the next little bit, we are going to delve into how Continuous Confidence changes our perspectives and rolls as we seek for further confidence in our code release. I want each of us to think back on when we were first introduced to Continuous Integration. Maybe this is the first time for some of us, so let me recap. Introduction To Continuous Integration Thoughtworks introduced a new way of developing code. They said, always integrate your code as quickly as you can. His allows for fast feedback. So their guideline is shortlived branching, maybe a day at longest. Keep everything on master, and keep it releasable. Now I remember when I was first introduced to Continuous Integration. We made an automated build  and test system. We were loving it. We said, "Ok, everyone develop solely on master." And we were off. So there we started and we did what "everyone else" did I tell he world: we called it continuous integration. And yet, as we went further and fur...

Continuous Confidence is not a new idea. Over the years, I have spent many hours thinking about, and witnessing multiple development shops implement their own understanding of Continuous Integration. Time and time again they fail to completely succeed. There are moments when there is fresh air and people are happy, but then something comes along to spoil that zen moment. After looking at what was happening, I came to realize that there is much more to continuous integration than what is really out there. People are funny creatures. When we have a problem, we try to find a solution. We will try anything and everything we can, that makes sense to us. If we don't understand it, then we shy away from it. If we are developers, we tend to judge the worthiness of a statement, and then if found lacking, we ridicule and mock it for not making sense. (Overstating the obvious for dramatic effect.) Here in is the key to understanding failure to implement Continuous Integration or Continuous ...