4 ms·

I think author misses some points: 1. Sometimes engineers are right to be non-committal if the non-functional requirements are not yet fully known because the

I think author misses some points: 1. Sometimes engineers are right to be non-committal if the non-functional requirements are not yet fully known because the business side simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system. 2. Many orgs have a poorly managed culture around disagreements on technical design and some folks just don't want to put up with that kind of friction when the difference between using approach A or B is real, but not going to topple the project either way so why waste that energy fighting that kind of battle? EDIT: Simple analogy > Say we must choose where to get dinner. Japanese or Indian. Without constraints, I do not care. But if Antoine and Lin are coming and Antoine has a shellfish allergy while Lin is a vegetarian, I now want to commit because I like their company and Indian is the better choice. Why make a fuss about Japanese or Indian if I do not care unless there is actually a real reason to pick one over the other? Either is fine with me; I just want to go out to dinner and have a good time. I am happy with either Japanese or Indian! Do you see the difference? If Antoine and Lin are not coming, I will eat anywhere; I don't care -- let's have a good time! If Antoine and Lin are coming, I think we should pick Indian because they have requirements that we should consider -- let's have a good time! It's like asking me to choose GCP, Azure, or AWS. Does it really matter if there's no constraint? I can and have delivered systems on each of these platforms. Am I cowardly for not committing and not being a diehard for one of these when there are no NFR's that favor one over the other?

robertlagrant 2y ago
> Sometimes engineers are right to be non-committal if the non-functional requirements are not yet fully known because the business side simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system. Doesn't this necessitate asking the questions to get the NFRs out? You don't need to be non-committal then. Just say "we need answers to these 8 questions before we can estimate, as they will make a massive difference."
- CharlieDigital 2y ago
  You'll get them...at some point. It may be even at the very end when the customer complains that it doesn't quite work the way they intended and it turns out, they never fully specified exactly how it was supposed to behave! If you haven't experienced this, you haven't truly lived the enterprise software delivery reality.
  - robertlagrant 2y ago
    Of course it can happen that way :) But as an engineer you have to decide on the NFRs if you don't ask anyway, so why not ask them and declare them up front if you don't get an answer? Then you can point to the problem is down the line and say we need X time to increase this NFR.
    - CharlieDigital 2y ago
      Sure, but you've missed my point: in that case, some engineers just don't want to have that debate because there's very little point in expending that energy.
      - kikimora 2y ago
        Best strategy would be to declare NFR using engineer’s domain knowledge without waiting for clients to tell them. This is conditioned on engineers knowing domain sufficiently well. Which is a requirement for effective work anyway.
        CharlieDigital 2y ago
        I feel like a broken record now, but once an engineer decides to "declare NFR", then it's a situation where it's one opinion versus another not driven by actual requirements and I contend that this is a point of friction that some engineers just do not have the energy for when there are no real requirements -- just fabricated ones.
        2y ago
viraptor 2y ago
> simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system. "We're scaffolding / not implementing / delaying this part, until X, Y, Z are known." is a completely valid decision to officially make. And it helps with planning and development of related code. "I don't know, because of missing NFRs" is not a decision though.
- CharlieDigital 2y ago
  > "We're scaffolding / not implementing / delaying this part, until X, Y, Z are known." Isn't that the same thing as "not committing"? I'm very confused.
  - viraptor 2y ago
    "what do we do with this part?" Not committing: "I don't have enough info, don't know". Decision: "We can only finish it once X is known. Until then we assume it behaves like (…). For code that relies on it, we're prioritising flexibility to change over perfect solution at this point. Y is responsible for announcing when X is known."
- kragen 2y ago
  Generally speaking, "we're scaffolding/not implementing/delaying this part" is something you can do with functional requirements, but not with non-functional requirements. Changing non-functional requirements like security, maintainability, or testability generally requires rewriting the whole system from scratch, incrementally or otherwise.
kragen 2y ago
As for "non-functional requirements" ("NFRs") Wikipedia suggests examples: 1. Execution qualities, such as safety, security and usability, which are observable during operation (at run time). 2. Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the system.[5][6] Sometimes "the business side" has the expertise required to define these. Sometimes they don't, and engineers need to do it, using whatever knowledge of the business they have. "The business side" often will not take responsibility if the system is insufficiently testable, maintainable, extensible, scalable, secure, or usable, instead blaming engineering.
Aurornis 2y ago
> 1. Sometimes engineers are right to be non-committal if the non-functional requirements are not yet fully known because the business side simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system. I understand where you’re coming from, but in my experience this only leads to deadlock on both sides with nobody moving forward. The best engineers I learned from will push forward with a decision and also communicate the tradeoffs and consequences upward. This breaks the stalemate and forces the “business side” (which shouldn’t actually be separate from engineering) to either accept the decision or propose an alternative. The game where engineers view themselves as in a standoff with “business side” people and nothing moves forward has been a path to a slow decline everywhere I’ve seen it happen.
- RHSeeger 2y ago
  This strikes me as parallel to "the best way to get the answer to a question online is to post the wrong answer, and people will flock to correct you".
