Abstraction and the left hand that doesn't know what the right hand is doing
A bug popped up the other day that is an example of a frustrating class of computer problem. Here's how it happened:

I have some code that presents a nice UI for managing a certain kind of data. Originally, it was designed to handle data from a particular source. Later on, another source for the "same" kind of data was added to the program. Fortunately, my code is "properly" abstracted, so the UI doesn't care where the data comes from, and I can use it either way.

Unfortunately, and herein lies the problem, a requirement arose later that if the data comes from source A, the UI should behave very slightly differently than it should if it comes from source B. Unfortunately, my UI can't tell the difference between data that comes from one source or another. In essence, the program has forgotten something that it needs to know.

There are several solutions to this particular instance of the problem. One obvious one is to change the API to the UI, to add a little parameter that controls activating the different presentation. Another (not so good) solution would be to try to add intelligence to the UI piece that analyzed the data and looked for some hint that it should display it using method A or method B. (Sometimes you have to do the latter when the API is not under your control.)

The frustrating part of this situation is that I think it's inevitable. To make computer systems tractable, you have to use abstraction. Abstraction, to me, means to remove inessential details leaving behind the essence. The problem is that it can be awfully difficult to figure out what the essential details are and what is noise. If you leave too much out, you have this forgetfulness problem where information is lost as it goes through the system. If you put too much in, though, your abstraction is not abstract, and it becomes hard to use in more than one context.

To some extent good design work can mitigate this problem. It does help to think things through up front, and talk them over with others. But it can't solve it completely. We are not terribly good prognosticators, and requirements change over time. If you control all the relevant code, re-factor aggressively. That will beat the code into a useful shape fairly rapidly. If you don't control the code, be prepared for ugliness.