Back when Visual Basic was still a Thing, I worked as a contract programmer for a shop that rented us out to 2 rival testing firms; each had contracted with our shop to write functionally identical testing software. I was never the greatest programmer you ever saw - as with so many things, my abilities are far humbler than I am - but I gave good testable valuable for pay, and there was a programmer shortage, so hey!
Those two clients did skills certification examinations for "ReallyBigCompany, Inc". ReallyBigCo wanted the exams to adapt to the skill level of the test taker, which we peons understood that to mean that, rather than just rattle off 10 randomly selected questions from a database of 1000, we would start with a question of moderate difficulty; if the testtaker gave a right answer, the next question was harder; if the testtaker gave a wrong answer, the next question was easier.
We all thought this was a cool way to get a more precise measurement with fewer questions, and I regret that I did not get to work on the exam engine itself.
Instead, I worked on the part where each testtaker practiced taking the test. We had 6 or 10 question formats. Most questions were not mere Multiple-Choice or Fill-In-The-Blank; we had Connect-The-Squares-In-Logical-Sequence and Draw-The-Diagram and Put-The-Boxes-In-Order and more. Fun!
Three problems surfaced:
The 1st was both technical and organizational. Our company geniuses hadn't yet worked out how to get the Large XML File Of Questions And Answers into the program, and management didn't seem to understand that it's hard to test if you can't use data. Until that part got written, we were stuck, but being stuck meant we weren't making progress.
I reached back into my memory of BASIC-Before-Visual-Basic for a trick: treating the text file as a string of parameters.
I learned-by-doing that each parameter was limited to 80-bytes (probably a relic of Hollerith cards - from before BASIC was even a thing - and so, ultimately, of Jacquard looms) but that was ok; I just strung them together into one Ridiculously Long String, and away we went!
I packaged this neatly in a module so whoever ultimately installed the database would have to change only the one thing, and we got back to work. No else on the team understood or cared, just so long as it worked.
The 2nd problem was designing the training interface. We wanted the test to be Fair, so that testtakers who had practice taking tests online would not have an advantage. This was not hard for some types of questions, such as "pick the best word to fill in the blank" but other question types made us stop and think.
Think about "draw arrows between these squares representing operations in the order they must occur". You can probably think of several ways to tell a program to connect boxes with arrows, some more intuitive than others. We certainly did! For example, you could click on the first box and then the second box to make an arrow appear connecting them. Or you could click on the first box and hold down the mouse while moving it toward the one you liked; the arrows would follow your mouse until you lift up on the mouse button. And so on....
Management rejected the easiest, most intuitive methods because they were already in use in popular software, and that would give an advantage to testtakers familiar with them.
Management rejected the hardest, least intuitive methods because they sucked.
Ultimately management accepted a method of such surpassing mediocrity that no commercially successful software ever used it, yet it just barely did not actively obstruct getting the task done.
What was the method, you may ask? Sorry, my brain, in self-defense, long ago purged the memory. Only the horror remains.
The 3rd and boss problem was that we were writing the same software for two different companies (remember?). They were giving the exact same test for ReallyBigCo and so, unsurprisingly, had identical requirements.
They also, unsurprisingly, had terms in their contracts which forbade giving the work they were paying for to someone else.
We were not staffed to work on both contracts at once, so we started on the one whose name came first in the alphabet (I only assume that's how management chose, who knows?)
The day after delivery of its final version, our team met to plan doing the work for the other.
"This should go much faster," said the team lead, "since we have all the code from the last project."
"But what about the contract?," I asked innocently. "It explicitly forbids re-using their code for anyone else."
"No problem," said the senior programmer. "I'll write a quick macro to change all the module and variable names."
---
This is not why I'm not working there anymore, but in retrospect, it would have been a good reason.
