Michael, As per Mark's comment above, examples of OO code without getters would be of interest. Do you know of any that are publicly available? (Even though, as your post suggested, precise thought probably trumps any particular technique -- even removing getters. Would still be interesting to see a good example.)

Apparently experienced chess players "see" the board differently from beginners. I suspect the same is true from code - and that there are non-narrative ways of "seeing" that develop with experience. There's an excellent recent book from Daniel Kahneman which goes into a lot of detail on this stuff. I posted a quick (and _very_ incomplete) overview here: http://www.agilekiwi.com/peopleskills/understanding-ourselves/becoming-an-expert/

Hi Glen, I didn't quite follow what you meant by this: 'the "blended" project performance can be easily hidden by "summing" the EV numbers' Could you elaborate on that point a little?

Correction, there are two common ways of doing (a) wrong numerically: (i) comparing actual and planned costs, which is the more common mistake on "less agile" projects; or (ii) comparing actual and planned progress, which is common on "more agile" projects. Both miss the point that the only valid measure involves comparing cost (AC) with progress (EV).

I see what you mean. Those things are indeed important to the overall success of using EV. So I wonder why I keep thinking that, in the sub-$5m agile world, those 11 criteria are not really "what it's about". I think this might be the reason why: The problem I have, in persuading people to use EV (in sub-$5m software dev), is not actually about those 11 things. They are probably doing the first 7 adequately already. Where they come un-stuck is that they are not actually "doing EV", by which I mean they are not doing these two things: (a) Assess your past performance by comparing actual cost to actual progress, numerically. (b) Assume your future performance will be similar (unless you take corrective action) Typically, they are not doing (a) because either the comparsion is subjective rather than numerical, or the numerical comparsion is of actual cost to budgeted cost(!). Typically they are not doing (b) because, firstly, it depends on (a), and secondly there seems to be a cultural preference towards subjective judgement and assumptions that future performance will somehow be better than past. (This preference seems to be encouraged, I was shocked to discover, by the EV section of the PMBOK guide). Once you start doing (a) and (b) then you automatically find yourself meeting criteria 23 and 25. That just leaves 26 and 28, which I agree are essential to getting value out of EV. I understand there are problems in some circles with people treating EV just as a reporting excercise and not actually using it by doing 26 and 28. But in the project cultures that I've worked in, that hasn't been a problem. If EV shows bad news, an appropriate degree of "panic" and problem solving quickly ensues. :-) So, I guess my original question was really asking whether you know of an appropriate label for (a) and (b), above. To me, that pair of concepts seems to be the kernel of truth which needs to be "sold" to the sub-$5m software community.

Hi Glen, Given your comments at the end of this post, what do you think would be an appropriate name for EV-like techniques that aren't traceable to the 11 key criteria? For instance, the EV-like approach I've outlined here http://www.agilekiwi.com/EarnedValueForAgileProjects.pdf is more-or-less traceable to the goals listed in the DoD’s Earned Value Management Implementation Guide, but I wouldn't claim to trace it back to the 11 "key criteria". Nevertheless, it seems really useful for projects in the range $50k to $5m - which is obviously a totally different size range from what you normally work with (but probably fairly common in the Agile world). In summary, it seems useful, but hard to name...

