I suggested that quite a few times in fact, but the answer was always 'there is no money' so the only thing to do was to try to somehow make it work. (edit: and because I almost always found a way 'Fred' became convinced that that was just me trying to get out from under work that I could do but didn't want to do, so every time I managed to fix something[1] I proved him right in a way deepening the misery and the complexity of the next challenge).

Another option would have been to take time out to study the underlying theory better. The initial spec was trivial, if there had been any indication of how immense the requirements were going to be I would have either refused the work or I would have taken out a year or more to educate myself on the subject matter.

Funny thing though, even now, knowing as much as I do I would probably refuse that job. This is not a one person thing, there are too many specialties involved and the codebase is far too large for a single person. The demands placed on such software have only gone up over the years.

One thing is funny though, even today in terms of ease of use the UI I came up with still is better than anything else on the market, as is the toolpath optimizer that is built in.

Eventually, during the creation of a parallel development (the milling software, which I've left out of the story, it would not have added too much I though, but now I realize it would have added one more thing), I got so stuck on a piece of very hard math that I managed to convince Fred that we needed outside expertise and by great exception I was allowed to spend some money on a consult with a real mathematician.

Another thing where we brought in an outsider was when the display requirements went up way beyond the initial spec (real time zoom during the runs), I was allowed to hire a friend of mine (Maurice), a guy that I'd worked together with on programming games to write a chunk of assembly given a datastructure. This was doable because it was a fairly isolated part of the code, but Fred was totally paranoid about bringing on board other programmers having access to large chunks of the source.

[1] A nice example of such a situation was when we had to do the thread cutting that was so easily discarded in the beginning after all. This required a synchronization with a third axis spinning at anything between 50 and 1500 RPM or so, yielding a pulse train of up to 25Khz, something that none of the interrupt inputs of the chosen computer could handle with any reliability, especially not while driving a stepper at the same time with very tight constraints on latency. Normally encoder output is fed in to specialized counter boards but those were way out of the budget, and besides would only fit the IBM architecture. So I designed our own counterboard, and fed the output in to the midi port with a bunch of trickery to be able to re-construct the position of the toolbit relative to the index on the main axis.

This was a very nasty bit of code, because it depended on a lot of things that could change in real time (such as the density of the material being hit, the supply of coolant and so on) and there was not a whole lot of margin for error here. Once a thread has been 'started' you can't back out, you have to complete the sweep. So what the program would do is look in a table to figure out how much lag we could reasonably expect after hitting the material with the toolbit, then measure the sitation as it actually occured and compensate. Eventually I got it to work reliably enough for production but of course that was a total hack.