In this series we explore a business architecture that’s more complex than obviously necessary, but where each complication creates value over time. Watch designers speak in terms of “complications” instead of “features”. I love this framing because it simultaneously reminds everyone of both costs & benefits.
Note: In pricing of insurance policies and changes to them, we routinely effective date both the rate data that drives this process *and the code itself.* Especially in government regulated environments (mostly personal insurance). Changes to insurance rates and algorithms must be filed with the government regulating agencies and approved. Policy terms that start after the approved effective date use the new rates and algorithms. Changes to policy terms that start before then use the old data and code.
(Bug fixes can and sometimes must be applied retroactively.)
It's helpful to realize that in modern "stored program" (or Von Neumann) architectures, there is no fundamental difference between code and data. With scripting languages, one can store the script code in effective dated records. In more "conventional" languages, one can effective date the function/method lookup tables.
1. There will be more posts. I want to uncover the positive purpose of batch processing. Also the bi-temporal range query algorithm has always been a mystery to me.
2. I’m not sure how to look at older posts on SubStack. I’ll add links or an index or something.
> If you process yesterday’s data with today’s logic, you could easily come up with different answers than you did yesterday. In practice this doesn’t come up that often, but it’s interesting to imagine automatic solutions. A bi-temporal code repository?
In a git repository the entire history of the code is present in the clone. One can imagine storing the commit hash of the code with the transaction. In practice, I’m not aware of a system existing that would allow one to execute code from any arbitrary commit. But thats an intriguing possibility indeed for full reproducibility and audibility.
Okay, I'm very curious about the relationship between the Tao Te Ching and double-entry bookkeeping. But since this post is the top result on DuckDuckGo for those two terms, and Google turns up nothing of interest... what should I search for?
I have no idea. I just know that when I start talking about accounts & transactions, wild-eyed folks start tugging on my sleeve & asking if I want to learn about the Tao Te Ching.
This could be implemented as a transaction log where the balance at a specific point in time is calculated by looking at the previous values. Or if we'd like O(1) time for `getBalance()`, when writing to the log calculate the change based on the previous record and store the updated value. The write and read interfaces become dead simple, and the complexity of writing the log record is isolated. I think complexity is unavoidable, it's just a matter of keeping it "together" and not spreading it across the code base.
You can look at that Account object as a transaction log. Bi-temporality means that caching is less valuable, or at least trickier to implement. Think about all the test cases that would have to pass should you happen to post a retroactive transaction.
The History class is what "dooms" theses transactions in the minds of upper management. As History is looked at in the past, it records the reasoning of those transactions. The CEO is going to have to answer why he or she paid X amount for that strip of land to build the high dollar condos on. Maybe he should have known - at least inspected it more - that those condos would slide into the Pacific. If the auditors insist on looking at History, questions will be raised...
I can understand that fear but I think the risk is smaller than you make it. The kind of transactions I'm talking about are financial--this money flowed from here to there at this moment. We'll leave the psychological analysis to someone else.
Note: In pricing of insurance policies and changes to them, we routinely effective date both the rate data that drives this process *and the code itself.* Especially in government regulated environments (mostly personal insurance). Changes to insurance rates and algorithms must be filed with the government regulating agencies and approved. Policy terms that start after the approved effective date use the new rates and algorithms. Changes to policy terms that start before then use the old data and code.
(Bug fixes can and sometimes must be applied retroactively.)
It's helpful to realize that in modern "stored program" (or Von Neumann) architectures, there is no fundamental difference between code and data. With scripting languages, one can store the script code in effective dated records. In more "conventional" languages, one can effective date the function/method lookup tables.
If I understand well, this is last post of series. I can't find previous/related posts. Or I need to upgrade? Sorry I'm new on this Substack thing.
1. There will be more posts. I want to uncover the positive purpose of batch processing. Also the bi-temporal range query algorithm has always been a mystery to me.
2. I’m not sure how to look at older posts on SubStack. I’ll add links or an index or something.
1) As far as I know, these are the posts in the series, so far:
https://tidyfirst.substack.com/p/what-if-you-are-going-to-need-it
https://tidyfirst.substack.com/p/never-forget
https://tidyfirst.substack.com/p/when-did-it-happen-when-did-we-find
https://tidyfirst.substack.com/p/accounts-and-transactions
2) To see all older posts: https://tidyfirst.substack.com/archive?sort=new
3) From Kent Beck's reply before me, I don't think there's a place yet where you can see the list of posts in _this_ series.
Correct. I should have created a new section.
> If you process yesterday’s data with today’s logic, you could easily come up with different answers than you did yesterday. In practice this doesn’t come up that often, but it’s interesting to imagine automatic solutions. A bi-temporal code repository?
In a git repository the entire history of the code is present in the clone. One can imagine storing the commit hash of the code with the transaction. In practice, I’m not aware of a system existing that would allow one to execute code from any arbitrary commit. But thats an intriguing possibility indeed for full reproducibility and audibility.
You can certainly do this with Clojure since git dependencies based on commit SHAs are a first-class thing.
Be a fun experiment.
Okay, I'm very curious about the relationship between the Tao Te Ching and double-entry bookkeeping. But since this post is the top result on DuckDuckGo for those two terms, and Google turns up nothing of interest... what should I search for?
I have no idea. I just know that when I start talking about accounts & transactions, wild-eyed folks start tugging on my sleeve & asking if I want to learn about the Tao Te Ching.
This could be implemented as a transaction log where the balance at a specific point in time is calculated by looking at the previous values. Or if we'd like O(1) time for `getBalance()`, when writing to the log calculate the change based on the previous record and store the updated value. The write and read interfaces become dead simple, and the complexity of writing the log record is isolated. I think complexity is unavoidable, it's just a matter of keeping it "together" and not spreading it across the code base.
You can look at that Account object as a transaction log. Bi-temporality means that caching is less valuable, or at least trickier to implement. Think about all the test cases that would have to pass should you happen to post a retroactive transaction.
The History class is what "dooms" theses transactions in the minds of upper management. As History is looked at in the past, it records the reasoning of those transactions. The CEO is going to have to answer why he or she paid X amount for that strip of land to build the high dollar condos on. Maybe he should have known - at least inspected it more - that those condos would slide into the Pacific. If the auditors insist on looking at History, questions will be raised...
I can understand that fear but I think the risk is smaller than you make it. The kind of transactions I'm talking about are financial--this money flowed from here to there at this moment. We'll leave the psychological analysis to someone else.