There are no inconsistencies to fix; the credit/debit model is fully consistent, just implementation inconveniences. And I don't think anyone would have trouble with this if it was titled “implementing double entry accounting in software” rather than “double entry accounting for developers”; that is, it's a fairly decent explanation of how, if you have preexisting understanding of the domain, to reduce it to software internals, but very bad as an explanation of the domain (whether to an audience of developers or otherwise.)
> Established accounting terms are from 500 years ago when people had trouble with subtraction.
People still have trouble with substraction compared to addition, especially with large numbers.
There are no inconsistencies to fix; the credit/debit model is fully consistent, just implementation inconveniences. And I don't think anyone would have trouble with this if it was titled “implementing double entry accounting in software” rather than “double entry accounting for developers”; that is, it's a fairly decent explanation of how, if you have preexisting understanding of the domain, to reduce it to software internals, but very bad as an explanation of the domain (whether to an audience of developers or otherwise.)
> Established accounting terms are from 500 years ago when people had trouble with subtraction.
People still have trouble with substraction compared to addition, especially with large numbers.