Comment by badminton1 | Hacker News Reader

Comment by badminton1 | Hacker News Reader

Agile enthusiasts really enjoy applying agile methodologies to functional requirements such as user stories.

But non-functional requirements are rarely explicit: security, reliability, redundancy, durability, concurrency, performance, scalability, configuration, deployment, documentation, logging, monitoring, supervision, maintainability, construction for verification...

You don't get a user story saying: "as a user i would like my information to be private" or "as a user i would not like to experience a concurrency bug".

To neglect those non-functional requirements in favor of perceived progress is not in the company's best interest. A solution that doesn't comply with those requirements also has a name: a functional prototype. There's a difference between developing production software and developing prototypes, even if you consider yourself agile.

Now, as a software engineer, you should be able to identify these requirements and include them in estimations. You can also ignore them, and project an image of a highly productive engineer, but some day your code will crash and you won't have 10 days to fix it. That day you will be miserably fired to the sound of a trumpet.

I think most successful agile teams would adopt those non-functional requirements not as tasks to be implemented but as cross-cutting concerns of all work. Ie, on a Scrum team they could be part of the Definition of Done, ie "Is the code maintainable" which would not allow some work to be considered completed until it met that definition.

I'm not 100% clear on what you are saying but it sounds like you think agile teams ignore these non-functional requirements in favour of perceived progress on features. I think that may well be true in practice but it is also true of non-agile teams. It is in fact just true of immature development teams the world over. Being agile or not has nothing to do with it. Scrum and other processes do at least try to have something in place to cater for these requirements, which often sadly get overlooked when pressure is applied to make flat out progress on features.

I concur. But it was mostly in response to the article.

I do believe though that there are many engineers that highly disregard good practices because they get a political benefit from releasing more.

Just like politicians get appraisal when doing ribbon cutting at inaugurations, and never when repairing a bridge, many organizations promote the engineers that deliver more features, not the ones that keep the system working.

By doing this they create a culture of technical debt and failure.

> You don't get a user story saying: "as a user i would like my information to be private" or "as a user i would not like to experience a concurrency bug".

Uh, you do. You totally do.

"As a User, I want the site to appear on my browser quickly".

In acceptance criteria, "Quickly is defined as 98th percentile 400ms full roundtrip to AWS US-east-1".

How do you do this? You write a test. What kind? A performance test. When does it run? Every time you check into CI.

How is this different from standard agile practice?

It isn't.

The quote is about 'privacy' and your user story is about 'speed' - these are different criteria and 'privacy' is much harder to specify in a user story.

That's what I get for reading too quickly :)

I focused on performance because that's one example I've had brought up several times. And it's probably the easiest one.

I've seen privacy stories too. The style I like is to create a malicious user and deny them.

    As a Malicious User
    I want to steal credit card numbers
    So that I can sell them on the black market

    Given I have access to the web app
    When I supply malformed URLs
    I am ignored

    A/C
    Pentest tool with decent corpus

Another approach, also used, is exploratory testing. Security and privacy are tricky because you're dealing with humans who can react creatively; so the best test is humans who react creatively.

A functional requirement is like adding a room to your house. A non functional requirement is defining what the construction material is and what the construction standards are.

What you describe is like constructing a house, then once it is constructed, specify it needs to be earthquake resistant. That should be specified as an upfront requirement not a story.

If you construct it, and it was already earthquake resistant, should not be a problem. But if it wasn't, you will need to rebuild.

> What you describe is like constructing a house, then once it is constructed, specify it needs to be earthquake resistant. That should be specified as an upfront requirement not a story.

There's no law against writing every story with some NFR component, or interspersing NFRs with regular feature stories.

The process of writing, test-driving and accepting stories is a framework, it's guidelines. When I or other engineers see obvious architectural landmarks ahead, we often encourage the product managers to bring those forward.

A story can have user value, and it can also have business value outside of user value. One such business value is attacking architectural risks.

And sometimes you tell business "this unaddressed architectural scope is a big risk", and they say "OK, let's fix it".

And that is still agile. The point was never rejecting high ceremony in order to replace it with low ceremony. It was that professionals should talk to each other. Constantly.

NFRs can be hard to add once something is built.

Nobody is arguing with that. But it's also very wasteful to build an earthquake resistant house in a geologically stable area. You have to talk it over.

Reply on news.ycombinator.com