By engineering, of course, I mean engineering from scratch. On that last point though (splitting this off), I think there are two difficulties in engineering i

By engineering, of course, I mean engineering from scratch. On that last point though (splitting this off), I think there are two difficulties in engineering it. First these are fundamentally more complex systems. The more complex a system is the harder it is to spot all points of failure. Additionally more complexity fundamentally means that that failure cases are more complex. Instead I think that the way most of these systems develop is through progressive, evolutionary invention. Ok, I have tally sticks. I can write about them in a journal and use arithmetic to track the totals. I will write the stock on the left, referring to the thing owed (Latin "Debit") and the smaller foil on the right, referring to what is loaned to me (Latin "Credit"). Ok, now I need to categorize these. So I will start putting a code by each one. Now I have a chart of accounts! Now I need to total each of my accounts so I transcribe into another book and now I have a ledger. Do the books balance? Let me add them up and find out. Let's call this a trial balance. And so forth. The utility arises largely from a large number of different people working with real issues to find other uses for the system. We see this with the evolution of SQL over a period of time as well. SQL today may not have changed in its outlines since it was developed but the standards have evolved a lot to meet needs. So the challenge is for something like a disconnected POS. Again a system like the real world invoice and cash voucher system might work best.