Glen, In the project's I've seen, many of the NON-Earned Value ones could have rightly claimed to be doing many points on the list of 10. For instance, they typically did all of the following: 1. Defined authorized work elements 2. Identified project organizational structure 6. Scheduled the authorized work in a sequential manner that identified the significant task dependencies 7. Identified physical products and organizations 8. Established and maintained time–phased budget baseline [admittedly not necessarily in the way an EV project might do it] 16. Recorded direct costs consistently in a formal manner 23. Periodically generated project metrics [OK, so they weren't EV metrics, but they were metrics] 28. Incorporated authorized changes in a timely manner All the while, they were doing their reporting by little other than actual versus planned spending! To me, the two points that those projects were missing are: 5. Provide integrated planning, scheduling, budgeting, work authorization, and cost accumulation processes [at minimum, compute AC and EV in comparable numerical units] 25. Develop revised cost estimates–at–completion based on performance to date [namely, performance to date as measured by #5, rather than any other so-called "measure" of performance to date] To me, those 2 are the heart of EV. I sometimes fear that, when there's another 8 wrapped around them, the core message won't stand out as clearly as it should. If the organisations that are not doing those two, would just start doing them, it would make a big difference. So, in the conversations I have, here in NZ, I tend to push these two "neglected" points, and not really mention the rest. So far, that approach seems to be useful, although I notice that it seems to be at odds with how even "simplified" EV is presented in the US. What are your thoughts about descriptions of EV that are more concise than the above "set of 10"? Is it stretching the point to even call them EV? (I suspect some would say yes, and some would say no.)

Interesting question. I'd agree with your assessment of where EV is applicable -- if we're talking about EV done in accordance with the full set of 32 ANSI-standard criteria. However I feel that the basic idea, of numerically comparing progress with cost, is applicable to virtually all projects. For instance, I find that principle to be extremely valuable even on projects with teams of 2 or 3 and durations of only a few months. So, perhaps the answer depends on what we mean when we say EV. If we mean, "EVM as it needs to be practiced on large wicked problems" then, yes, _in that_form_ EVM is only applicable to those problems. But, if we mean "comparing progress to cost, in a manner appropriate to the project at hand" then it's applicable to virtually all projects. It's this latter group of projects which I feel is missing out on the benefits of EVM, because practitioners in those projects (rightly) see the ANSI-standard approach as inappropriate to their needs, and then (wrongly) give up on the idea of EVM altogether. By the way, many of the smaller software projects I've worked on over the years still posses many of your listed qualities of "wicked" problems: novelty, no right or wrong answer, no stopping rule, and solution discovered (at least in part) through building it. So perhaps the difference difference between "full" and "light" EVM may depend more on project size than wickedness.

Glen, I wonder if its the case that there are two "audiences" for EVM. The first audience is people who are encountering it for the first time. Thinking back to my own learning, I believe that group needs to be able to see that it is _worth_ learning - i.e. there are benefits, and the difficulty is not as bad as it first appears. For people in this group, the fewer the acronyms, the more approachable the concept will appear (and the less likely they are to give up on it). The second audience is for people who are using it day-to-day. For them, yes, having standardized names for things (CPI etc) is valuable as you suggest. (One possible exception would be very small projects, outside the ANSI EVM standard. For instance, on my first EVM-like project I simply circulated a chart each week. There was no numerical report at all, and no mention of CPI etc - although in a sense all the key measures are still "there", visually on the chart.) Anyway, for larger projects, I agree with your point that its useful/essential to have standardized names for the concepts. The trick is perhaps to avoid having those names scare away the "newbies" ;-) Regards, John

@jdege That's the implicit test I mentioned: build it, and see if you have a problem. I did not mean to imply that was a bad thing to do. Generally, it's my preferred approach too. My concern with this thread is that _in_some_circumstances_ LINQ to SQL compilation is not one of the "small efficiencies" which Knuth criticizes, it can be a make or break issue for an application. This thread seems to inappropriately trivialize that possibility. I'm not advocating doing something "just because its faster", at the expense of maintainability; but rather being aware of problems which may arise, so we can make sure to test and profile the application thoroughly enough, and early enough.

Surely the big lesson here is that instead of blindly following the advice of Rico Mariani (or Jeff Atwood) we should _test_ to see whether compilation makes a meaningful difference _in_our_particular_application_. Jeff is conducting an implicit test, by leaving his queries uncompiled and seeing how that turns out. It's turned out fine in his case. I conducted the same implicit test on a recent project and it wasn't fine. Performance was particularly bad when using a very broad inheritance hierarchy of L2S entities on the 32-bit version of the CLR. @Jeff: By the way, your comparison may not be entirely valid. You wrote: "Then we compared it with the SQL variant; note that this is also being auto-cast down to the handy PostTag object as well, so the only difference is whether or not the query itself is SQL." The point to note is that materializing the objects (i..e. constructing your PostTag objects) is something that is greatly improved by compilation. In other words, L2S compilation does not just affect running the SQL, it also affects instantiating the result set objects. (Rico covered this in one of his posts IIRC) I believe a more realistic test is to run two versions of a linq query - one compiled and one not. (Leave ExecuteQuery out of the picture totally). When I run such a test, the compiled version takes about 25% of the time of the uncompiled version. That's for simple queries. When hitting a table that contains a very broad inheritance heirarchy, under the 32-bit version of the CLR, the performance differences is orders of magnitude.