Wednesday, August 27, 2008

Poll #2 Closed, Poll #3 Opened

The results of poll #2 are in. The question was "What is the optimal recertification period?". Twenty-four votes were cast. The results were:
  • 1 year: 0 votes (0%)
  • 2 years: 9 votes (37%)
  • 3 years: 8 votes (33%)
  • 4 years: 4 votes (16%)
  • None, once certified always certified: 3 votes (12%)
So the majority seems to be in favor of the current recertification period.

Now for a new poll. This one concerns the recertification method. Realistically we have to expect recertification to cost money, so let's put that aside. What else should be required?

Currently a test is required for recertification. But other professions use different models. For instance, I'm a Professional Engineer in the state of Michigan. Recertification in Michigan requires only a fee. No testing is required. In other states there are requirements that a certain number of Continuing Education Units (CEUs) be earned during the certification period. CEUs are earned by taking classes, attending conferences, giving presentations at user group meetings, attending user group meetings, etc. Should CEUs be introduced into the LabVIEW certification system? For instance, perhaps CEUs could be used to waive the test. Earn enough CEUs and you don't take a recert test, but if you fall short you do take the test. Or perhaps CEUs should be required in addition to the test. Cast your vote in the poll and let me know what you think.

1 comment:

Anonymous said...

Hi Tom,

For lack of a better place for this... I took the CLD recently (still out for grading), and it made me wonder how well NI's doing on their own standards. While there's too much that is subjective to measure, a quick troll through vi.lib shows (arbitrary thresholds):

Description 12385 empty of 17786 checked (69.5%)
Tipstrips 98245 empty of 99307 checked (98.9%)
# nodes: 424 items above a value of 100 (2.5% of the total)
# signals: 1253 items above a value of 100 (7.5% of the total)
# structures: 71 items above a value of 30 (0.4% of the total)
# diagrams: 125 items above a value of 50 (0.7% of the total)
diag depth: 288 items above a value of 6 (1.7% of the total)
# controls: 209 items above a value of 12 (1.2% of the total)
# indicators: 39 items above a value of 12 (0.2% of the total)
# inputs: 82 items above a value of 12 (0.5% of the total)
# outputs: 17 items above a value of 12 (0.1% of the total)
# global reads: 4 items above a value of 12 (0.0% of the total)
# global writes: 93 items above a value of 1 (0.6% of the total)
# local reads: 10 items above a value of 12 (0.1% of the total)
# local writes: 161 items above a value of 1 (1.0% of the total)
# attr reads: 17 items above a value of 12 (0.1% of the total)
# attr writes: 50 items above a value of 12 (0.3% of the total)
# cins: 11 items above a value of 1 (0.1% of the total)
# dlls: 1919 items above a value of 1 (11.4% of the total)
diagram width: 8270 items above a value of 1024 (49.2% of the total)
diagram height: 2614 items above a value of 768 (15.6% of the total)

Overall, not bad, but their documentation could use a lot of work, and their diagram sizes...

Do you think NI should devote time and effort making their own legacy code match up to the CL(A/D/AD)?