Experience-rated development (by John Koziol)

Before Microsoft made the mistake of actually hiring me (heh), I worked as a vendor to the company for the VFP 6 certification tests. The test teams always debated what could reasonably be expected knowledge of a developer. You see,  at that time the concept was to find the MQC - Minimally Qualifed Candidate.  What magic set of knowledge indicates that someone should be certified in a tool?

I'll never forget that Ted Roche, one of the team members, made a fascinating point - VFP projects tend to be line-of-business oriented and can take 6-12 months from conception to fruition. Therefore, at the time (1999), no one could reasonably be expected to have worked on more than 8 projects or so sice the product debuted Summer 1995. That assertion, which I find very true, made a big impact on me as to how I evaluated an MQC.

Fast forward to 2004 - We live in a world where new versions of developer tools come rolling out every 2 years or so, with all new features and enhancements. Back in the old days (I'm dating myself), we dealt with COBOL ANSI-68 or ANSI-74.  A 6 year difference, and the changes were not that severe.

So when I see folks pining away for a new version of a tool, I have to wonder how much experience they've garnered in the real world with the prior version that was just probably released within the last 24 months. Mind you, I'm not arguing against adapting the latest and greatest - better to have a P-51 than a Sopwith Camel and we'll figure out the fuel injectors later - but what is the compelling reason for folks to always look to the next version? Is it a geek-gadget thing or is there a method to the madness?