- CharlieDigital 2y ago
  Of course you push forward as a team, committal here I take to mean between two or more engineers trying to debate a technical option. Why must every engineer have an opinion on every technical decision if there are no hard requirements? I may only have an opinion if there is a hard requirement. I gave an example below. > Say we must choose where to get dinner. Japanese or Indian. Without constraints, I do not care. But if Antoine and Lin are coming and Antoine has a shellfish allergy while Lin is a vegetarian, I now want to commit because I like their company and Indian is the better choice. Why make a fuss about Japanese or Indian if I do not care unless there is actually a real reason to pick one over the other? I just want to go out to dinner and have a good time otherwise; I am happy with Japanese or Indian! Do you see the difference? If Antoine and Lin are not coming, I will eat anywhere; I don't care -- let's have a good time! If Antoine and Lin are coming, I think we should pick Indian because they have requirements that we should consider -- let's have a good time! It seems pretty clear to me that not every engineer must have an opinion on every technical decision to which they should commit when sometimes, the choice doesn't matter and it's easier to let the individual with a stronger opinion drive the choice because the other option is friction for no reason and expending energy debating made up constraints.

robertlagrant 2y ago

> Sometimes engineers are right to be non-committal if the non-functional requirements are not yet fully known because the business side simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system. Doesn't this necessitate asking the questions to get the NFRs out? You don't need to be non-committal then. Just say "we need answers to these 8 questions before we can estimate, as they will make a massive difference."

CharlieDigital 2y ago
You'll get them...at some point. It may be even at the very end when the customer complains that it doesn't quite work the way they intended and it turns out, they never fully specified exactly how it was supposed to behave! If you haven't experienced this, you haven't truly lived the enterprise software delivery reality.
- robertlagrant 2y ago
  Of course it can happen that way :) But as an engineer you have to decide on the NFRs if you don't ask anyway, so why not ask them and declare them up front if you don't get an answer? Then you can point to the problem is down the line and say we need X time to increase this NFR.
  - CharlieDigital 2y ago
    Sure, but you've missed my point: in that case, some engineers just don't want to have that debate because there's very little point in expending that energy.
    - kikimora 2y ago
      Best strategy would be to declare NFR using engineer’s domain knowledge without waiting for clients to tell them. This is conditioned on engineers knowing domain sufficiently well. Which is a requirement for effective work anyway.
      - CharlieDigital 2y ago
        I feel like a broken record now, but once an engineer decides to "declare NFR", then it's a situation where it's one opinion versus another not driven by actual requirements and I contend that this is a point of friction that some engineers just do not have the energy for when there are no real requirements -- just fabricated ones.
        2y ago

viraptor 2y ago

> simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system. "We're scaffolding / not implementing / delaying this part, until X, Y, Z are known." is a completely valid decision to officially make. And it helps with planning and development of related code. "I don't know, because of missing NFRs" is not a decision though.

CharlieDigital 2y ago
> "We're scaffolding / not implementing / delaying this part, until X, Y, Z are known." Isn't that the same thing as "not committing"? I'm very confused.
- viraptor 2y ago
  "what do we do with this part?" Not committing: "I don't have enough info, don't know". Decision: "We can only finish it once X is known. Until then we assume it behaves like (…). For code that relies on it, we're prioritising flexibility to change over perfect solution at this point. Y is responsible for announcing when X is known."
kragen 2y ago
Generally speaking, "we're scaffolding/not implementing/delaying this part" is something you can do with functional requirements, but not with non-functional requirements. Changing non-functional requirements like security, maintainability, or testability generally requires rewriting the whole system from scratch, incrementally or otherwise.

kragen 2y ago

As for "non-functional requirements" ("NFRs") Wikipedia suggests examples: 1. Execution qualities, such as safety, security and usability, which are observable during operation (at run time). 2. Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the system.[5][6] Sometimes "the business side" has the expertise required to define these. Sometimes they don't, and engineers need to do it, using whatever knowledge of the business they have. "The business side" often will not take responsibility if the system is insufficiently testable, maintainable, extensible, scalable, secure, or usable, instead blaming engineering.

Aurornis 2y ago

> 1. Sometimes engineers are right to be non-committal if the non-functional requirements are not yet fully known because the business side simply hasn't really fully scoped their NFRs which can often make a big difference in the design of the system. I understand where you’re coming from, but in my experience this only leads to deadlock on both sides with nobody moving forward. The best engineers I learned from will push forward with a decision and also communicate the tradeoffs and consequences upward. This breaks the stalemate and forces the “business side” (which shouldn’t actually be separate from engineering) to either accept the decision or propose an alternative. The game where engineers view themselves as in a standoff with “business side” people and nothing moves forward has been a path to a slow decline everywhere I’ve seen it happen.

RHSeeger 2y ago
This strikes me as parallel to "the best way to get the answer to a question online is to post the wrong answer, and people will flock to correct you".
CharlieDigital 2y ago
Of course you push forward as a team, committal here I take to mean between two or more engineers trying to debate a technical option. Why must every engineer have an opinion on every technical decision if there are no hard requirements? I may only have an opinion if there is a hard requirement. I gave an example below. > Say we must choose where to get dinner. Japanese or Indian. Without constraints, I do not care. But if Antoine and Lin are coming and Antoine has a shellfish allergy while Lin is a vegetarian, I now want to commit because I like their company and Indian is the better choice. Why make a fuss about Japanese or Indian if I do not care unless there is actually a real reason to pick one over the other? I just want to go out to dinner and have a good time otherwise; I am happy with Japanese or Indian! Do you see the difference? If Antoine and Lin are not coming, I will eat anywhere; I don't care -- let's have a good time! If Antoine and Lin are coming, I think we should pick Indian because they have requirements that we should consider -- let's have a good time! It seems pretty clear to me that not every engineer must have an opinion on every technical decision to which they should commit when sometimes, the choice doesn't matter and it's easier to let the individual with a stronger opinion drive the choice because the other option is friction for no reason and expending energy debating made up constraints.