Non functional requirements - a tale of two cities

I've been thinking about non-functional requirements lately. Ilities, some might say. It occurred to me that there are two classes of non-functional requirements: those that are visible to the user and those that are hidden.

Performance and usability are examples of non-functional attributes of the application that are visible to the user. I classify these as being "in front of the curtain"... or "part of the performance" (to use theatrical terms). Though attention to these issues is sometimes delayed to the end of the release, they occupy a high level of importance in delivery priorities.

Other non-functional requirements are backstage, and pretty much lead to efficiencies (or inefficiencies) for the development team. Examples include testability, supportability, maintainability and extensibility. These non-visible requirements bleed into visibility in some sense... for example, extensibility problems lead to delays in releases which impact follow-on release timelineness; poor testability leads to gaps in test coverage, which leads to bugs. But the impact of these issues often occurs long after the "current administration" has moved on.

I suggest that the order of priorities can be interpreted as 1) functionality, 2) speed of delivery, 3) visible non-functional requirements, and 97) non-visible non-functional requirements. Speed of delivery takes precedence.

Beware the "speed smell": sacrifices at the alter of speed, to the detriment of long term health of the system. In particular, beware these sacrifices being made by an administration that is poised to move on.