New problems of deduplication
Programmers spend a lot of time fighting against duplication. Duplicated code is bad, other things equal, because it is inefficient, harder to maintain, harder to improve, much buggier, and much more confusing. Duplicated data is bad, other things equal, for many of the same reasons, but it's arguably even more confusing, because in practice it often takes the form of, e.g., a "master database table" with three different SKU columns that encode subtly different information.
Not all duplication is bad: if your company is big enough, maybe it's OK if distant teams write the same helper functions. Maybe you really do, for whatever reason, need performance gains you can get by storing your data in several places (whether that's copying it across systems, materializing it in advance, pre-computing variations of it, or whatever). We do not, on average, spend enough time fighting against duplication, but the optimal amount of this kind of duplication is not zero.
Whether or not you agree with me about all of that, it's worth thinking about how AI is creating entirely new genres of duplication problem:
- The faster and better AI gets at documentating software systems, the more such documentation becomes a kind of materialized view on the codebase. More and more, I see AI confusing itself by relying too heavily on existing documentation where it could more accurately, and very cheaply, figure out the relevant facts directly.1
- The faster and better AI gets at processing data, the more preprocessing data becomes a kind of duplication. Suppose you're writing software that prepares invoices for human review and generates a list of fields that require particular attention. If you could be generating that list on demand later (and you probably could), there's at least a question to be asked about whether to make those judgments now or later, precisely because AI so often closes the gap between "is theoretically determined right now" and "is practically available right now."
- Historically, tracking bugs is useful because (i) it can be hard to find bugs, (ii) it's useful to have organized views of all the bugs, and (iii) people are likely to have valuable, if partial, insight and knowledge from which future workers will benefit. An entry in a bug tracker, however, ultimately duplicates information that is in principle available elsewhere (if the entry is accurate!). Now that it is orders of magnitude easier to find bugs and examine the relevant contexts, it's often optimal to spend a bit less effort finding and investigating bugs before you're ready to fix them.2
Further notes:
- We have long known that it's tempting to make things you won't actually need. The cost-benefit calculation here, then, needs to account not only for the fact that you can do later what you're tempted to do now, but also for the fact that you might never end up doing it.
- Don't forget that the model you use later is likely to be better than the one you'd use now, even if "later" is only days away.
Here as elsewhere, "I see this problem" does not mean that the problem would exist under ideal usage. It's quite possible that I'm not telling LLMs how to use and update documentation properly; my point here is not that eliminating documentation is the new best approach, but that the decision about how much documentation to have looks more and more like the decision about whether to pre-compute a certain view on some data.↩
...even as we should have higher and higher standards for our software. One reason not to track bugs when you're not ready to fix them is that you should more often be ready to fix them!↩