Prove It!

By -
The Developer's role within Continuous Confidence, is a little bit different. The traditional look on what a software engineer does, brings us back to writing code and then having others verify it works. This traditional view is flawed and actually produces weakened confidence over time. Let's explore why.

One Time Evaluation

Over the last decade or so, new methodologies have taken form. Test Driven Development (TDD). Code coverage. Behavior Driven Development (BDD). These forms have been around for a while, but only in the last 10 years have they really started to gain traction. When the traditional model focusses on someone other than the developer verifying the build, it is verified in a single instance of time. That single instance will never be repeated, and so, naturally, bugs will come. Using the afore mentioned methodologies, we start to place the responsibility of testing on the shoulders of the developers.

Abbreviated Timeline

We have made a serious mistake. Think about all the blood sweat and tears we put into a story (agile software development). Think of the days we put into it, thinking and iterating over the logic and understanding the intricacies of all we do. Now, think of when we "finish" the story. We wrap it up and pitch it over the wall to QA and say: ok, you have 2 hours, go! Why do we expect QA to take less amount of time to consume the complexities of our logic, and apply that logic to he product spec and do it in rig the first time? There in lies the break in confidence: the abbreviated timeline. So how do we fix it?

Prove It

We prove it! We write the tests that prove the desired behavior exists. We focus on: Behavior Points. We will learn more on Behavior Points later, but understand that QA really is responsible to make sure we have proven that the product behaves as defined. However, we need to automate that proof so that we can always be confident about that portion of code. We can't expect that code will always behave he same way. We need to prove it always will by other code. The effectiveness of the tests are the intricacies of what and how to test, are the combined efforts of the developer and the quality assurance consultant.

Do we want better confident code? Then prove it!

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