Strategic forgetting

1 files changed, 18 insertions, 0 deletions

diff --git a/content/code/strategic-forgetting.md b/content/code/strategic-forgetting.md
new file mode 100644
index 0000000..98d9cd0
--- /dev/null
+++ b/content/code/strategic-forgetting.md
@@ -0,0 +1,18 @@
+---
+title: Strategic Forgetting
+date: 2024-04-09T17:46:20-04:00
+---
+I am, increasingly, of the perspective that when a business pays programmers to automate some part of its business process, they do so because it will be cheaper to do that than to pay someone to remember that process. Sometimes, this process happens by intent, but much more often in my experience, it happens as a confluence of other incentives.
+<!--more-->
+
+"Business process" is a large category, and it includes everything from the scale of negotiating a contract with a prospective client all the way down to ordering office supplies; they all, in some way, entail expending the business' resources in order to accomplish some goal.
+
+When a business is not automated, then a business process can only happen when a person carries it out. The promise of computerization is that a business process that has been automated will be carried out reliably and repeatably by the computer programs involved, creating the perception that the staff that used to carry that process out are no longer required.
+
+This doesn't always mean they get let go. It can, but it can also mean that they're reassigned, and expected to be doing something other than the process they were originally detailed to. In either case, understanding of that process decays.
+
+But this also happens to the programmers and operators who sustain that automation. An automated problem is a _solved_ problem, and the organization likely expects those staff, too, to find other ways to be productive, sooner or later. Even if a group manages to retain both the responsibility and accountability for a process, and an understanding of that process, they may be reorganized - or they may move on, for their own reasons. There is rarely time, budget, or incentive to train their successors; sometimes, there are no successors.
+
+"Zombie" services, which carry out business processes for which there is no remaining stakeholder, are the terminal phase of a business program's main sequence. Devops practices accelerate this, but even classical ops processes mostly serve to measure the decay of knowledge and keep track of the technical services; they cannot guarantee investment in understanding what they do or why they do it.
+
+Plan accordingly. Your services, should you be successful, will carry out their work for you, long past the point where anyone will remember why.