#60-Shift Left - Introduction

This episode will introduce the concept of the "Shift Left" initiative in product development, and will set the stage for a series of podcasts that examine key aspects and implications of it. 

Transcript

Shift left, Introduction

Product development has several significant aspects to it. There is a sequence to these aspects, whether the development is being conducted in a waterfall fashion, or using an agile methodology. The difference is that the waterfall does these phases in large pieces whereas an agile process dictates small, repeated increments.  Either way, the same things need to happen.

Imagine a timeline running from left to right. The timeline I'm going to suggest is only one possibility, your mileage may vary, but some version of this would be typical. 

At the far left is planning. Requirements are gathered, analyzed, prioritized, and prepared for development.

Next is the working out of the approach that will be taken to meet the expectations implied by the requirements. This may involve many things including the purchase of hardware elements, the creation of source code, architectural decisions, and so forth. We can collectively refer to these activities as design. 

Moving further to the right, we enter into the implementation of the feature or system that is being built. This would include constructing hardware elements, compiling software, anything that is required to convert the design into an actual working product. We’ll call this implementation.

Once implementation is complete, we then work toward resolving all the dependencies with other elements of the system, or other systems that our product interacts with. We can refer to this as integration. 

Next along the timeline is the inspection of the system to ensure that it meets all requirements and expectations without aberrant behavior. We can refer to this as quality control, or quality assurance, and it is a traditional testing activity. For now, we'll simply refer to it as testing.

Once tested the product must be sold and deployed for use. Let's refer to this as deployment.

Finally the product, having reached the far right of the timeline, is in our customers hands and being used to deliver value hopefully in the way it was intended to.  We’ll call this simply usage.

At each one of these phases, there is a possibility that we may introduce a defect. 

• We may miss some aspect of the requirements and expectations in planning.
• We may create a plan or a design that is incorrect or naïve.
• We might Implement that design incorrectly.
• We can miss one or more dependencies.
• Testing may fail to find errors or edge cases in the runtime use of the system.
• We might find the system to be un-deployable as created.
• Our customers may ultimately report back to us that the system does not meet their needs because of incorrect behavior or unpredictable crashes and other bugs. 

The farther to the right that this happens will create the most waste and result in the greatest damage on multiple levels. The next few podcasts will examine the initiative called “shift left” which basically is an attempt to move the detection and prevention of defects to the earliest possible moment in the development process. We'll start by examining why this is and then look at a number of implications that arise from it that must be taken into account if the organization wishes to accomplish the virtues of shift left.  

Stay tuned