3 ms·

In my experience, simply doing the work without complaint is one of the most inefficient relationships with a programmer. Sometimes changing a minor business c

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.

amelius 7y ago
Engineers always have to give time estimates for their work. This is their way of complaining.
legulere 7y ago
The problem here is that business people don’t understand the details of the business requirements or the model of it in the code.
- onion2k 7y ago
  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 7y ago
    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.
- thrower123 7y ago
  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.
JumpCrisscross 7y ago
> 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 7y ago
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 7y ago
  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 7y ago
  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 7y ago
    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.

amelius 7y ago

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

legulere 7y ago

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

onion2k 7y ago
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 7y ago
  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.
thrower123 7y ago
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.

JumpCrisscross 7y ago

> 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 7y ago

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 7y ago
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 7y ago
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 7y ago
  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.