It's not all BS
I'd like to make an important dinstinction upfront: developers rarely BS! Most of the time they simply say things that the listener feels is BS. The purpose of this post is to translate common things developers say in to non-tech friendly terms. As with any human communication, be sure to give people the benefit of the doubt, ask questions, and above all be respectful.
"That's a lot of work"
This usually means that the idea being proposed requires changes to many disparate parts of the codebase. That makes it a high risk project (lots of chances to break stuff unexpectedly) which should make everyone involved assess how important it really is.
In cases like this there is often an 80/20 solution that reduces effort and risk down to a reasonable level. Walk through the requirements with your development team and rank portions of it by risk and effort. You'll almost certainly find requirements that simply don't make sense when you evaluate the risk vs. reward.
"There's a lot going on behind the scenes"
You've probably heard this when asking why a seemingly simple task takes longer than expected. There's no reason to distrust this statement! The real failure actually came back during the planning phase: your team missed the factor that's causing the problem. If at all possible, work with the developer to bypass the sticking point or change the requirements to mitigate.
Unfortunately there isn't much more you can do here: take a look at what went wrong in the estimation process and do better next time.
"I don't know when it'll be done"
And its close friend: "It's too early to give an estimate." Before doing anything else, take a step back and re-assess the task you're asking about. Is the task something that's doable in a day or a week? If so, ask your developer why they're unsure and press for specifics. It's likely that there are one or two big uncertainties that you might be able to help with.
More often, however, this is the answer you get when you're asking if a big project will be done on time. To get close to the answer you're looking for, ask about specific parts of the project. For example, ask when user management will be complete.
Need a hand?
Want to go more in-depth?
This article is pretty high-level. If you want more details and tactics on how to deal with developers, sign up to get 50% off my upcoming book, Dealing with Developers.