Amnesic Environment [closed]

Question

My team is looking for a technical term which may or may not exist.

We are trying to describe an environment, such as a database, which has been built up over time with little or documentation about the change process that has gone into it. Generally these are legacy systems who's original developers have long since moved on and they are in such a tangled and unmanageable state that the only way to recreate the environment, say for testing purposes, is to copy it and do your best guess at re-configuring it for its new purpose.

So far the best term we have come up with is Amnesic, such as "setting up the new test environment is going to be a challenge because it is an amnesic db." However, we are still not quite happy with the term and were wondering if a better and/or more accepted term for this situation exists.

Answer 1

There are terms which are close to describing what you want, but maybe not exactly right.

• The term Legacy Code (mentioned in the comments to the question) is often used as a derogatory term because it's been hacked on and has become brittle and hard to understand and work with.

• The term Lava Flow (also mentioned in the comments to the question) is used to denote clumps of code that have been there for eons and nobody dares touch them because they work (or nobody has ever touched them without breaking the world).

But "legacy code" merely implies old, and "lava flow" implies little blobs within a system, not the whole thing.

So... With tongue firmly planted in cheek, howsabouts I invent a term: "Basalt Deposit?" A basalt deposit consists of (often multiple) lava flows that have solidified at or near the base of a long-active volcano. Like the re-solidified wax that ran down the side of a candle and pooled at its base. It's a hard rock, and after the volcano has gone extinct and erosion has run its course, is usually the dominant feature in the landscape.

Usage: "Do you really want to go digging around in there? It's a basalt deposit, and you're gonna break your shovel."

Of course, instead of a pithy term, you could just post warning signs at the borders explaining what the dangers of the code are :)

Answer 2

Setting up the new test environment is going to be a challenge because there is a significant amount of technical debt. Corners have been cut and development was geared towards time constraints over quality control. By leaving off the necessary work required for a project (documentation, refactoring, regression testing, code reviews), they put off that investment into future. They reaped a benefit at the moment in exchange for some technical debt. But this debt grows with interest. As time progresses, the mind-space of the developers was dedicated elsewhere and the reasons for this change here or that addition there was lost. And with that loss, the task of documenting and cleaning the project up became that much harder. There comes a point where the debt is unmanageable and you should simply start anew. This is offset by how tightly coupled the project is to the rest of your business and how much of this cruft is legitimate business knowledge. Even for extremely crufty projects, reverse engineering the details may be a better solution than starting from scratch.

But it's going to be hard because you have to start paying off a massive debt. Most of the payment (that is, the time you spend reverse engineering this thing) is going to interest rather than the principle (we'll be documenting and refactoring more than we're adding new code or tests). At least at the start.