[dsp1234]

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]

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.

[rdiddly]

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.

[jimrhods23]

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

[funkymike]

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]

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.

[SkyBelow]

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

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]

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.