Hacker News Reader

Comment by dsp1234 | Hacker News Reader

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

View on HN

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.

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

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.

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.

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.

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

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.

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.

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.

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.

The purpose of those statements are to uphold contracts and compensation clauses when things go wrong and end up in court due to refuse of payment for delivering broken software (which might be debatable if that was indeed the case).

See, that would make sense if it was something like 'our system must have 99.9% uptime'. But to say it cannot have any downtime, at the same time as our releases requiring us to take it down during the release, and at the same time the business contracts allowing for downtime for releases, means that the NFRs do not have any realistic requirements and are thus useless.

It's like saying mobile devices must be supported. Does that mean only top of the line recent releases? Does that mean 8 year old smartphones? Does that mean the internet browser on the Nintendo DS?

Reply on news.ycombinator.com