In the early years of my career, we didn't have business analysts. We talked to people who wanted software that would improve their work process and we brainstormed with them how we could build software to address their needs. They sometimes asked for things they didn't need or didn't make sense, but we talked it out with them until we found the sweet spot between what they need and what we can realistically deliver.

The past few years, companies I worked for had a "business analyst" or "business developer", a role that never existed in the early years of my career. My experience is that the function of a BA is to be a moat between the business needs and the developer. They give me specs with zero context or explanation which makes it impossible for me to engineer a solution.

For example, the BA tells me that users with a "KE Number" can't order an inspection, and that this is a bug. I look at the code and work out from a sprawl of nested if-statements that currently the only users who can order an inspection are those who are currently up to date on their payments. I ask the BA what "KE Number" is and why they can order an inspection even if they aren't up to date on their payments. He looks at me like I'm stupid and repeats the command louder and slower. I try and try to convince him that I need to know why, even though it's incomprehensible to him that I would want to know. I finally manage to tease out that users on the Full Comprehensive plan are trusted to pay their bills and so they have permission to do anything that a user who is up to date on payments can do. Users on the Full Comprehensive plan get a KE Number, so that's a way we can identify them.

Aha, now I have the actual business rule! I can find the one place this business rule is expressed, or if it isn't there already, then I can add it. What I find instead is KENumber in various nested if-statements sprinkled all over the place from the persistence layer to the view logic. I do a git blame and find the developers who wrote these. I talk to them and find out they have no idea what KENumber is, but the BA told them "If KENumber is x, then do y" and so they added an if statement somewhere. I look through the Pull Request history and find 14 bug fixes in the form of "User with KE Number can't do x" and every single one was solved by adding yet another if statement to check if a user has a KENumber.

This has been my average workday at the last three companies I worked at. I feel like everyone is annoyed with me because I waste time asking weird irrelevant questions and they don't understand why it takes me so long to fix a bug. I thought it was a problem with the company but now I've switched twice and getting the same experience, so either I've changed or the industry has changed.

When I tell the higher-ups I want to be more informed of the business domain, they always respond "Oh, you want to switch careers? You want to give up software engineering and become a business analyst instead?" I can't seem to get across that I need to know the business domain in order to do the job of software engineering.

Does anyone relate to this? Am I way off base? Is there a way to convince higher-ups that we need to know the business domain? Is there a trick to finding a company where software engineers have access to the domain knowledge?