The growth of Agile and associated techniques like TDD and BDD has put a significant focus on delivering functional requirements via stories and automated tests. This is in part a side effect of the productivity of teams often being measured in terms of story points, bug counts and test coverage.
Unfortunately this can leave non-functional requirements like performance as secondary concerns. Clearly premature optimization is the root of all evil (actually I find micro-optimization a better euphemism); that said ignoring your non-functional requirements isn’t going to make them go away. As Simon Brown puts it in his Frustrated Architect article:
“Non-functional requirements" not sounding cool isn't a reason to neglect them.
Q: How can we make this palatable to “Agile” teams?
A: Provide a simple methodology for making a system’s key performance indicators (KPIs) visible and give it a shiny new “x-driven development” name to make it sound vaguely hip.
The article Stuff that works – Performance Driven Development outlines the key points:
- PDD is a common sense iterative development approach
- Developers have to create Key performance Indicator dashboards. (KPIs)
- These KPIs are created and updated continually throughout development. Not as an afterthought.
- These KPI dashboards are always available in real-time
Borders
Back in the 80s and 90s CRT screens were prevalent running at 50Hz or 60Hz. Action video games would typically attempt to update at a constant rate. Game developers would change the border colour of the CRT to visually measure how much time different parts of a program used. This gave immediate feedback on the performance impact of changes to the code. Unfortunately LCDs don’t have borders.
Similar psychedelic effects can be achieved in Silverlight using the EnableRedrawRegions property and the frame rate monitored with the EnableFrameRateCounter property.
Counters
Performance can be equally important for server side components. Predetermined performance data can published as counters and viewed in tools like Perfmon.
For some components I’ve implemented a simple Telnet server as a way to query a running component with specific parameters.
Another slightly more accessible option is to expose KPIs via a lightweight web framework like Nancy or Sinatra, and so make them easily visible on a web page.
Conclusion
Identifying key performance indicators for your system and having them visible early on in the project should help make it more likely that to your application’s performance is in sync with requirements. The good news is that there are plenty of fairly lightweight mechanisms to make this feasible. Now go read: