It depends.
What does it depend on, Brian?
(I don't know who Brian is).
As any business analyst, project manager, scrum master, or non-technical team leader will tell you, getting a straight answer to a "simple" question out of a software developer of any seniority is like trying to dig up potatoes with your bare hands.
Junior software developers will give you an answer, and it will usually be confidently incorrect. That is because they have yet to learn the pain of finding out after they've already promised to do something by the end of the day that there is no quick and easy way to do it without first rewriting significant portions of a system.
So, often what you get from a software developer is "it depends", not because we're being awkward but because our job is to tell computers what to do, and you would not believe how fussy computers are about how they're told to do things, or how difficult it can be to make a system do something that wasn't thought about during the design phase.
We are paid (according to one of my university lecturers, at any rate) partially to deal with complexity; as the famous misquote goes, "for any complex problem there is a solution that is clear, simple and wrong".
The correct quote is:
Explanations exist; they have existed for all time; there is always a well-known solution to every human problem — neat, plausible, and wrong.
You see what we're like? Can't even write a simple blog post without a tangent about how people get a common quote wrong. Awful.
Anyway, the point. Yes. I'm sure I had a point, it was here just a minute ago.
Ah yes, "it depends". The reason you get this answer from software developers a lot isn't because we're awkward (although we can be), or stubborn, or don't want to do it (we love twiddling with stuff). It's because we've learned from bitter experience that even the simplest changes are fraught with complexity, especially if the system was designed without accounting for whatever the new requirement is.
Here's an example: "can we reduce the padding on this this button by 5 pixels on each side?" OK....on all resolutions? What if it's too small on a mobile screen? What if the button being smaller breaks the layout on a tablet? What if the user has poor eyes and has to zoom in? What if....? The person asking the question rarely has to think about these things, but developers do. Before you know it, that "simple change" is 5 media queries, 3 hours swearing at CSS, and a rant about how unfair the world is when QA tells us that the button can't be clicked any more on some resolution that nobody but our clients have used since the Atari 2600 was the dominant games console (ask your parents. Possibly your grandparents).
Here's another one (which actually happened); you have a system that was designed many, many years ago. It stores a currency value, and at the time it was built that was only ever anticipated to be GBP. The currency was, very properly, represented as a decimal number in the system.
The front end had a restriction on the number of characters that could be entered, because nothing they sold would ever cost more than (say) £1 million, so you couldn't enter more than 7 characters, because that allowed up to £9,999,999 and even those most extreme inflation wouldn't pass that, right?
The company grew, and they started to do things in other countries, and they had to record exchange rates, and people could enter prices in their own currency. Then the Vietnamese Dong happened (yes that's a real thing, stop laughing).
The exchange rate, at the time of writing, is 1GBP to 32,275 VND, which means that 1000 GBP is 32 Million VND. It took a while, but eventually somebody noticed that they couldn't enter the correct values, because of the restriction on the length of the number entered.
A change like this, in the enormous complex system that had grown up around it, isn't as simple as you might think. "You can just remove the restriction on the front-end right?". Yes, you can do that, but what you need to do is follow every code path that might use that number and check that it never assumes the number is less than 10 million. There are a lot of those code paths in a complex system, and any one of them can go wrong if they make the wrong assumption.
At that point, the decision that was made about the length of numbers years ago suddenly seemed very short-sighted, but at the time I'm sure it made sense; I hope the developer said something along the lines of "it depends on whether we'll ever have to use this for other currencies" and was told "of course we won't, and if we do we'll have a new system by then".
And that's why software developers and engineers are like we are. Although, of course, it depends on the developer.