[bcrosby95]

In my experience, simply doing the work without complaint is one of the most inefficient relationships with a programmer. Sometimes changing a minor business constraint can have an outsized impact on development costs. Oftentimes these decisions are even made by business people that think they are making things easier but are actually doing the exact opposite.

[JumpCrisscross]

> simply doing the work without complaint is one of the most inefficient relationships with a programmer

There is a difference between complaining, voicing opposition and articulating trade-offs less technical people may not be familiar with.

[watwut]

I have worked in team where programmers constantly questioned business requirement - without having any understanding of business.

Eventually customer got tired of having to defend how many statuses he wanted in combobox or what process their company want to use.

By that I want to say, there is definitely such a thing as programmer not willing to consider business point of view for a second and thus being impossible to work with.

[makach]

IMO that sounds like a bad team.

It is vital to understand business needs. A lot of times businesses want changes that are hard, and very hard to implement. It is our responsibility to work with the customer to come up with a solution. The customer must accept the consequences that come with their requested change.

Unfortunately, some things are impossible to do. It is never good to be the bearer of bad news - I have myself told that we cannot do it this way, but I have always given a thorough explanation of why it is impossible and suggested workarounds and alternatives. I think sometimes this behavior can be the difference between the perception of being impossible to work with and helpful.

Truth is, it takes a lot of effort to balance your work against the ever-changing set of requirements coming from your stakeholders.

[zachrose]

Sometimes it’s hard to understand the business. I see this happen when developers are considered fungible resources to implement a spec. If their only visibility into the business problem is through a proposed solution, then yeah, questions about how many statuses are supposed to be in the combobox are to be expected.

[watwut]

It was not issue of ambiguity. Specification was clear. It was issue of programmer assuming that customer is wrong all the time and basically wanting the customer wrong. The statuses were right, but the programmer fought to merge few of them into one, because it looked "simpler" to him.

By questioning in don't mean having honest questions nor trying to understand, but being convinced that there must be mistake and forcing customer to defend every tiny choice.

And sometimes the customer wants radiobox instead of combobox are just wants to have it without having to spend 20min on meting to defend the choice.

[agentultra]

On the other side I've had customers ask for things that are impossible or against best practices and their own interests.

For example, password requirements. Many companies are not aware of the latest best practices and guidelines and request that we block browsers from generating or remembering passwords in password fields. Or they give us a list of draconian password requirements that are clearly debunked by the latest guidelines.

Or they ask us to basically break the HTML spec.

Like I tell my four year old son, I'd love to get a million dollars but I'm not going to get it because I stamp my feet and demand it.

Trade-offs need to be made on both sides. I agree that an engineer that doesn't provide alternatives when a customer demand is not technically feasible should be corrected. However the customer should be prepared to choose from those alternatives or change their demands as well. The first step to success is shipping and the most common reason for software projects shipping late is a failure to start. I'm not against firing bad customers.

It's much easier to ship without a contentious feature and figure out how to add it later than to delay shipping (for certain features within reason, of course -- please don't ship half-baked security libraries or aviation control software).

[watwut]

Yes, but that is different situation.

I was specifically talking about situation where requirements are possible and not ambiguos. And where engineers starts "knowing" customer is wrong and keep knowing it despite it regularly turns out it was enginers lack of domain knowledge.

There is no trade off between these two situations.

I don't know what you mean by breaking html spec. Browsers keep it and we work either with it or around it?

[agentultra]

Ah okay, that makes sense.

re: HTML -- I've had strange requirements come in that required us to work around the HTML spec in order to get the UI to work they way they wanted. We eventually found a better solution...

but the point was that not all requirements are golden; sometimes the customer is plain wrong, ignorant, and stubborn.

[legulere]

The problem here is that business people don’t understand the details of the business requirements or the model of it in the code.

[thrower123]

Sometimes things have been trundling along on so much fuzz and handwaving that nobody actually knows how things are supposed to work when it gets down to formalizing them into a set of rules that could be implemented in code. Many such cases.

[onion2k]

If someone doesn't understand something it's because it's either not been explained well enough or that person doesn't have the background necessary to understand it. Either they need more information or they shouldn't be making decisions about it.

If the problem is that the issue hasn't been explained well enough then the developers need to work harder to better explain what the problems are and why they're problems.

If the problem is that the business person doesn't have the necessary background to understand the issue then you have a huge problem. That person is going to be a problem at every step. I don't envy anyone in that situation. In the past 25 years of development I've never actually encountered that situation though.

[gen220]

I’d put forward that there’s one more possibility: the person’s paycheck is contingent on them not understanding.

Unfortunately, some business people are compensated as direct function of revenue (growth), even though they have to pull engineering levers to obtain that delta in revenue.

For a lot of these people, once they’re convinced that doing X will lead to growth, no explanation will convince them that it isn’t worth it.

[amelius]

Engineers always have to give time estimates for their work. This is their way of complaining.