The Beginning

By -

Background

I have been in the software industry for well over 12 years. I am a software engineer. I have a degree from Brigham Young University in Information Technology. I love everything that has to do with technology.

Over the years, while working with small companies to large corporations, I have come to realize something very unique and frustrating that happens with software development: it makes people crazy and paranoid. I found experiences in my professional career paralleled my personal life and started to realize that just maybe, the industry was looking at software development in the wrong way. 

There have been many new processes that have come up over the recent years. One of the most influential is a process started by ThoughtWorks called: Continuous Integration. I have found that abiding by the concepts and principles described in Continuous Integration, that I am more at peace with my software life. I have found that it helps development teams be more "Confident" in their releases.

But here is the sticking point for me. Have you ever noticed that even after following these principles described in Continuous Integration, or even beginning to follow these principles, other departments and people in the company are not as confident as you are? Let me share a story.

Let's Ship it

I was hired by a company to come in and help them implement "Continuous Integration" in their organization. After looking at their testing and getting them continuously testing what they had, I turned and asked the Chief Architect: "If all the tests pass we're good right? Let's ship it!"

His response was exactly what I was expecting: "No, we can't ship it." I asked him why he felt we couldn't ship it. His response was the same I find almost everywhere I go: "We need someone to look at it first. We need QA to review it."

I used this opportunity to re-iterate something is suspected from the beginning, and what started this whole Continuous Confidence movement: he wasn't confident it would not break.

Confidence

Why does that happen?  Why is it that people can run tons of tests and still not be confident that there isn't a bug, a break that could ultimately take down the system? The key to this is actually very simple: confidence. The tests, the experiences that they have with releases, causes them to lose confidence in their code. The company as well starts lose confidence if there are too many "fires" one after another.

So what does it mean to gain confidence? Well, that is different in each company. It depends on what people are feeling and what they are sensing about the product. Each organization is different but there are principles, guidelines, and practices that every organization can use to help achieve a Continual Confidence in what they are shipping and ultimately allow every organization to have pride in what they do and deliver product in a timely and efficient manner.

This site is to help us explore the principles, guidelines, and practices that will allow us to gain greater confidence in our organization, our product, and our release process.

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