>>>>The thing is, there are so many examples where the invoice header and the line items and the inventory have to be depleted all at the same time, and when it doesn't work right, someone has to go digging. This is far from the exception.
>>
>>Yes, "Good enough" often seems to prevail in this world. To quote from the serenity prayer: "God, grant me the serenity to accept the things I cannot change, courage to change the things I can, and wisdom to know the difference." ;-)
>
>While I sometimes ridicule bad or sloppy thought and code, "Good enough" is often the fitting strategy, as Pareto principle will deplete funds otherwise and might scuttle the whole project. When faced with exponential growth or danger of extinction via punitive compensation or indemnification, this argument becomes thin, but for coding covering "good enough" for 1st release IMO is quite acceptable if done on features, not code quality. If the code itself is written in a way to allow fixing problems arising without total overhaul, that is often ok.

Good enough is transactions. PERIOD. Anything less is unacceptable. The point is do it with transactions from the start - and if you don't know about transactions - like these guys, don't start.

I took a job for a telephone company, 25 years ago maybe. That's where I met Toronto's Jim Nelson. He and the entire team did not know what I knew THEN to make things crazy fast. At least that company was smart enough to have me do training of the team. Too bad it was too late because they company folded.