There’s a cynical read of “shift left” that is “make people do more work but pay them the same.”
I haven't heard of this. I thought shifting left was the new hotness.
I was under the impression that finding and fix mistakes as soon as possible is considered best practice.
Shifting Testing Left Is a Return of an Older, Better System
I don't really understand. I thought the "old way" was to wait until everything was done to check if it works, and the "new way" was to add tests for individual components as you go, making sure nothing breaks as new features are added.
>>I thought the "old way" was to wait until everything was done to check if it works, and the "new way" was to add tests for individual components as you go, making sure nothing breaks as new features are added.
Things tend to be more cyclical.
30 years ago, we did unit tests where we continually test individual components, then system tests were you test if your system works as a whole, then integration tests where you check how your system works with others. We had dedicated environments for these. And this was in the big-corporation, bog-standard, boring, commercial-off-the-shelf standard enterprise resource planning software. Yes, we had waterfall / predictive project management model, but I'm not sure where this notion comes in that before right now, this exciting brilliant moment in time, nobody in IT knew at all what they were doing and built entire bridges for years and waited to see if they'd collapse when the first car came :-)
Grumble grumble get off my lawn young kids etc etc :->
Exactly. When I started my job 20 years ago, our company was waterfall, and my then boss (in his 50s) told me - never rely on QA, it's your responsibility as a developer to make sure the code (and product) works.
I think he was right. Today, apparently, he would be left.
"Left" isn't a personal label (like it is in politics); In this context it refers to having useful tests earlier on the timeline (where time in the development workflow is on the X axis).
Even the original waterfall paper describes an iterative project management model with testing & revisions on the results, at multiple levels of the system.
And just to demonstrate the universality of the human condition... just yesterday I was having a rant about (a) everything being always underbudgeted because the cheapest quote usually wins, so everyone underquotes hoping the client changes their mind and the resulting variation(s) swing the needle into profitability, and (b) that there's also a tendency to create artificial urgency (unrealistic deadlines etc.) in order to try and extract greater productivity from your workers.
Hanlon's Razor would tend to discredit (b) but I've seen it in action too many times to fully accept this...
I'm currently delivering a couple of new appsec test tools into the business, and it's the Devs who are most vocal about shifting left and wanting early access to the tools.
I'm all in favour, particularly if people don't see it as an imposition!
Not in the systems I've worked in. I interpret "shifting left" as preferring unit tests to integration tests. In that world, a unit test that runs in the same env as the dev box running compiler and completes in 20 ms will allow much, much faster iteration than an integration test that has to spin up an EC2 instance, upload code, run a script, download results, etc
Comments
I haven't heard of this. I thought shifting left was the new hotness. I was under the impression that finding and fix mistakes as soon as possible is considered best practice.
I don't really understand. I thought the "old way" was to wait until everything was done to check if it works, and the "new way" was to add tests for individual components as you go, making sure nothing breaks as new features are added.
30 years ago, we did unit tests where we continually test individual components, then system tests were you test if your system works as a whole, then integration tests where you check how your system works with others. We had dedicated environments for these. And this was in the big-corporation, bog-standard, boring, commercial-off-the-shelf standard enterprise resource planning software. Yes, we had waterfall / predictive project management model, but I'm not sure where this notion comes in that before right now, this exciting brilliant moment in time, nobody in IT knew at all what they were doing and built entire bridges for years and waited to see if they'd collapse when the first car came :-)
Grumble grumble get off my lawn young kids etc etc :->
Exactly. When I started my job 20 years ago, our company was waterfall, and my then boss (in his 50s) told me - never rely on QA, it's your responsibility as a developer to make sure the code (and product) works.
I think he was right. Today, apparently, he would be left.
"Left" isn't a personal label (like it is in politics); In this context it refers to having useful tests earlier on the timeline (where time in the development workflow is on the X axis).
I was just joking, I know what it means (to the extent one can truly understand a buzzword).
Even the original waterfall paper describes an iterative project management model with testing & revisions on the results, at multiple levels of the system.
And just to demonstrate the universality of the human condition... just yesterday I was having a rant about (a) everything being always underbudgeted because the cheapest quote usually wins, so everyone underquotes hoping the client changes their mind and the resulting variation(s) swing the needle into profitability, and (b) that there's also a tendency to create artificial urgency (unrealistic deadlines etc.) in order to try and extract greater productivity from your workers.
Hanlon's Razor would tend to discredit (b) but I've seen it in action too many times to fully accept this...
I'm currently delivering a couple of new appsec test tools into the business, and it's the Devs who are most vocal about shifting left and wanting early access to the tools.
I'm all in favour, particularly if people don't see it as an imposition!
I've never heard of this either. Shifting left only changes the timing of work, not the workload.
Not in the systems I've worked in. I interpret "shifting left" as preferring unit tests to integration tests. In that world, a unit test that runs in the same env as the dev box running compiler and completes in 20 ms will allow much, much faster iteration than an integration test that has to spin up an EC2 instance, upload code, run a script, download results, etc
I believe the article writer is talking about moving QA work to the beginning of a process, not adding unit tests to the front of a pipeline.
Theyre both examples of shifting left, though.
There's always a context contingent cost/benefit trade off, but sometimes converting integration to unit tests is a win.
Yes of course, but your mentioning unit tests in a comment about moving work steps but they are totally different things in this context.
That's often not true. Testing more, earlier, tends to surface problems whe they require less work to fix.
Easier context switching, less dealing with extra added complexity between coding the issue and fixing it etc.