Continuous Confidence in Software Development

The hardest question to answer, it seems, is what kind of test should we be writing? Within the industry today, we have a preconceived notion that integration tests are the best. When we have conversations with developers about what needs to be tested they like to say: test all of it. When we are hesitant that we may have broken something we turn to an integration or selenium test to verify it. This is a problem. We need to truly understand the cost and the confidence that we gain at each level of test. There are many mantras that say we need more unit tests. But the question is why? Also the question is why do we always think in terms of integrations and seleniums? Confidence Over Time Martin Fowler, presented a great post on the Test Pyramid . In the post, he speaks about he need to having a balanced testing suite, and the trade-offs for each type. So the question still remains: which do we use? To answer this question, let's look at this from the perspective of the devel...

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

Ok. We all have the same dilemma when we test. We all ask the same questions: what should we test?  If you want the greatest confidence in your code, test your changes. When we make changes to legacy code, test those changes. When we make new code, test those changes. The Status Quo When we have a legacy system, we have a hard time figuring out how to change it without breaking. We are not real confident in how our code will effect the system as a whole. So we move on and hand it off to QA saying "test it all!"  How To Kill Productivity If we want to kill our productivity in three small, short words, then by all means we should say to QA  "test it all". See when QA hears that, they will test it all. They will test things we never touched. They will test it in ways we never thought possible. They will take forever to do it. So there has to be a better way. There is: test the changes. What Do We Mean, Test the Changes When we test the changes, we assume the...

When we look at what we are selling and what we do as a company, have we ever noticed that customers just are not as loyal as they used to be? Have we ever seen people leave when our site gets unstable? Why is that? Confidence The answer is quite simple: they don't have a lot of confidence in us. When someone gets angry and sees that there are some problems that just went out, people start to lose confidence in our product. It's not that we did anything bad or vindictive, but it is the natural cause and effect. So as we continue to release code, sometimes, to gain trust back, a moratorium is a good thing. Stop. Let the customer breathe. Allow people to see and trust you once again. Work with them to help gain that trust once more. It's All About Relationships When we start servicing a customer, we are starting a relationship with them. When we don't care for anything but their money, we make sure that there is very little if any trust there. Once things get toug...

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

The Developer's role within Continuous Confidence, is a little bit different. The traditional look on what a software engineer does, brings us back to writing code and then having others verify it works. This traditional view is flawed and actually produces weakened confidence over time. Let's explore why. One Time Evaluation Over the last decade or so, new methodologies have taken form. Test Driven Development (TDD). Code coverage. Behavior Driven Development (BDD). These forms have been around for a while, but only in the last 10 years have they really started to gain traction. When the traditional model focusses on someone other than the developer verifying the build, it is verified in a single instance of time. That single instance will never be repeated, and so, naturally, bugs will come. Using the afore mentioned methodologies, we start to place the responsibility of testing on the shoulders of the developers. Abbreviated Timeline We have made a serious mistake. T...

When we look at the Continuous Integration model and the reason it has been so successful, one might think it is because we release more often and our commits are small. One might also think, the boredom of constant releasing is powerful as well. As we examine further, as well, there are times when in reality, even when practicing Continuous Integration, we are asked to stop releasing so often.  We have moments when the rest of the company or when the customer asks for us to not release as often. Why is that? Confidence. Trust. Let's be honest, we break stuff...often. It happens. It's ok. But when we lost trust, we need to gain it back. Determine The Cause The first step to Continuous Confidence is the council. Pull in people from every group and department of the company. Don't pull in managers. We can invite them, but we need people who are in the trenches and who know where the pain is. Be productive. Keep the council moving, but council  about why people don't w...

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