←back to thread

172 points yatrios | 1 comments | | HN request time: 0.217s | source
Show context
game_the0ry ◴[] No.42186165[source]
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.

replies(1): >>42186448 #
Spivak ◴[] No.42186448[source]
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.

replies(1): >>42186840 #
game_the0ry ◴[] No.42186840[source]
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."

replies(2): >>42187956 #>>42188269 #
1. mrkeen ◴[] No.42188269[source]
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.