4 ms·

Jacques, it was fascinating and terrifying to see how "over your head" the project became. Do you feel like hiring someone who had expertise in the industry wo

by mcantor 16y ago

Jacques, it was fascinating and terrifying to see how "over your head" the project became. Do you feel like hiring someone who had expertise in the industry would have been a good solution to the death march of iterative re-writes that you ended up locked into?

jacquesm 16y ago
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.
- dasil003 16y ago
  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. On the other hand, maybe you actually learned it faster this way. I guess it depends on how good you are at book learning, but there's no way to grok a process like jumping in and coding it.
  - jacquesm 16y ago
    Part of the problem here is that we're talking about fairly obscure knowledge, at a minimum you'd need a good sized library with articles about the problems you're trying to solve. This being the Netherlands such articles were not easily available and the www did not exist yet. So my sources of information where I was located were fairly limited. If I could have taken the time off I would have spent that time first on a literature search and after that on tracking down copies and reading those books. I agree with you that I learned faster this way but not as thorough and as deeply integrated as I would have liked, it usually was just enough to get the job done before moving on to the next crisis.
- patrickyeon 16y ago
  Thanks for the story. There were some very good lessons in it. > 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 I have a similar situation with the startup that I work for now. I've done some decent work, even though I don't nearly have the toolset (or background experience, tbh) that would usually be required or available. This has been interpreted as "you've validated working with what we've got" as opposed to "you can do impressive work, in spite of what we've got." Now I'm asked to do the usual improvements (better performance, more features, and lower cost), and expected to figure a way out with this "validated" workflow. I guess this is just a wordy way of asking if you have any advice on that matter. It would be appreciated.
  - jacquesm 16y ago

by mcantor 16y ago

jacquesm 16y ago

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.

dasil003 16y ago
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. On the other hand, maybe you actually learned it faster this way. I guess it depends on how good you are at book learning, but there's no way to grok a process like jumping in and coding it.
- jacquesm 16y ago
  Part of the problem here is that we're talking about fairly obscure knowledge, at a minimum you'd need a good sized library with articles about the problems you're trying to solve. This being the Netherlands such articles were not easily available and the www did not exist yet. So my sources of information where I was located were fairly limited. If I could have taken the time off I would have spent that time first on a literature search and after that on tracking down copies and reading those books. I agree with you that I learned faster this way but not as thorough and as deeply integrated as I would have liked, it usually was just enough to get the job done before moving on to the next crisis.
patrickyeon 16y ago
Thanks for the story. There were some very good lessons in it. > 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 I have a similar situation with the startup that I work for now. I've done some decent work, even though I don't nearly have the toolset (or background experience, tbh) that would usually be required or available. This has been interpreted as "you've validated working with what we've got" as opposed to "you can do impressive work, in spite of what we've got." Now I'm asked to do the usual improvements (better performance, more features, and lower cost), and expected to figure a way out with this "validated" workflow. I guess this is just a wordy way of asking if you have any advice on that matter. It would be appreciated.
- jacquesm 16y ago