A break from assessment discussions over to programming. I’m in the middle of a classic “iceberg” programming task. Ever heard of that? It’s where something that looks pretty simple on the surface has a ton of obnoxious code underneath it.
Case in point: I’m adding a feature to the main Examiner system where you can create an assessment and only score the top “N” items. You’ve all seen those: “There are 20 items in this test. You only need to answer 15. You can answer more, but you’ll only be scored on the highest-scoring 15″. Sounds simple, right?
First off… I’ve got to fold this into my existing scoring system without breaking anything. That’s not too hard as all this code is pretty much isolated from my regular scoring. Now it gets messy. Do I figure mastery based on percentages? Do I count in the percentage ALL the items or just the ones that were answered. Do I simply set an absolute mastery point?
Next… how to report things. I want to show all the items, how do I differentiate one from the other.
Case studies (scenario questions). Do I treat each item in there as a single item or do I treat the whole item as a single entity for scoring purposes.
Finally… what about multi-part tests? What if some of the sub-tests use the top-N method and others don’t.
*woof* Each of these decisions leads to piles of code. AND piles of QA testing.
So, when you see some Neat Little Feature in a program, any program, you’re often seeing the tip of a giant iceberg that’s below the surface where all the magic really happens.
OK. Back to programming with a break to see Avatar this afternoon!