Philip,
Thanks for clearing that up.
I think it's more useful to think in terms of optimizing quality and productivity rather than process, and to think in terms of changes in productivity and quality rather than what constitutes an absolute level of high productivity and quality.
Right. That is what I meant. I actually wanted to write about productivity but, I choose process because I thought it encompassed productivity. I now see why they are different.
I now see the goal of our projects; To be able to introduce "fixes" that will optimize quality and productivity. In my case, focusing on quality improvement, the fix will be a quantitative approach for recommending reviews. In Cedric's case the "fixes" encompasses a lot more possibilities, because he has an a couple additional variables, ie (1) Quality, (2) Productivity, and (3) Quality and Productivity combined. Not to mention, Cedric will have to be able to evaluate whether or not a "fix" did the job in correcting the ups and downs. (that's why he is doing a PhD thesis and I'm not. haha)
I guess the whole point of my previous email was to try to narrow down the scope of what Cedric was trying to do. In my view it seems that it will be perfectly reasonable to tackle the three variables (Quality, Productivity, Quality and Productivity) separately and not try to do them all at once. I suggest taking a look at productivity first because that seems easier to detect changes in.
Notice that I changed my use of "process fixes" to just "fixes". I did that because it seems that if our software development process involved basing decisions on Telemetry then we aren't really introducing a "process fix". Instead, we are just simply fixing quality, productivity, or both.
thanks, aaron
