7 ms·

This isn't all on the non-developers. I've walked into two rooms this week, which contained several senior developers, and when I asked them about non-function

This isn't all on the non-developers. I've walked into two rooms this week, which contained several senior developers, and when I asked them about non-functional requirements, they had to ask what they were, and why they were important. I've also seen teams where the Defintion of Done doesn't include any steps at all towards deployment. Done is when someone approves the pull request. Not surprisingly, it takes longer for those teams to 'complete' a change. In the former case, they are continuously surprised, and angered, by 'requirements' that 'no one' told them about. In the later, they stop halfway, and wonder why everyone is waiting on them, because it's 'development complete'.

dfjhdkjfhsdkf 7y ago
I agree with your comment about senior devs. it seems as devs climb the ladder many get a superiority complex where they could do things quickly and others cannot. I was once a tech lead of a team where the architect had been berating and criticizing a team member for weeks over something he thought should take a day. I suggested he should take over and complete it. It took him weeks to complete.
- jimrhods23 7y ago
  "I was once a tech lead of a team where the architect had been berating and criticizing a team member for weeks over something he thought should take a day" As I've gotten more experience as a developer, I've realized that most tasks take longer than I used to estimate..usually because I want to come up with a long-term solution and not just hack something together with no testing.
- rdiddly 7y ago
  the architect had been berating and criticizing a team member for weeks If berate is truly the appropriate word (upon investigation), and I had any say in the matter, I would fire his toxic ass immediately.
- funkymike 7y ago
  I'm sure I still have far to go, but currently when I see someone quote a time frame for a change I am more concerned when it is short vs. seems too long. Especially when the dev is questioned and the estimate doesn't include time for documentation, deployment, etc.
VBprogrammer 7y ago
To be fair; non-functional requirements as a separate entity are pretty much wank. If you need a line in a document to tell you that exposing privileged information to the outside world is a bad idea, or that you should make sure the solution you are designing has a reasonable chance of servicing the expected load then you probably shouldn't be a developer. The last time I seen explicit non-functional requirements the had something like "the solution should have a 99.99% uptime." I realised that our down time for releases (old school I know) was more than that and promptly ignored them.
- deleted 7y ago
  [deleted]
SkyBelow 7y ago
>when I asked them about non-functional requirements, they had to ask what they were, and why they were important. Based on my own experience with NFRs, these are perfectly reasonable questions.
- kevan 7y ago
  We're missing a lot of context about this situation to tell if anyone was being unreasonable. A reminder for everyone: unless you're all in on waterfall with complete specs, user stories are placeholders for a conversation. Talk to each other and assume good intent on all sides until proven otherwise. You'll have a much more enjoyable work experience than if you dig in and make things adversarial.
- Qwertystop 7y ago
  I think this is a parse issue -- is this > I asked them about [the non-functional requirements for this project] and they had to ask [please give me details on those requirements] or is it > I asked them about [non-functional requirements as a general concept] and they had to ask [what are these new things you speak of, I have never heard of such a thing] ? The former is reasonable, the latter less so.
  - SkyBelow 7y ago
    For me, it was more "These things you call NFRs, I do not understand the purpose of them, especially given how they are decided." Requirements like "The system must be secure.", "The system must not go down.", or "The system must not have performance issues." I'm lost as to what the purpose of such statements are as they don't let me know where real focus needs to be given. Not every system is mission critical and deserves equal resources devoted to ensure uptime.
    - DougWebb 7y ago
      As developers, the most useless bug reports we get are "It's broken". The NFRs you describe sound like "The system must not be broken", which probably makes a lot of sense to someone who's likely to submit a useless bug report.

dfjhdkjfhsdkf 7y ago

I agree with your comment about senior devs. it seems as devs climb the ladder many get a superiority complex where they could do things quickly and others cannot. I was once a tech lead of a team where the architect had been berating and criticizing a team member for weeks over something he thought should take a day. I suggested he should take over and complete it. It took him weeks to complete.

jimrhods23 7y ago
"I was once a tech lead of a team where the architect had been berating and criticizing a team member for weeks over something he thought should take a day" As I've gotten more experience as a developer, I've realized that most tasks take longer than I used to estimate..usually because I want to come up with a long-term solution and not just hack something together with no testing.
rdiddly 7y ago
the architect had been berating and criticizing a team member for weeks If berate is truly the appropriate word (upon investigation), and I had any say in the matter, I would fire his toxic ass immediately.
funkymike 7y ago
I'm sure I still have far to go, but currently when I see someone quote a time frame for a change I am more concerned when it is short vs. seems too long. Especially when the dev is questioned and the estimate doesn't include time for documentation, deployment, etc.

VBprogrammer 7y ago

To be fair; non-functional requirements as a separate entity are pretty much wank. If you need a line in a document to tell you that exposing privileged information to the outside world is a bad idea, or that you should make sure the solution you are designing has a reasonable chance of servicing the expected load then you probably shouldn't be a developer. The last time I seen explicit non-functional requirements the had something like "the solution should have a 99.99% uptime." I realised that our down time for releases (old school I know) was more than that and promptly ignored them.

deleted 7y ago
[deleted]

SkyBelow 7y ago

>when I asked them about non-functional requirements, they had to ask what they were, and why they were important. Based on my own experience with NFRs, these are perfectly reasonable questions.

kevan 7y ago
We're missing a lot of context about this situation to tell if anyone was being unreasonable. A reminder for everyone: unless you're all in on waterfall with complete specs, user stories are placeholders for a conversation. Talk to each other and assume good intent on all sides until proven otherwise. You'll have a much more enjoyable work experience than if you dig in and make things adversarial.
Qwertystop 7y ago
I think this is a parse issue -- is this > I asked them about [the non-functional requirements for this project] and they had to ask [please give me details on those requirements] or is it > I asked them about [non-functional requirements as a general concept] and they had to ask [what are these new things you speak of, I have never heard of such a thing] ? The former is reasonable, the latter less so.
- SkyBelow 7y ago
  For me, it was more "These things you call NFRs, I do not understand the purpose of them, especially given how they are decided." Requirements like "The system must be secure.", "The system must not go down.", or "The system must not have performance issues." I'm lost as to what the purpose of such statements are as they don't let me know where real focus needs to be given. Not every system is mission critical and deserves equal resources devoted to ensure uptime.
  - DougWebb 7y ago
    As developers, the most useless bug reports we get are "It's broken". The NFRs you describe sound like "The system must not be broken", which probably makes a lot of sense to someone who's likely to submit a useless bug report.