No, I am not referring to Einstein's theory of relativity (though I can draw some parallel if I really think about it). Something I was reading in an algorithms/data structures book recently hit a profound note in my thinking, though we all have learnt and overlooked it at times. The topic was on analysis of algorithms using Big(O) notation, and the words that hit home were “relative rates of growth”. We all have learnt this before and understand the simple matter of comparing algorithms based on their growth rates. But when we think of comparing the relative rates of some functions, we are not talking about comparing the functions themselves anymore. For instance, say that f(n) = N^N and g(n) = 1000N. It does not make sense to say that f(n) < g(n), which will be true for all N less than or equal to 1000, but false for all N greater than 1000. Therefore, it is the growth rate of f(n) that is compared relative to the growth rate of g(n). In this context, it makes sense to say O(f(n)) > O(g(n)).

This made me jump track and think of Agile estimating. We estimate a base story and then estimate the remaining stories in the backlog relative to the base story value. There is no specific unit defined, but we call them story points. There is no specific time unit associated with the relative growth rate of an algorithm, or the relative complexity of a user story, but we use them in order to make some pretty important decisions in our work. We compare one algorithms complexity relative to another, and estimate task complexity relative to a another ‘known sized’ task. This makes me wonder, what else do we knowingly or unknowingly measure in relative terms in our day to day work?

There is little doubt that measuring something in relative terms produces more accurate results than say, labeling a specific time unit or complexity unit to a mathematical function or user story. It helps us measure and calculate things to large degree of accuracy, and has quite a number of similarities with relativity in physics in my opinion. One such similarity is the concept of a frame of reference: in algorithm analysis, a frame of reference could be the computer platform that the algorithm is run on, in agile estimation the definition is a bit fuzzier but could be the team size for example. You could come up with certain relative values in one frame of reference, and a completely different set of values in another, whether its relative story points, growth rates, or velocity (in physics). It’s interesting to see where this kind of thinking can lead us, and even more profoundly interesting would be to see the hint of a large as-of-yet undiscovered unified software theory of relativity, lurking under the bits and bytes out there waiting to be stumbled upon and discovered.