Continuous Confidence in Software Development

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

The biggest challenge in today's Continuous Integration culture, is separating areas of concern and letting departments be autonomous and independent. What We find most often is that a Development organization adopts Continuous Integrationa and then starts to push their product and manner of releasing to the IT department. We need to start letting the IT organization be the professionals they are. This allows confidence to build across the teams and solidifies the organization as a whole. So how do we do this? Communication Listen to your teams. We need to recognize that Continuous Integration deals with the codebase. It is a practice to continuously integrate people's work with each other via continuously building and testing code. Development is responsible for the code. DevOps is responsible for building the assets that will be deployed, to the standard that IT expects. IT gets to determine what type of artifact they require to maintain the performance of he system. If t...

There are a lot of questions around legacy code. If we ask any developer who is new to the organization, they will most likely say: REFACTOR! Our first knee jerk reaction is to not touch the legacy code, so we kind of dismiss the new developer saying that. However, we should look more deeply at what they are saying. The Code is Messy Generally, when dealing with legacy code, it is messy! Let's face it, when we start writing code, we ignore certain design patterns for others because there isn't a need. Once we get large enough, something has to be done about it. We need to stay focussed. If we feel that we are assigning one senior developer to fix legacy code, while 50 others are still using it, we will,never fix the code. Continuous Confidence comes from looking at the code and feeling calm not erratic. The Code is Antiquated When we hear refactor, His might mean as well that the code doesn't follow today's standards. So how do we make it so? We need to refactor...

One of the hardest parts of Continuous Confidence is understanding what brings confidence to our testing. We strive, at times, to find that proper level of confidence. Too often, we talk about Code Coverage. We want to make sure that we are touching everything, and it lifts our confidence, falsely, to the same level of as our code coverage. If we have 60% code coverage, then we have 60% confidence. The issue, however, is after a while, we start to realize, once we get bugs, that we aren't really that confident in our code and then we dismiss testing almost as a chore instead of a tool. So how do we get more confidence? Well, the answer is simple, the process a little more difficult: write quality tests. Area Coverage The first thing we need to do, is understand what we are testing. We should be considering Area Coverage instead of Code Coverage. Area Coverage looks at the areas of the application that have tests. There aren't a whole lot of tools out there that will help yo...

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

Often, when we think about our release process, we think primarily about the core product we deliver.  We ponder on how we can deliver better, faster, and with quality. There is, however, other parts of the software business that need to improve as well. There are other deliverables that, when we take the time to understand and focus on, we can gain greater insight into confidence culture wide. Sales When we think about the Sales organization, how can we implement Continuous Confidence there? Well, notice that for a certain period of time, we spend a lot of time and effort training people to sell the product. We spend a lot of time focusing on how to answer questions and how to pitch the deal. May we in addition focus on the confidence of the deal? Do we focus on them having confidence and a solid relationship? Do we take the time to care about the other person? Do we genuinely seek to know why we didn't win the sale? Often sales fail because people don't have confidenc...

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