4 ms·

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,

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

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