Shift Left Is the Tip of the Iceberg

In my org [1], "shift left" means developers do more work sooner.

So before we clearly clarify product requirements, we start the build early with assumptions that can change. Sometimes it works, sometimes it does not, which just means we end up net neutral.

But an executive somewhere up the management chain can claim more productivity. Lame.

[1] I work at a bank.

I think that's a myopic view. Getting something anything in the hands of your potential users that's even vaguely in the ball-park of a solution shaped thing gives you extremely valuable information both on what is actually needed and, to me more importantly, what you don't have to build at all.

I consider it a success when an entire line of work is scrapped because after initial testing the users say they wouldn't use it. Depending on the project scope that could be 6-7 figures of dev time not wasted right there.

Much of what you are saying does not apply to consumer banking.

"Build fast and break things" works in big tech, but its a serious risk in financial services.

That being said, we are being forced to "build faster and try not break things."

I’ve never been in banking, but I’ve been in games (AAA) and biotech most of my career.

I agree with the previous commenter. It isn’t about breaking things out even moving fast (in my experience), but about getting “the juices flowing”.

I’ve found that when there’s a request for some new tool or thing, people have a very difficult time defining [all] the real world needs. They know they need X, but don’t remember - or even realize - they also need Y, Z, etc. Or worse, many people have been conditioned through corporate culture that they can’t even ask for things that would make their lives easier.

Getting something basic in someone’s hands quickly with the desire of creating a loop of feedback, feature, feedback, … gets the end user more focused and engaged with the final product, which gives the engineers more focused requirements. I’ve found it also gives the engineers the opportunity to make suggestions and get more invested.

I'm in fintech right now, experiencing that pain. We do a sort of "reverse waterfall".

We respond to spikes in increased exceptions, then read logs to try to figure out why something "went wrong". If we can change some code to fix it, we do so. But since we don't have confidence in our fixes, we have to move further back to the design and guess how the system is supposed to work. I'm hoping next month we start a dialogue with with upstream and ask how we're supposed to use their API.