In your example there are ways to do development incrementally. You could generate some files that only use a tiny subset of the features of Parasolid, in only one version. Once you have that working you can add feature and version support incrementally guided by your customer's priorities, which they might not even be aware of themselves but can easily be found by testing your code on a sampling of their most important files. Your incremental progress is loading of files with progressively more features, closer to your customer's files. It might turn out that you can avoid implementing every version and feature of the format, and it's much easier, faster, and more accurate to figure this out by testing working code than trying to write a spec ahead of time.
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."
Comments
In your example there are ways to do development incrementally. You could generate some files that only use a tiny subset of the features of Parasolid, in only one version. Once you have that working you can add feature and version support incrementally guided by your customer's priorities, which they might not even be aware of themselves but can easily be found by testing your code on a sampling of their most important files. Your incremental progress is loading of files with progressively more features, closer to your customer's files. It might turn out that you can avoid implementing every version and feature of the format, and it's much easier, faster, and more accurate to figure this out by testing working code than trying to write a spec ahead of time.
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."