I really dislike the term "non-functional requirements". It makes them sound less important to business.
I often try to turn them into functional requirements. This is easy for performance as there generally is a goal of throughout and/or latency. Quite often this requirement is untouched up to the point it is in production, and then the escalation happens. Which generally puts devs in the losing position even though no agreement was made. Management usually wants to make the customer happy despite them asking unacceptable results marked as defects rather than changes. (i.e. free work)
As mentioned you need to architect for the illities. Making something scale in a certain direction needs architectural decisions in the beginning. Decisions which cannot easily be changed when development is (almost) done.
Other illities like quality and maintainability I find really difficult to change into functional requirements. Projects generally want to finish as quick as possible taking shortcuts which hamper these illities. Trying to convince business that we need to put effort in these is not something I've been really successful in. They always think it's quicker to skip these things, and do it afterwards when there is time. I am quite often involved in the unicorn project where things will go differently, or so they think.
Thanks for the insight. Regarding the more nebulous illities, I certainly agree that lacking a functional requirement makes them harder sells. For quality and maintainability, do you have an opinion about using metrics from testing or static code analysis? I know they are controversial and can be gamed, but seem tricky to track otherwise. I'm also interested in trying out Adam Tornhill's techniques where complexity itself is not inherently bad, but complex code that is constantly changing and associated with bugs may be.
I have a love-hate relation with metrics. They require a lot of work to use. You cannot simply enforce rules like a maximum fan-in or cyclomatic complexity. Breaking up something because it goes over a certain metric just slightly is just wasting effort.
A lot of thing within a (physical) library are about books. Almost everything refers to books, that does not make the design of 'book' bad, just a place which has a lot of impact if it needs changing.
Looking at metrics over time is where things are becoming more interesting.
Complexity is only a problem if we need to deal with it. If no one needs to read or modify a particular part of the code, does it really make a difference whether it’s complex?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I really dislike the term "non-functional requirements". It makes them sound less important to business.
I often try to turn them into functional requirements. This is easy for performance as there generally is a goal of throughout and/or latency. Quite often this requirement is untouched up to the point it is in production, and then the escalation happens. Which generally puts devs in the losing position even though no agreement was made. Management usually wants to make the customer happy despite them asking unacceptable results marked as defects rather than changes. (i.e. free work)
As mentioned you need to architect for the illities. Making something scale in a certain direction needs architectural decisions in the beginning. Decisions which cannot easily be changed when development is (almost) done.
Other illities like quality and maintainability I find really difficult to change into functional requirements. Projects generally want to finish as quick as possible taking shortcuts which hamper these illities. Trying to convince business that we need to put effort in these is not something I've been really successful in. They always think it's quicker to skip these things, and do it afterwards when there is time. I am quite often involved in the unicorn project where things will go differently, or so they think.
Thanks for the insight. Regarding the more nebulous illities, I certainly agree that lacking a functional requirement makes them harder sells. For quality and maintainability, do you have an opinion about using metrics from testing or static code analysis? I know they are controversial and can be gamed, but seem tricky to track otherwise. I'm also interested in trying out Adam Tornhill's techniques where complexity itself is not inherently bad, but complex code that is constantly changing and associated with bugs may be.
I have a love-hate relation with metrics. They require a lot of work to use. You cannot simply enforce rules like a maximum fan-in or cyclomatic complexity. Breaking up something because it goes over a certain metric just slightly is just wasting effort.
A lot of thing within a (physical) library are about books. Almost everything refers to books, that does not make the design of 'book' bad, just a place which has a lot of impact if it needs changing.
Looking at metrics over time is where things are becoming more interesting.
Talking about Adam Tornhill, his book Your Code as a Crime Scene is on my to-read list.