Wow, Jacques, it doesn't sound like you feel much that "Fred" basically stole a bunch of money from you. You explain that you didn't have a contract drawn up, and that Fred's justification for not sharing proceeds from the company sale was that, after all, it was his money invested. I'm sorry, but if money invested was the only determinant factor in a company's success VC's would simply produce hits every week. Also, you may still feel some misplaced guilt/responsibility/loyalty to that venture, even in hindsight, but to me, looking at it as an outsider, it appears you contributed around 80% of the overall value to that company. Even Fred wasn't delusional enough to believe the company wouldn't crash and burn without you. You also say Fred was the "driving force" of the company. Yeah, sure, but he was riding on top of you doing the driving. This was a great and graphic story, and I'm glad you choose to look at the benefits of knowledge you took away from it, but man, that Fred seems a real charlatan/a-hole.
I've tried (very) hard not to let my feelings (in so far as there are still smoldering embers about this) either current or remembered shine through and to depict things as objectively as possible.
Part of that is giving credit where credit is due. The vision was his, the implementation, and dealing with the fall-out of all the bad decisions in every way except monetary (he never missed a payment of the agreed upon monthly amount) was mine. All of us, also those that were brought in later worked quite hard.
There would not be much point in writing this in any other way, the only thing you'd get out of that is that I am either vindictive or that I still haven't come to terms with all this, 20 years after the fact.
I think I have come to terms with it, I see it as a very expensive but ultimately very useful lesson that I apparently needed to learn in order to do better.
I'm sure Fred worked hard enough, but I think you're being lenient and modest to compare his efforts to yours. It's unbelievable the level of technical prowess you pulled off 20 years ago, by yourself, on an ill-advised platform, working so many hours that your wife left you, for a minimum base salary and the promise of equity which was later disregarded. You know better than I do, of course, but I can't imagine Fred truly appreciated or understood just how advanced the engineering work, and sheer hacking, you were doing was.
> but I can't imagine Fred truly appreciated or understood just how advanced the engineering work, and sheer hacking, you were doing was.
That is probably true, at the same time he knew full well to sell when I announced my departure so he must have had some idea. The interesting thing is though, in retrospect, the 'ill advised platform' brought out the best in me in many ways, and I wonder if I had learned as much as I did had the platform been more powerful. There's nothing more satisfying than taking something that any sane person would say can not be done and then doing it anyway simply because nobody told you it couldn't be done.
I think of the whole thing as a character building exercise ;)
And I have learned to have great respect for the people that make industry work, the guys behind the lathes and the mills, the 'operators' that have more knowledge in their pinky about metal and metal working than most people will acquire in a life time of book knowledge.
They taught me more about feeds and speeds and materials than I ever wanted to know. And they also taught me that I'll never be a good machinist, even though I'm safe and can make what I want I just can't spend the lifetime on gaining all that knowledge.
One nice anecdote about that. One guy was complaining about the precision, this was in a factory of gears called 'Mak aandrijvingen', the guy told me while listening to the machine (in a factory full of noise at that) that it was running about 1/100th wide close to the chuck.
I thought he was pulling my leg, brought out the micrometer, sure enough 1/100th wide. We adjusted the table a tiny bit with to reduce the offset but overcompensated, during the next trial run he told me it had gotten worse, probably around 0.05 mm. Sure enough, the exact amount was very close to that. After that I started to slowly believe that this guy was so attuned to his machine that he could hear how much material it was taking off and as a consequence knew how much was left. When he finally said it was good it really was. By then I was a firm believer :)
Truly amazing. Reminds me of the anecdote about Jim Gray wherein he was able to figure out that the database was not tuned based on the the hard disk noise.
I've heard stories about Ted Williams - the last baseball player to hit .400. A shipment of new bats would arrive for the team. He would look them over and pick some out saying "These ones are 1/8th of an inch too short."
Thanks for sharing the story. I was thinking that maybe a good course of action would have been to find some guy like the one you mention here and see if they were interested in being beta testers/consultants in exchange for getting the machine for free.
My dad and I are kind of like you and that guy, by the way. He's the shop guy with no schooling but almost half a century of experience building stuff, and I'm the one who knows all the math and computer stuff... ;-)
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?
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.
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.
Company-wide, with some occasional exceptions (but 'company-wide' refers to a dev team of four people). It is a boot-strapped startup so there isn't money to throw around either.
(edit: the more I think about it, the more I want to claim that it happens to me a little more, because I end up taking on the challenges and producing results, without the support I think I should have)
A couple of pointers: read 'the soul of a new machine' by Tracy Kidder, if you find yourself agreeing with the fact that you are 'signing up' then the problem may be on your end.
But the fact that you think that it is company wide suggests the issue may be with your management.
In that case I would confront them with this. Maybe suggest that that is not a long term workable solution and if they refuse to change tack start looking for other options or put down your foot once to see how they respond to that.
good luck, that's a tough situation to be in.
Don't fall like I did for the 'I've already invested so much in to this, one more thing I can do' trick, that carrot can be moved ahead of you for ever.
Thank you, again. I like to think I'm pretty good at ignoring sunk costs (the "I've already invested, I'd better keep on trying here" mentality), I think a bigger trap is that I'm an EE, and there is not much opportunity to be involved in research/design unless you have an even more advanced degree or a fair bit of work experience.
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.
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.
I wonder if having a catastrophic start-up experience is practically a rite of passage for the serious entrepreneur.
Obviously some people hit it big first time, but your very first business is obviously the one that's most likely to fail catastrophically, and if you can take that kind of blow (and it is a very big blow) and keep going, it's probably a predictor of success. Thoughts?
Because I don't feel like putting my private life out for the world to dig around in.
It's painful enough as it is to dig through this old stuff and to try to abstract out the lessons learned in such a way that someone might get some mileage out of it.
As for the private aspect, what happened is that we completely lost focus on what was important in life and what was not (or at least, I did) and that I allowed myself to be used in a way that was not healthy. The fights about money, the talks they would differ so much from one person to the next that I don't think that it would contribute much to the story.
I'm still in contact with the woman I was with back then, she has since found someone else to live with and has a really nice kid so at least I know that she landed on her feet. She was/is a good person that stood by me until she couldn't take it any more and I really don't blame her. After I quit the company we tried to get back together again but it never felt like it was before and it fizzled out.
The carrot was being held about a week to a month ahead of where we were all the time so we really believed that we'd be out of trouble shortly. And I think that 'Fred' believed that too, he was no longer objective about any of this.
I wonder if having a catastrophic start-up experience is practically a rite of passage for the serious entrepreneur.
Yes, but one in which bodily harm is also on the table? I've read a lot of entrepreneurial tales, but this one puts "sacrifice" and "earning your stripes" at a whole new level.
A lot of the successful companies I can think of were actually their founders' first-ever business attempt: Apple, Google, Microsoft, Oracle, and Yahoo, to pick some of the bigger ones. Of course, some luck was probably involved there that they managed to avoid a negative experience.
Thanks. A few things caught my attention which haven't been discussed yet in this thread:
that was some of the nicest work I ever did -- it's interesting how destructive processes can also produce great work. (This is not to say that the results are worth the destruction.)
Take the feedback you receive and use it to improve the product but unless something is really trivial it is better to sell what you have than to make some promise you can not keep -- another general lesson I would take away is, "be very wary when the salesperson is allowed to write the spec". I bet this is true across all business domains.
Fred never did hire a replacement, and hoped that I would stay on because I would not let my buddies down. -- I think this dynamic is built into the business models of some companies, especially consultancies. You feel guilty if you go home to sleep while your friends are coding 'til their eyes bleed, even when the overwork is brought about by extrinsic factors (see above).
>> You feel guilty if you go home to sleep while your friends are coding 'til their eyes bleed, even when the overwork is brought about by extrinsic factors (see above).
Been through that at the early stage of my career. It was a startup too. Right now if anybody trying to pull that out with me, its not going to happen again. If they should hire more people but not hiring, then its their problem. I'm not staying more than I should, and if I put on extra time (funny that I still do this a lot, I guess I just love what I do), its on my terms. Not happy, then let me know when to quit.
I also found out that when you go through the extra mile a lot, without proper compensation, they will treat you cheap. In a way, its sort of true, since if we put more effort that we are paid for, then we are cheap in that sense. Its easier to get respect when you just stick to your guns and politely declined those request for extra effort unless its paid up for. You may not get what you demanded, but its easier for them to treat you with respect (oddly!).
The lesson that I learned from my version of failed startup is that you should have the funder/entrepreneur to know the trade. Warren Buffet says never invest on anything that you do not understand. If the funder/investor/entrepreneur does not know the trade, then there is no way they could tell that you are telling the truth, other than pushing your buttons. And they will push your buttons, as much as they can get away with.
Its a good lesson learned, and I'm glad I'm through. But there is no way I am going through that again.
>I think this dynamic is built into the business models of some companies, especially consultancies. You feel guilty if you go home to sleep while your friends are coding 'til their eyes bleed, even when the overwork is brought about by extrinsic factors (see above).
why do programmers allow this tactic to work?
This is the problem; if you give me better work when I pressure you and treat you like shit than when I treat you respectfully and let you set your own hours, what do you think the result will be?
I think that tactic only works on the inexperienced (with people), as I was.
If you tried such a trick on me today I'd catch on in 5 seconds flat.
Part of it lies in that programmers are fascinated by technology, which means that if you give us shiny toys to play with and the occasional interesting puzzle to solve we'll take a good bit of abuse before throwing in the towel. We're also much too eager to show that we can do stuff.
Another part is that you have - as an inexperienced froggie - too little feeling to sense that the temperature in the pot is rising and that if you don't jump out now you may lose your ability to jump at all.
Finally, and perhaps crucially, the more you have invested in a project like this the harder it becomes to walk away.
If people can maintain a sustainable advantage through being nasty, those that are willing to be nasty will rise to the top.
I think that relying on feelings of "don't be nasty" to keep businesspeople in check in the face of nastiness that confers sustainable advantages is... not so sustainable. Some people /enjoy/ being nasty. So yeah, we have to build the world we want, and social mores are strong things.
One thought, from a market efficiency perspective, is that when I see an apparent sustainable advantage to being nasty, when there are successful people not being nasty in that way, is that maybe it's not as much of a sustainable advantage as it seems?
In this case, I think that jacquesm nailed it when he pointed out that this can happen, at most, one time for each programmer, and relying on only fresh programmers is difficult, just because without past experience, it's very difficult to judge the quality of a programmer.
> Wow, this Fred fellow admitted to you that he committed arson?
Yep. He even said that he'd gone back while the fire was still being fought to look.
> Is he identifiable from your story?
Not by you. I figure four or five people could put 2 and 2 together, none of them read this blog and they're already in the know.
It was reported to me after the statue of limitations had expired (nobody got hurt, even though that was pure chance) so as far as I know I'm in the clear.
>Yep. He even said that he'd gone back while the fire was still being fought to look.
Arsonists always do. That's why they take pictures of the crowds at fires. The person who started it is almost certainly there watching. In fact, it will probably be a man standing there with a bulge in his pants (seriously).
The book _Reporting at Wit's End_, a collection of New Yorker pieces by St. Clair McKelway, leads off with a profile of Joseph Brophy, for many years chief fire marshal of New York. Quite interesting on arsonists, both the professionals and those who do it for a thrill.
While the 'from hell' part was interesting, as someone who was (relatively) recently put in the world of CNC and rapid manufacturing by my startup... seeing that from someone's perspective was also interesting.
Not that you were 'just starting' with hardware, but still.
"(7) Dare to sell what you've got to those customers that want what you have instead of selling what the customer wants but what you haven't got yet and may not be able to deliver in time. Take the feedback you receive and use it to improve the product but unless something is really trivial it is better to sell what you have than to make some promise you can not keep. "
Oh man... this is the hardest and most important lesson ever, I think. The allure of "sell it first, then build it" is very strong, but in the long term, that way lies madness.
the problem is that it's /really/ easy to get yourself into the kind of trouble you don't recover from that way.
I understand that different markets are different, but in every business I've run, the limiting factor was my commitment or my reputation (sales) or some combination therof.
If I over promise a little, I can deliver for a limited time (as the OP did) at the risk of burnout. It sounds like burnout was a huge factor in the failure of the business this story is about. Burnout of key people can very easily kill a small company.
If I over promise a lot and fail, then we start taking hits to the reputation, and if I've accepted pre-payment that I can't pay back, well, at that point it's pretty much over.
so yeah, while it can result in dramatically positive outcomes, it's a /very/ high risk move.
I wasn't going to read it as I skimmed through, but I recognized the lathe (minus the computer and shield) and am glad I read through.
Having worked metal with these things and mills you can easily understand why cnc machines are so damn expensive. There is so much to deal with and I think if you would have chosen a mill instead this would have ended in more headaches more quickly.
One question that has more to do with the tech than the hell part I have is: did you have to deal with the excess strips of metal (which I've seen build up to dangerous length of spinning razor metal when people were being stupid) in the computer or was it under manual inspection? (There's plenty more that I thought about but that was my first)
There was a 'swarf breaker' option, especially useful for working with plastics but also when working with stainless steel. During rough-cutting this would modulate the toolbit by pausing it just long enough that the swarf would break and would fall away from the toolbit.
If you don't do that in some materials it will build up to the point where it will form a giant mess which can cause the whole thing to stall out, cause toolbreakage or even machine damage.
Swarf control is a very tricky sub problem of the whole machining thing.
I left out the milling program that was developed in parallel, when I compare the two I'd say the mill was (in spite of being one dimension more) the easier one of the two.
I can understand how you worked so many hours on this, this should have been a huge project for a bigger team with expertise in the field and knowledge of controls.
I must say I would have given up much more early, although you probably would have too knowing what you know.
Another question I had was if these machines required a large amount of manual interaction (though lubrication probably was at least provided by the machines at this time).
> I had was if these machines required a large amount of manual interaction
Because they were 'retrofits' rather than machines designed from the ground up things like tool exchange, zeroing, tool breakage and so on caused quite a bit of operator interaction.
If you look closely on the photo there is a little switch above the big red STOP button that we called the 'softstop', it was polled every few milliseconds in all situations except for thread cutting, and when engaged the machine will pull the tool away from the work (in all operations, including drilling, inside work, outside work and cut-off) so that you could stop the spindle.
Later versions had a tool changer driven by a third stepper motor, this was mechanically a very weak device and caused tons of trouble.
Lubrication on most manual lathes is either done by a hand pump that you operate ever so often, on more advanced machines it is timer driven, or coupled to the amount of movement on the carriage.
There also is the coolant to take care of, we had a relay box hooked up so that the various functions of the machine could be switched on or off under programmatic control.
All these mods together meant that installing the kit on an existing lathe was quite a bit of work, it wasn't unusual that more than one day went in to mating the x-y table to the machine (this is a very precise job), running tests, hooking up all the auxiliary stuff and so on.
Thanks for answering my questions, theres just so much work involved with these kinds of things and I'm sure it was just one thing after another.
But it is rather interesting how you handled all of it especially for the time when cncs had only been out for like less than a decade and you were modifying existing machines.
"I must say I would have given up much more early"
In my experience, it's really easy to fall into the smooth-talking salesman trap, especially if you aren't fully aware of the scope of work. When you're already committed to the project, things like "let's just make a big push to get out feature X" don't sound so unreasonable until you realize that all you have been doing is making big pushes.
This is a great story and kudos to you for building something adventurous in very adverse conditions.
As a side note, in a previous lifetime, we built some software for the Atari ST and we had quite a bit of experience with it. You are spot on about the robustness of the hardware. If the machine were to ever stop working, standard practice was to lift it off the desk about two inches, and let it drop. The theory was that it would reseat whatever chips had worked loose. It was a little bit more than a game computer, but as you say was pretty fragile.
Hehe aye, we called that a 'Spanish repair' after I'd seen the practice in Spain in a TV store. The guy there would drop the TV from 1", if that fixed it the customer was charged. Then from 4", if that fixed it the customer was charged.
After that from 1', if that worked the customer was charged and if it didn't there was no point in trying to repair the TV any more.
You can imagine the kind of trouble we had with the computers sitting in an enclosure right next to a vibrating CNC rig.
More than once I had to drive halfway across the country to re-seat a chip that had decided to go for a walk after jumping out of its socket.
Don't worry, no regrets, I learned lots there, especially things not to do and I credit a good part of later success to that particular period in my life. I also found two lifelong friends, the kind of bond that experience forged will not be broken.
Without a written contract you owned all of the code you wrote. You could have sent a cease and desist to the purchasing company and walked a way with a ton of money, very easily*
*As easy as a lawsuit ever is, I mean... it could have taken a couple years and about 100k investment, but likely they would have realized the problem and just settled.
He'd have to prove he wrote the code. Which leads to an interesting question - what constitutes an admissible proof of code authorship? Is depth of knowledge of the codebase sufficient?
except he was being paid a monthly salary and cashing checks which didn't bounce -- those are a form of documentation. Not to say I don't think he got screwed, because it sounds like he did. but i disagree that he necessarily owned all the code he wrote. because he was getting paid cash regularly for it.
I am and there is some truth to it, there were enough witnesses to the deal that I could have probably done that, and possibly would have prevailed. Don't forget that I was not the only person that got screwed out of his share, another key point would have been that my 'take home' was well below market rates, and that - until 'Fred' stripped out my name - there was a copyright notice in my name in the code and that I had about 500 subdirectories with backups of the code as it was developed (I didn't have any real version control).
But frankly I didn't care enough about it to put that much negative energy in to it, court cases are extremely hard on the system.
I simply chalked it up to experience and enjoyed my new project, which was building a very large scale message switch using QnX, it was my first experience in networked computers using message passing and a completely new world.
The contrast with the other company was remarkable in every which way and Jan (the guy that owned the new place) and I are still friends today. The funny thing is that a couple of years later I employed him for a bit!
Amazing story. I salute you for going through it. Toshiba used to sell CNC milling machines to the Soviets back in the 80's to make very quiet submarine propellers. I wonder whether your version were just a smaller scale. If Fred had played his hand right, he could have made out a lot more.
The kind of machine you are talking about is called a parametric CNC machine, not all controllers can do it, but those that can are capable of making very complex surfaces.
The work you are referring to requires 5 axis control, something that is fairly common nowadays but back then was extremely rare. The software I wrote was not capable of such complex movements because the machine itself was only a 3-Axis machine, a 5-Axis retrofit would be extremely hard to construct. Basically you'd have to rip apart the main structure of the machine and rebuild it. (see http://www.youtube.com/watch?v=lWCaQ4XvG6Y&feature=relat... from about 3:48) You could conceivably do that if you only worked on one kind of machine but retro-fits tend to be bolted on to whatever is available that still has a rotating spindle and good bearings.
The software did have some parametric tricks but not a full suite, mostly related to making different sized versions of the same part.
Most CNC machines are programmed in something called 'G-CODE', with a translator step between the CAD and the CAM part. The software that I wrote was much more tightly coupled (cad-cam all in one) so we had the full power of a regular programming language at our disposal to do complex part generation.
Pretty amazing video. It's interesting to see how the people disregard safety while the machine is running. They walk so close to the drill. I can see what you meant if there were bugs in the software and the drill arm suddenly swung wildly.
There likely is a strike detector on the gantry and the arm the toolbit is attached to, so it is not quite as unsafe as you might think.
I agree with you though that they're not practicing proper safety and I've seen numerous examples of millwrights and machinists missing digits, eyes or worse.
A toolbit spinning fast enough will throw swarf around over considerable distances and it doesn't take much to take out an eye.
In production use normally there would be an enclosure and mandatory goggles. No 'walking around in the machine'.
Even the doors normally have interlocks, if they open it counts as an e-stop (emergency stop).
I don't understand how Jacques survived the 12 hour days for weeks on end? I go pretty stir-crazy when I work a 60 hour week and it's why I haven't started a startup. I'm not sure I would have it in me. Kudos.
I'm also wondering why he stuck around so long. To me the writing was on the wall that it wasn't going to work!
It was closer to two years all together. And on plenty of days more than 12 hours. But I always was a pretty high energy person.
This is not something you should give me 'kudos' for, it's just something I was born with, though I feel as I'm getting older that I'm definitely slowing down.
The problem with quitting was that there seemed to be light at the end of the tunnel all the time, only then when you almost got there the tunnel got longer.
And in the end, it did work. The software ended up working as advertised (ok, you can keep adding features to something like that forever, just like any other cad program) and it ended up as the basis of a reasonably successful company that is still in business over two decades later.
It's just that to do this sort of thing properly the first time out of the gate you'd need at a minimum 3 people, a domain expert (which 'Fred' definitely wasn't) driving the specification, a UI guy and a low level person.
If it had been like that I could have saved literally months of rework based on the assumptions that were fed in to the process early on as 'immutable', only then to be changed at a later date anyway.
Maybe a morale can be: "Start with small projects before going for big ones"?
I mean, there are a lot of important lessons you learn when you have a "project from hell", so my reasoning is that the project better be small, so at least the price will be low.
It started out as a small project. Little did I know.
I had done a large number of smaller projects and several mid-sized projects, as well as one very large one by the time I started working on this though, so it's not as though I was green behind the ears or something.
Maybe the morale should be 'know when to walk'. And I should have walked long before I did. The violence is what made the coin drop for me, it was a realization clear as day, 'I'm being abused here'.
Suddenly the veil came off. After that quitting was relatively easy.
They'd always said that. Then at midway, suddenly "we need the money, and there is this client willing to pay if we make it such and such. It shouldn't be that hard eh? I know you can do it". On and on.
Till this day, if anyone says "I know you can do it", my alert level would increase.
To me, what made it easy for me to quit, was the fact that my boss didn't not want to spend any money on sales to sell the finished product, when all this while he had been spending money on the development of the product. For all the talk of "I am being most loyal to the company" and "I sacrificed a lot for the company", he hesitated on doing the final push.
As naive as I was, I suddenly discovered it would be stupid for me to stay. That made it easy.
There's no better way to learn the true character of a man than to ask him to write a very large check based on an oral contract.