> I cannot figure out what you mean by "BA" in this context
Business Analyst - those people who learn everything about what the customers requirements, specs, etc are. What they need, what they currently have, how to best advise them, etc.
> In my experience, they know nothing, including how to program.
In my experience (Banking, Insurance, Fintech, etc) they were invaluable.
If, while developing, you hit some ambiguity in the spec, you could always go to the BA that wrote the spec and clarify, and I've never had the situation where they responded "Wait, let me ask the customer"; they knew what the business process should be, what the workflow should be, etc.
It worked for the customer as well - when they had trouble deciding "should or workflow do $FOO or $BAR?", a quick chat to our BA would be enough for them to make a decision.
Now, having worked in Agile shops (which I believe are the majority), there is no space for a BA - the ethos is "through something together, and if the customer doesn't want it, refine it until they do", so any BAs in this shop tend to be superfluous anyway because there is no place for them in the process anyway.
That's a failure of the process, not a failure of the role.
I was a BA forever ago during a summer job in college. That job wasn't for me at all! Looking back on the experience, putting together a FRD felt much like writing a CLAUDE.md with some prompts thrown in!
> I was a BA forever ago during a summer job in college. That job wasn't for me at all! Looking back on the experience, putting together a FRD felt much like writing a CLAUDE.md with some prompts thrown in!
But soon enough, all s/ware dev jobs will be that, because LLMs can write code faster than humans can.
Business Analyst - those people who learn everything about what the customers requirements, specs, etc are. What they need, what they currently have, how to best advise them, etc.
They know everything, except how to program.