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

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

There is a lot of talk on the Internet around Continuous Integration. There is a lot of push toward constant releases. Always releasing small portions, maybe even continuous deployment. There is a lot of tout people as towards releasing code 1000 times a day! People are in awe, and then, we try to reproduce the effects. We try to follow the example and release 100 times a day. So, we need to stop the insanity! Not Releasing Is Ok! We need to stop and look at our business model. We need to understand our requirements. We need to understand our customer base. Ask questions. Are we comfortable releasing code daily? Do our customers want us to release daily? Is our code base stable enough to release in a manner unnoticed by our customer? Does our product lifecycle make sense to release in this fashion? These questions are used to help guide discussions. We need to talk about and consider the importance of the confidence of the product. Without Confidence, Why Release? If we are not ...