Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

closed as not constructive by Robert Harvey, Steve Evers, gnat, ChrisF Dec 14 '12 at 23:40

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

4  
Crufty? Undocumented? POS? –  Robert Harvey Dec 14 '12 at 19:22
1  
Legacy code / Legacy DB? –  Oded Dec 14 '12 at 19:27
2  
Not exactly what you are describing but it sounds like the database has a lot of Technical Debt. –  Mike Dec 14 '12 at 19:31
1  
We refer to those types of environments as the wild west in reference to cowboy programmer-ism. –  Akira71 Dec 14 '12 at 19:37
1  
Lava Flow –  MichaelT Dec 14 '12 at 19:38
show 3 more comments

2 Answers 2

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 :)

share|improve this answer
    
Baked in grease is my favoured term for this, it'll come out, but you're going to need some effort and good cleaning products (techniques, ie. Unit tests / Integration tests) to deal with it. –  Slomojo Nov 27 '13 at 2:33
add comment

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.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.