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

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 write code and we deliver software to people, there will always be mistakes made. It's OK. If we feel the pressures of delivery and performance to our customers, then we need to do something different. Slow Down When "fires" erupt in our daily software life, making a giant enormous deal out of it, is actually the opposite thing we should do. Be grateful for the moment to learn. Thank those who have brought it to our attention. Allow the fire to be dealt with in a methodical and smooth approach. Smooth is fast. Also, smooth is confidence. Identify The Source When we try to identify the source of the fire, we should not name the developer as the source. We name the real source: the code, or the process that had a problem. See, when we finally understand where the issue is, we can finally make the needed change, however, together with that, we can also inform the customer what the issue is and how we plan to fix it going forward. If we don't do hat, then ...

when we write software, often we talk about the customer. We talk about their interactions with our software. We talk heir behavior and we ultimately decide what is going to be best for the customer. So in all of that talking, however, do we ever talk about what will make he customer trust us the most? Trust: The Measuring Stick When we start talking about a new feature and he performance of the application, we start geeking out! We  are developers, it's what we live for. Never, in the history of the world have we ever seen so many people gathered around a small little box talking in a foreign language and having such a great time. This is coding! This is awesome! Yet, at the other end of the spectrum, at the end of he development process, the customer is waiting. They await he next code release, and if we have not done our jobs right, they dread the next release. See, if we were all about the feature, or the performance, and didn't bother to release seamlessly, the cus...