Shift-Left!!!

Written By Dave Tavares

What is shift-left, and why is it so important?

The Software Development Life Cycle (SDLC) encompasses a commonly understood sequence that begins with requirements and concludes with Release Candidate independent testing. The cycle remains the same for DevOps, Agile, Highly Iterative, and Waterfall. Given the previous methodology order, the print cycle length ranges from hours/weeks to months. 

What is shift left?

This comes from the classic SDLC approach, which is linear. Here, I have aligned the SDLC order to be compliant with the ASPICE standard:

SDLC order: Requirements, Architecture, Design, Implementation, Code Reviews, Test, Release

Shift-left is the practice of trapping bugs and improving understanding earlier in the SDLC (moving from right to left).

Shift-left is intended to accomplish:

  • Consistent understanding of the project (requirements, architecture, designs, peer (code) reviews, tests)

  • Seek and destroy misunderstandings, issues, and bugs earlier in the life cycle

Another look at SDLC for Software and Firmware [estimated cost to fix a requirements issue]:

  1. Requirements (leftmost) [$10]

  2. Architecture [$100]

  3. Design (high and detailed) [$1000]

  4. Implementation [$10000]

    • Peer/Code reviews

  5. Testing (including regression) [$100000]

    • Unit

    • Integration

    • Requirements, Design, etc.

    • Feature, Function, Performance, Reliability, etc.

    • Alpha

    • Beta

    • Release Candidate. This is just a check. No bugs/issues should be found!

  6. Customer Found Bug (rightmost) [$ 1 M+]

    NOTE 1: Although the cost has both pro’s and con’s it seems to be a good estimation. For proof, just search the web for Cost of Quality (CoQ) Formulas.

    Bing search results below:

    NOTE 2: In my experience, a bad requirement costs significantly more than $1000 if found during the test cycle. Analysing the issue alone will overshadow this. For example, a one-hour meeting of critical team members (Requirements Engineer, Architect, Design Engineer, Developer, and Tester) will cost approximately $500. This is to formulate what is broken and agree on the following steps to get answers. Once the correction is found, Corrective actions add another set of costs. The cost depends on the severity of the failure and the complexity of the corrective actions.

    Note 3: Engineering cost includes salary, benefits, and any costs to the company.

Why should you implement the shift-left mindset?

Improve quality,

Reduce the cost of developing, testing, and time to release.

Reduce the negative impact of finding early failures later in the SDLC

Significantly reduce the cost due to bugs found by customers (which impacts more roles than engineering).

Reduce negative impact on the product and the brand, which may lead to brand tarnishing, marketing issues, and sales reductions.

Dave Tavares

Initially, I was a software developer for the Department of Defense (DoD) through defense contractors. I understood that the software could not fail because lives depended on it (extreme safety concerns). I quickly took steps to ensure that my software was highly reliable and easy to maintain.

Due to the quality of my software deliveries, I was promoted to software engineering leadership.

By request, I was responsible for leading a Quality Engineering (QE) team where the team was not meeting client expectations for a highly critical solution requiring the removal of as many bugs as possible before going live with accuracy and extreme stability (i.e., air traffic control). I had a leadership and hands-on role. Safety was paramount. We succeeded due to Cyclomatic Complexity path test coverage > 85%. I tracked the first ten years of this solution required for range control, and the software never failed and always worked as expected.

I then moved into high-tech industry testing (broadcast, health care, smart grid, IoT, semiconductor software design/software test tools, and autonomous driving, to mention a few).

During my QA/QE phase, my software quality engineering responsibilities at the contributor level included manual, automated, and comprehensive testing. I brought innovative practices to match the SDLC, CMM, and ISO 9001 target goals at the Quality Engineering Lead and Director levels, satisfying their customer base. I was responsible for setting processes, procedures, templates, and checklists for all phases and types of testing. Quality was improved, resulting in a maximum of 90% reduction in customer bugs. I was also a lead assessor for CMM and ISO 9001 during this time.

In my most recent role as the Staff Technical Program Manager, I moved into engineering hands-on training, driving engineering standards compliance and assisting engineers with compliant artifacts. I translated standards into system/software/firmware engineering processes, practices, and templates. Standards included ASPICE, ASIL, and applicable portions of ISO 26262

Finally, I have worked with agile, highly iterative, and waterfall models and assisted teams in migrating between different models.

Previous

Available Services
Next

Risk Management