This is based on a talk given to SysAid R&D by Dr. Shmuel Ur
We’ve all been there. Someone, a lecturer, or a product manager, wants us to build something quickly. It could be a homework assignment or a proof of concept or a MVP, but the important thing is to get it out there quickly. So we cut corners, twist monads, and bang out a couple hundred lines of code and voila! It works. No need for unit tests, code reviews, or (gasp!) manual QA.

This blog delves into the myriad of benefits of shift-left testing. Faster time to market, cheaper projects, knowledge transfer, and a more cohesive organization. #coding #shiftleft #code Click To Tweet

Now for many developers the lesson here is that we can get a feature out the door more quickly if we don’t have to coordinate with other people for e.g. testing and review. Relax those constraints and developing a new feature gets faster and easier. Except that as we all know there’s a wide gulf between something that works for a demo and a robust feature that survives user interaction, network outages, and other abuse.  

'We all know there’s a wide gulf between something that works for a demo and a robust feature that survives user interaction, network outages, and other abuse.' #coding #code #tech Click To Tweet

Why code quality is important

Say that feature sailed out of our desktop and breezed itself through our CD into production. Now someone finds a bug. The button’s font is invisible, the server crashes every second Monday at 10:19PM. You know, something nice. The first person to realize this is the customer, he contacts support, who go through tiers 1-4 and then to R&D. Someone has to realize who’s responsible for the bug and route it back to us and now we have to fix it. So multiple people were involved, and if there’s more than one iteration most of them will have to spend more time on the bug. That’s expensive. Maybe fast is not as fast as we thought it would be. Remember the tortoise and the hare?

OK, maybe we shouldn’t have skipped QA. Instead, we can develop and then push to QA, it’s their job to find out bugs after all. Which is true, except if we do that we have multiple people involved in our bugs, which is expensive again. So what to do?

Shift left

How can we improve our development process and make it faster and cheaper? An obvious place to start would be to reduce the cost and effort we put into solving bugs.  What if we build a funnel that catches bugs? We start with stages, from development and on to QA and then to production. As we progress more bugs are caught, but it’s important that at each stage we try to catch as many as we can. We want to catch them as early as possible, since bugs are cheaper to fix the sooner they’re caught.

This is called Shift Left Testing, and whaddya know it even has its own Wikipedia entry.

How can we improve our development process and make it faster and cheaper? This blog takes a look. #ShiftLeft #Coding #Code Click To Tweet

Shift left testing is cost effective, because the sooner you catch bugs, the less people are involved and the cheaper it is to fix them. Assuming you have a fixed number of bugs per project, the earlier in the pipeline you catch them the cheaper the project is and the faster the time to market.

Strategies to increase code quality, their impact, and cost

So how do we implement shift-left testing? First, at the people level, if you’re in the kind of organization that measures performance by the amount of features pushed out, that requires a change in thinking. You no longer measure the amount of features pushed but the cost of bringing a feature to completion, where completion means the feature is out and stable in production for a reasonable amount of time. Proving to the organization that testing is a worthwhile activity can be a difficult task. It’s like exercise. Everyone knows it’s good for you, you feel good after you do it, but there’s never enough time for it. That shouldn’t stop you from trying to get everyone on board.

Second, at the development level there are quite a few tools and practices that you can use. I’ll list the important ones here.

Here we look at alternative strategies to increase #code quality, their impact, and cost. #coding #tech Click To Tweet

Static checking

Static checking is an easy one. Apart from the initial (and minimal) cost of integrating a static checker into your IDE and CI pipeline there are really no costs involved. You can use Facebook’s checker, or Google’s, or any other you like and they can quickly surface bugs you might have missed during development.

Automated testing 

Automated testing can be resource intensive and hard to do right. You have to think carefully about what to test and you have to devote time to making the code testable and writing and maintaining the tests. With that said, the benefits are enormous. Not only are you catching bugs at an early stage, you’re also writing what is likely to be better code and creating infrastructure which will support future refactoring and changes. A discussion of the pros and cons of unit and integration testing is outside the scope of this article but it’s definitely something you should invest in.

Code review

Code review has a number of benefits. Apart from a quick and easy way to catch bugs it’s also good for knowledge sharing, employee growth, and promoting a culture of code quality and excellence.

Summary

In this article we showed the myriad benefits of shift-left testing. Faster time to market, cheaper projects, knowledge transfer, and a more cohesive organization. It can be hard to start a proper code quality funnel but the payoff is enormous. So start today, it’ll make you feel better!