>>>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.