Preferences objects present a way to store arbitrary data into Rally which can be combined with other Rally information.
For example, if I want to calculate defect density and see a graph in Rally, I can’t because I don’t have KLOC information in Rally. But if I write a script that periodically drops my current line count every iteration or so into a preference object of a well know ID, I can do this easily.
But should I? And if so what are the limitations of preferences objects in Rally? How much data can I safely store in them, and how many preferences objects can the system reasonable handle? Is it hundreds, thousands, tens of thousands? Our instance already has thousands of these just from standard apps that are installed, so it looks like the answer is at least thousands.
We currently do not place any restrictions on the use of preferences and frankly, I don’t think we know the limits if its use. For the load that you are suggesting, I suspect you will not exceed those limits.
On another front, I’d love to hear more about the analysis that you have in mind. Before coming to Rally, I have done a bit of work using LOC to normalize metrics as well as to heuristically determine artifact dependency. Now at Rally, I have both the analytics features as well as the connector features within my domain of responsibility as a Product Owner and I’ve been exploring ways to responsibly use LOC at Rally.