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?


 

Comments (9)

  1. Johnny Hall says:

    I’m with you. I want to feel like I’ve mastered version 1.x before I move to 2.0. Or at least become competent.

    I’ve been working with .NET since the beta and been writing "production" software for over a year and I feel like I have only scratched the surface.

    And I’ve got to help developers who are only just starting out.

    2.0 can wait.

    Disclaimer: I’m actively awaiting certain key features, including Refactoring support, Generics and SQLXML 3.0 being natively supported in .NET.

  2. wOOdy says:

    Typical VFP projects even tend to never stop. I know of at least ten developments, which just add features, changes and adoptions due to business needs on a weekly basis. Such projects are difficult to move to a newer VFP version in between and it’s even impossible to switch to a completely different development tool. You can’t go to you boss and say "We stop development for at least a year, because MS thinks we now have to switch to <InsertYourFavBuzzword.Net>". It’s just not possible in real life.

    In VFP’s world, Updates are always welcome because they provide a fully backward-compatible way of incorporating newest technologies (like XML or Webservices) and of course urgently needed bugfixes, without breaking the ongoing development process. Thus: yes, I want updates. Now and as often as possible 😉

  3. Desmond Lloyd says:

    Am inclined to agree with Mr. Koziol and the other "remarks" as well.

    Mr. Hall has a very valid point, of course, however what constitutes (as you pointed out so eloquently) a minimal amount of knowledge on a particular development tool? So essentially it comes down to a "geek" thing, if new features can be added that can expand the tools funtionality by all means bring it on…. (as wOOdy points out)

    The next step if for the vendor of the tool to decide on what features are "add ons" and which ones are overall enhancements or improvements to the tool in general.

    BTW very good points on the life of a VFP project. Surely that is applicable to a whole range of other development tools out there as well… The eternal project, more improvements and enhancements!

  4. I have to agree (to a certain point). I’m not sure how productive a dev team would be when they are trying to build something on an alpha platform, which is prone to breaking, therefore causing a work stoppage issue, and quite possibly a whole lot of refactoring. Heck, I’ve been "drinking from the firehose" for the last 4 years, and while I do have a better understanding of C# than I did 4 years ago, I still haven’t "mastered" the IDE or the language. Most of my projects haven’t even touched certain areas of the .NET frameworks, like remoting or winForms…

  5. John Koziol says:

    Woody raises an interesting point insofar as perpetual projects go. IMHO that’s usually an indication of a good application as the customer is very happy with what they have and keep asking for enhancements or expansion. When the application is a miserable piece of crap <g> then the project will continue with a rewrite – you just won’t be involved.

  6. Aaron Lewis says:

    "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?"

    For myself, and I’m sure quite a few others, it’s about not wanting to fall behind. You see, our tool and platform vendor (someone you know!) happens to enjoy it when we give them money. In order to get more of it more frequently than 6 years, they release new versions of the tools in increments that span — important, pay attention — *less* than 6 years.

    What you see replying to blogs will most likely be a small minority of the overall development population, and not necessarily representative of the majority. So when you see a person freak out over, say, generics in a future release of C#, remind yourself that you are dealing with exactly that. A freak.

    lol

  7. Dating says:

    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 concep

  8. Weddings says:

    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 concep