Why do we release code?

By -
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 might be writing a SaaS product that can be released multiple times a day. We might be writing desktop app that we want to release monthly, or mobile app that releases on a normal schedule. We might release code only Semi-Yearly. Whatever the answer, his will shape how we interact with other departments and with other people. Continuous Confidence is the focus to implement relationships, to identify handoffs, and to produce quality releases by identifying and acknowledging where people lack confidence in the system, and providing structure to overcome that lack of confidence.

If all our tests are passing, should we ship it now?

Do we get consternation or anxiety from the prospect of just shipping now? All our tests passed, why can't we ship? The answer to this question, helps us identify the pain points in our software development cycle. Answers from other departments, like Customer Support, or from IT, present great feedback into what is causing pain and a lack of confidence. We might be ready, but IT might be  swamped and can't handle the release right now. There might be code that can't be released right now, due to marketing, due to a plethora of reasons. People might not feel comfortable with it. The point of Continuous Confidence is not to achieve 100% confidence in our code, because that is not possible, but rather to achieve whatever level of confidence we need to make all parties involved, confident and comfortable with releasing.

Principles of Continuous Confidence

This is where we use the areas of Continuous Integration, of Continuous Delivery, of Automated Testing, of Feature Toggling, and of other coding practices that will help us be as agile as we can. Remember, we don't have to do everything that is taught by each of these areas, but rather understand what parts of confidence we are lacking, and how these practices can help us gain what we lack. 

Now, he final piece of the puzzle: keep practicing. We need to keep striving for more and more confidence. Keep rinsing and repeating. Focus on that confidence, and ultimately we will have quality and confident code being released each time. If we make a mistake, we learn, we don't punish. When we find a problem, we rejoice, because, when done right, we will never make that mistake again.

Comments

Post a Comment

Popular posts from this blog

Not All CI Solutions Are Created Equal

By -
Are there any of you out there who have attempted Continuous Integration, Delivery, or Deployment, and had it fail? Have you ever just given up because it was over complicating things? People were not happy? Believe it or not, this is very common. I have heard many stories where organizations have failed at implementing CI. So first and foremost I want to say: it's ok! We all recognize the value of what we get from doing CI, but in reality, in practice we need to be more practical and pragmatic in our approach. May I offer some counsel. Implement Countinuous Confidence This may seem strange at first, and probably expected since this blog is all about Continuous Confidence, but really, truly, this is he first step. Focus on your confidence points.  Generally, when I see failure in the CI world, it isn't the methodology, but rather the lack of confidence in the process that is causing the problem. Generally speaking, I see people wanting to implement CI in here organization becau...
Read more

Stop Talking About Continuous Integration

By -
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...
Read more

Legacy Code: What to do About it

By -
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...
Read more