3 ms·

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 domai

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.
- robertlagrant 2y ago
  So does the engineer sit there and do nothing until they know the NFR, or do they decide on the NFR themselves and build to that? If the former, fair enough? If the latter, what energy does it take to send that NFR in an email saying "This is what we're building to; you have 7 days to debate it."
  - CharlieDigital 2y ago
    > So does the engineer sit there and do nothing until they know the NFR, or do they decide on the NFR themselves and build to that? Imagine you are going out to get dinner with a group of friends. "Hey, Antoine is allergic to shellfish and Lin is a vegetarian" are hard requirements. Now that I have some hard requirements, I may have input on options that fulfill those requirements because there are real constraints around which the choice must be made. With no requirements, I don't really care where we eat, I'll go with whomever has the stronger opinion; I'm really interested in having a great meal together -- why ruin vibe over whether it's Japanese or Indian? Is there really a need to debate whether it's Japanese or Indian? Am I a coward for not taking a hard line on Japanese being the clearly superior dining option? Why cause friction when both get the job done? But if Antoine and Lin are coming, then I will take a hard line because Antoine is allergic to shellfish and Lin is a vegetarian so let's pick Indian because I like Antoine and Lin's company. > ...send that NFR in an email... Yes, this is exactly how real world software engineering works. Just send the NFR in an email and call it a day.
    - robertlagrant 2y ago
      > Is there really a need to debate whether it's Japanese or Indian? This analogy is wrong - you're not the diner. You're the chef. You're going to cook something. You need to pick anyway; why not say what you're picking in advance and give people a chance to object? Is it really just something you can't muster the energy for?
      - CharlieDigital 2y ago
        Read the first line of the article: > Some engineers think it’s a virtue to remain non-committal in technical discussions. I'm non-committal because I don't care where we eat unless there is a constraint.
        robertlagrant 2y ago
        In this are you the cook making the food (the engineer) or a customer ordering the food (one of the business people)? If you're the cook / engineer, you are going to make something. What are you going to make?

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.

robertlagrant 2y ago
So does the engineer sit there and do nothing until they know the NFR, or do they decide on the NFR themselves and build to that? If the former, fair enough? If the latter, what energy does it take to send that NFR in an email saying "This is what we're building to; you have 7 days to debate it."
- CharlieDigital 2y ago
  > So does the engineer sit there and do nothing until they know the NFR, or do they decide on the NFR themselves and build to that? Imagine you are going out to get dinner with a group of friends. "Hey, Antoine is allergic to shellfish and Lin is a vegetarian" are hard requirements. Now that I have some hard requirements, I may have input on options that fulfill those requirements because there are real constraints around which the choice must be made. With no requirements, I don't really care where we eat, I'll go with whomever has the stronger opinion; I'm really interested in having a great meal together -- why ruin vibe over whether it's Japanese or Indian? Is there really a need to debate whether it's Japanese or Indian? Am I a coward for not taking a hard line on Japanese being the clearly superior dining option? Why cause friction when both get the job done? But if Antoine and Lin are coming, then I will take a hard line because Antoine is allergic to shellfish and Lin is a vegetarian so let's pick Indian because I like Antoine and Lin's company. > ...send that NFR in an email... Yes, this is exactly how real world software engineering works. Just send the NFR in an email and call it a day.
  - robertlagrant 2y ago
    > Is there really a need to debate whether it's Japanese or Indian? This analogy is wrong - you're not the diner. You're the chef. You're going to cook something. You need to pick anyway; why not say what you're picking in advance and give people a chance to object? Is it really just something you can't muster the energy for?
    - CharlieDigital 2y ago
      Read the first line of the article: > Some engineers think it’s a virtue to remain non-committal in technical discussions. I'm non-committal because I don't care where we eat unless there is a constraint.
      - robertlagrant 2y ago
        In this are you the cook making the food (the engineer) or a customer ordering the food (one of the business people)? If you're the cook / engineer, you are going to make something. What are you going to make?