The order is an order is an order.

2016-09-02 15:19  anorder     [permalink]

Then there was the day I decided to redesign. I had a hard time explaining. Not only why I thought a redesign was needed, but what is was exactly that I would do differently in this new design.

There would be a small distance between the data of the orders and the rest. The design would center around the idea that an order is exactly just and only that, an order. A request from a customer to have us do something. The distince between order-data and the rest wouldn't be large, it would more be something like a conceptual demarkation. In practice the order-data would be insert-only. A new order is registered, and after that read-only. This is easily explained to you, but caused shockwaves over the entrenched toilers of the company.

So to get closer to the common root of a great number of small problems, I started a design with just this, drawing up a model of reality where this is the first fact to note: the fact that an order comes in. When, by whom and for what. Not that the order is accepted. Not if it is payed for or not. Not if it's covered by customer credit or not. Not that it's cancelled or completed. Register different facts in different tables. Back to the books. Back to the 16th century penwright toiling in candlelit accounting books.

I sometimes joked that serious companies would require a stamp and signature to transfer this or that between departments. And silently I hope some still do. And even if none are left, it's up to us to see the romance in it. It's man-made structure to guide a man-made process, but it's structure and process none the less. Things break down swiftly when those go.

→