I should point out that I drastically simplified what was involved, attempting to give an idea of the scope rather than the nitty gritty details. In fact they helpfully provide a set of schema files defining exactly the class layout for each class read in each version. Much of the actual work involved figuring out how to interpret those files into useful code. And of course we did not try to support parsing every possible class from every possible version before we tried importing simpler files from the versions we already understood. Believe me, if anything I am too impatient to see real results rather than too patient.

My fundamental point was that it both took a long time to develop the parsing stage and there was no opportunity for useful customer feedback to be had during that development. In order to make a marginally usable importer, the code had to be able to parse nearly every type. The customer could not tell me what to skip. There was just no way for them to provide useful feedback at this stage other than "these are the sorts of files we need to be able to read."

As a programmer, I aggressively attempt to not implement features my customers do not need. It is the only plausible way to write this sort of code as a one-man shop. But as feedback, it usually works the other way around -- I implement the minimum needed to make the files they send me work for them. So it's not me saying "Do you need this?", it's them saying, "Hey, we need this."