Shift Left Software Development Process (2022)
devopedia.org
devopedia.org
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."
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.
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"?
> 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.
Some of the most important types of testing early in the process involve testing the design and concept with users.
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.