This is just a new name for practices that have been in place for at least twenty years on decent projects. See fail fast, test early, small features, frequent early feedback, anti-pipeline pattern...
Because we still have no licensing body in software engineering (and I like that), the exponential growth of hiring during industry booms means that many teams are working with very thin access to historical knowledge because there are zero or few “old timers” around to convey past technique.
The new generation inevitably reinvents practices and sometimes resurfaces them through independent archaeology, and so there’s a lot of cyclical repetition of both successes and failures. There’s also sometimes lucky innovations when old ideas get aired out in a new context and yield different results than in the past.
If you’ve been around for a while, it’s easy to call out these repetitions and it can be satisfying to do so. But at the same time, it often means that the new generation is finally catching up on things that nobody’s been around to teach them. That’s something worth celebrating, not diminishing.
After so many times being the youngster advocating for things like this to the 20-30 year experience crowd, I am not sure I agree that age or experience are really major factors in this context.
Ya, after a while in the field I noticed that Xtreme Programming, Agile, DevOps, and now Shift Left, and most other ideas are all just describing the exact same thing. Be flexible in your work, set up your processes to be able to deliver quickly so you can adjust quickly.
I was puzzled why it seemed we were learning the same lessons in an industry over and over again, and why we kept giving new names to things that we're already existing. Then I received enlightenment when I realized that consultants that were selling agile previously were now selling DevOps. The reason they keep changing the name is because it allows consultants to come in and charge you more money to tell you to do the same things management bungled the last 3 times, because the problem isn't with the business processes it's with the idiots running the company.
Or to quote Scott Adams "If you notice a lot of focus on process improvement at your business that's a sign all the smart people have left and management is trying to figure out a process simple enough for the idiots left."
Leaving a top class engineering shop for a ... not top class one is one hell of an experience. So many words/phrases for things that shouldn't need a phrase.
I'd thought of this as similar to Kanban or Test-Driven Development.
Before you start designing, look at what you have and ask why it doesn't already work. Those answers become manual test cases. Then get it into a test environment immediately, not after more than a day of coding. Every day make the test environment more like production. Run the whole cycle every time, build, release, test, otherwise one of the phases will go astray when you aren't exercising it.
I know Kanban is something different but these are all "Don't push from the start of the pipe, pull from the end of the pipe" approaches. It also works with media encoding and decoding. If you push, the buffers fill up and you have to figure out where to stuff packets when the codecs tell you they're full. If you pull, you waste 1 cycle figuring out where to start, but then everything is smooth and just-in-time.
It's all the same crap. It's Lean, too. There must be 20 names for this concept.
Toyoda Automatic Loom Works had the jidoka system which automatically stopped the loom when a thread broke[0] preventing downstream production issues. Later used in the Toyota Production System.
I'm convinced that shift left is just a way for management to eliminate QA jobs and push that work onto existing devs. Just like DevSecOps. Most people can't do that many things at an expert level.
There have been times where I've advocated shift left because the people to the right were less expert on their own topics than the people on the left. So why not just cut out the downstream churn.
For roles like QA, Ops, Infosec I've found that the good ones are so much harder to find than good developers. And when you find those good ones, they're worth their weight in gold.
But because they, especially QA & ops, tend to be viewed as lower on the hierarchy they often have lesser talent filling the ranks. Sometimes the entire group will be like this. And at that point, why even bother?
> For roles like QA, Ops, Infosec I've found that the good ones are so much harder to find than good developers. And when you find those good ones, they're worth their weight in gold.
I agree to that 100%. This is why I keep sounding like a broken record to young devs.
> But because they, especially QA & ops, tend to be viewed as lower on the hierarchy they often have lesser talent filling the ranks.
Geez ever wondered why? It is partly due to the "monkey" work that's required. I feel the "ops" world needs a heavy reset (may sound like broken record again: eliminate toil, eliminate side-effects, chicken/egg problems, test? what test? etc..). Geez and I wonder why positions at "FANG" like places require software engineers to fill in the ops work - the engineers, the thinkers and the leaders at these companies understood pretty early on the importance of "engineering" applied to these "ops" and "qa" disciplines.
That's kind of my point when I brought up the good ones being worth their weight in gold. It doesn't need to be all toil. But companies often view these roles as toil and thus they don't want to spend much money on it. Which means they get the bad ones. Which means it's all toil. And the cycle perpetuates.
In contrast, the high end people I've come across in QA, Ops, Infosec, etc. They were not only *expert* in their domain but better devs than most of the devs. In other words, the dynamic was the opposite from what I first described. And of course those people are really freaking expensive. Again, the cycle perpetuates.
> One of the myths is that testing is done by developers and hence QA teams will become redundant. In reality, QA teams will work more closely with development teams. Developers will be aware of testing needs. Testers will get insights into what's being developed. A related myth is that Shift Left is not aligned to Agile practices. This myth is also busted since greater collaboration between QA and development teams means that they can iterate faster.
> I'm convinced that shift left is just a way for management to eliminate QA jobs and push that work onto existing devs. Just like DevSecOps. Most people can't do that many things at an expert level.
Not necessarily. Those functions carried out by experts are best left to the experts. What software devs in a "shift left" environment _can_ and _should_(IMHO) do is to augment their capability via "self-service" platforms and those experts should do everything they can to make it accessible. It may take few rounds of PoCs/Experiments but it is well worth the endeavour.
I'm torn on this. On the one hand, I really dislike when my developers behave as if their job is done as soon as the code is written and that all that's left to do is to "throw it over the wall" to QA and Ops. But that is perhaps my more general view that developers who understand how their code actually runs and how it's tested, generally do a better job and are more valuable. On the other hand, I do feel that the notion of shift left, taken to an extreme, leads to the undervaluation of specialized QA roles. QA professionals have a specific set of skills focused on testing, finding bugs, and ensuring the usability of software. If you distribute these responsibilities among developers, who may not have the same level of expertise in testing, there's a risk that the quality of the software could decline. As other comments here have mentioned, just as DevSecOps requires developers to integrate security into the development process, shift left ends up meaning a demand for a really broad skill set from developers, including expertise in testing and quality assurance. And it's pretty difficult for professionals to maintain a high level of expertise across multiple disciplines. I mean...specialization exists for a reason; it allows professionals to hone their skills in a specific area, ultimately leading to better outcomes (hopefully? usually?). So "shift left" aims to streamline the development process and integrate quality from the start, but it can inadvertently marginalize QA expertise and overburden developers, potentially compromising quality and security. I do think management often has no idea how many different specialties and expertise there are within engineering. They often conflate it all since it's just "engineering". The amount of expertise devs are expected to know these days has gotten kind of absurd.
> One of the myths is that testing is done by developers and hence QA teams will become redundant. In reality, QA teams will work more closely with development teams. Developers will be aware of testing needs. Testers will get insights into what's being developed. A related myth is that Shift Left is not aligned to Agile practices. This myth is also busted since greater collaboration between QA and development teams means that they can iterate faster.
That feels a little “no true scotsman” to me. Like sure, if implemented correctly, Shift Left isn’t “developers are now also testers and can sign off on stories”. But in practice, it often becomes that. And while some may say that “that’s not Real Shift Left”, I’d argue that if a practice works great if you do it right but almost always fails the same way when you actually try to do it… well, that’s a problem with the practice itself.
We can at least ask developers to write proper tests and own (be on call) for their own mistakes. I think having a separate QA team write tests leads to bad incentives. If I were to set up a QA Team they would write tools under the platform engineering org.
Developers and QA teams should be doing different kinds of testing. Devs should be writing the majority of tests that can be automated. QA teams should be testing for things that can't be or are difficult to automate (e.g. UI/UX) and trying to break things in ways developers don't usually think about.
Please. Doing a perfunctory role does not equate to "overburden". I'll get grads from a third-world who will _happily_ take the burden off these developers if you so insist.
> I do think management often has no idea how many different specialties and expertise there are within engineering.
That is true. It is every one's responsibility to inform mgmt of this and keep open channel.
Given by today's standard, _most_ if not all the code I review out in the wild are these:
- Search your question on $search_engine
- Land to stackoverflow
- Copy
- Paste
- Write some crappy unit test (important but still crappy IMHO)
- CI
- Boom land on production
Where is this special fairy of "overburden"'ed devs you speak of?
Very few code today are _true_ innovations. It's a pile of abstractions over abstraction shite.
Most code should be implementing business rules in the simplest and most maintainable way possible. I don't need developers "innovating" on my codebase.
And you can't find typical business rules on Stack Overflow. Getting this right is much harder than it sounds.
> Most code should be implementing business rules in the simplest and most maintainable way possible. I don't need developers "innovating" on my codebase.
Fair dinkum. That's you. You may be biased towards it due to past experiences and I understand it. However, with that mentality where there are no "innovation"(s) involved, you'll only get donkeys that live within the echo chamber. And, may be that's what you want.
Try working in highly regulated environments like energy, finance or health. Now make your product work in multiple markets for multiple clients of differing scales with differing needs. Business logic can get very complicated, quickly.
To the gargantuan number of people I meet everyday: Shift left in this context talks about SDLC (which is useful but quite old and unsurprising by today's standard).
There are far more important and larger piece of shifting "left" which developers do not yet fully come to grapple with. Let me spell it out for you:
- Information Security practices
- Platform/DevOps practices
- Networking Concepts 101: Are these new 20 something devs cognisant of the famous "fallacies of distributed computing"?
41 comments
[ 2.9 ms ] story [ 107 ms ] threadThat's 2001.
The new generation inevitably reinvents practices and sometimes resurfaces them through independent archaeology, and so there’s a lot of cyclical repetition of both successes and failures. There’s also sometimes lucky innovations when old ideas get aired out in a new context and yield different results than in the past.
If you’ve been around for a while, it’s easy to call out these repetitions and it can be satisfying to do so. But at the same time, it often means that the new generation is finally catching up on things that nobody’s been around to teach them. That’s something worth celebrating, not diminishing.
I was puzzled why it seemed we were learning the same lessons in an industry over and over again, and why we kept giving new names to things that we're already existing. Then I received enlightenment when I realized that consultants that were selling agile previously were now selling DevOps. The reason they keep changing the name is because it allows consultants to come in and charge you more money to tell you to do the same things management bungled the last 3 times, because the problem isn't with the business processes it's with the idiots running the company.
Or to quote Scott Adams "If you notice a lot of focus on process improvement at your business that's a sign all the smart people have left and management is trying to figure out a process simple enough for the idiots left."
Before you start designing, look at what you have and ask why it doesn't already work. Those answers become manual test cases. Then get it into a test environment immediately, not after more than a day of coding. Every day make the test environment more like production. Run the whole cycle every time, build, release, test, otherwise one of the phases will go astray when you aren't exercising it.
I know Kanban is something different but these are all "Don't push from the start of the pipe, pull from the end of the pipe" approaches. It also works with media encoding and decoding. If you push, the buffers fill up and you have to figure out where to stuff packets when the codecs tell you they're full. If you pull, you waste 1 cycle figuring out where to start, but then everything is smooth and just-in-time.
It's all the same crap. It's Lean, too. There must be 20 names for this concept.
0. https://en.m.wikipedia.org/wiki/Sakichi_Toyoda
Some of the most important types of testing early in the process involve testing the design and concept with users.
There have been times where I've advocated shift left because the people to the right were less expert on their own topics than the people on the left. So why not just cut out the downstream churn.
For roles like QA, Ops, Infosec I've found that the good ones are so much harder to find than good developers. And when you find those good ones, they're worth their weight in gold.
But because they, especially QA & ops, tend to be viewed as lower on the hierarchy they often have lesser talent filling the ranks. Sometimes the entire group will be like this. And at that point, why even bother?
I agree to that 100%. This is why I keep sounding like a broken record to young devs.
Geez ever wondered why? It is partly due to the "monkey" work that's required. I feel the "ops" world needs a heavy reset (may sound like broken record again: eliminate toil, eliminate side-effects, chicken/egg problems, test? what test? etc..). Geez and I wonder why positions at "FANG" like places require software engineers to fill in the ops work - the engineers, the thinkers and the leaders at these companies understood pretty early on the importance of "engineering" applied to these "ops" and "qa" disciplines.
In contrast, the high end people I've come across in QA, Ops, Infosec, etc. They were not only *expert* in their domain but better devs than most of the devs. In other words, the dynamic was the opposite from what I first described. And of course those people are really freaking expensive. Again, the cycle perpetuates.
> One of the myths is that testing is done by developers and hence QA teams will become redundant. In reality, QA teams will work more closely with development teams. Developers will be aware of testing needs. Testers will get insights into what's being developed. A related myth is that Shift Left is not aligned to Agile practices. This myth is also busted since greater collaboration between QA and development teams means that they can iterate faster.
Not necessarily. Those functions carried out by experts are best left to the experts. What software devs in a "shift left" environment _can_ and _should_(IMHO) do is to augment their capability via "self-service" platforms and those experts should do everything they can to make it accessible. It may take few rounds of PoCs/Experiments but it is well worth the endeavour.
I may sound like a broken record. Sorry.
> One of the myths is that testing is done by developers and hence QA teams will become redundant. In reality, QA teams will work more closely with development teams. Developers will be aware of testing needs. Testers will get insights into what's being developed. A related myth is that Shift Left is not aligned to Agile practices. This myth is also busted since greater collaboration between QA and development teams means that they can iterate faster.
Please. Doing a perfunctory role does not equate to "overburden". I'll get grads from a third-world who will _happily_ take the burden off these developers if you so insist.
> I do think management often has no idea how many different specialties and expertise there are within engineering.
That is true. It is every one's responsibility to inform mgmt of this and keep open channel.
And vice-versa (should of said).
Given by today's standard, _most_ if not all the code I review out in the wild are these: - Search your question on $search_engine - Land to stackoverflow - Copy - Paste - Write some crappy unit test (important but still crappy IMHO) - CI - Boom land on production
Where is this special fairy of "overburden"'ed devs you speak of?
Very few code today are _true_ innovations. It's a pile of abstractions over abstraction shite.
And you can't find typical business rules on Stack Overflow. Getting this right is much harder than it sounds.
Fair dinkum. That's you. You may be biased towards it due to past experiences and I understand it. However, with that mentality where there are no "innovation"(s) involved, you'll only get donkeys that live within the echo chamber. And, may be that's what you want.
Heh. Thanks for raising. I am very well aware of it.
> Getting this right is much harder than it sounds.
Let's call a duck a duck. Unless, you tell me you are designing guidance system for NASA, I'd be happy to leave this pedantic discussion aside.
This just sounds like someone working at a terrible company with stories like 'build the api' having a revelation that their methods are not smart.
There are far more important and larger piece of shifting "left" which developers do not yet fully come to grapple with. Let me spell it out for you: - Information Security practices - Platform/DevOps practices - Networking Concepts 101: Are these new 20 something devs cognisant of the famous "fallacies of distributed computing"?