And, yes, documenting each new system and each new use case is tedious work, but here’s an example of what can happen if you don’t start doing this work right at the beginning.
Meta (aka Facebook) is the defendant in ongoing litigation in California. As part of the discovery process, the court asked Meta to provide
1. a high-level description of the most common functions and purposes of the system, and
2. the business units, divisions, or groups that use the system
for each of its 149 (!) internal data systems.
To date, Meta has been unable to do so. By its own account, it does not keep records on what its systems do, nor the use cases they respond to, nor the business divisions that use them. When questioned by the court, a Meta witness replied:
“Effectively the code is its own design document… …it is rare for there to exist artifacts and diagrams on how those systems are then used and what data actually flows through them”.
In other words, there is no separate document explaining how the systems work, the data they hold, and so on.
That’s not a great position for a company to be in.
And that’s not a great position for a director of the company to be in either: it means you are admitting that you have lost control of the company.
At some point, the law (by which I mean a) regulators, b) activists, and c) claimants backed by one of the large litigation funds looking to make a buck) is going to get involved and apply what economists call a market correction.
Ok, most of us are not the size of Meta, but the principle remains. It’s not exciting work, it’s certainly not glamorous work, but it’s a lot cheaper to implement the right process at the beginning, than it is to try and retrofit it years later. Retrofitting is very expensive.
At this point, I would like to introduce Mark’s Laws of System Complexity…
First Law: the growth of complexity in systems is exponential, not linear.
Second Law: if you are going to grab a tiger by the tail, best do it whilst it is still a cub.