Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Even with detailed specifications for exchanging data between computer programs, chances are that data generated by older versions of programs do not conform 100% to the specification, or that they use old obscure features which few people know how to implement them. As a result, companies have to keep a library of "odd specimens" for testing their software.

In good software design, these quirks can be confined into a small layer of libraries called "Abstraction Layer". However, most abstraction layers cut off too many functionalities (in order to prevent the higher level software from touching the unstable parts of the lower level software).

Sometimes it is not possible to completely hide away the unstable parts. What are the strategies for coping with such necessary workarounds?

((Please pardon my poor language skills.)

share|improve this question

Good documentation.

Code comments go a long way towards telling the next developer why the hack was placed there, and why it needs to stay.

Hopefully the reason is sound. At some point, if enough technical debt is incurred, a refactoring should be considered.

share|improve this answer

If data files, consider creating a translator module or separate program that will do the translation for you into the new format. Embed the knowledge of old -> new formats in that module and keep your current code clean.

share|improve this answer
+1 for translating to the new data format in the first place. If it's possible at all, it's always the best option. Directly supporting legacy hacks is a horrible task. – Joonas Pulakka Nov 15 '10 at 7:03

Unit/integration tests can be used to identify those 'features' (if they can't be removed). Likewise, the same kinds of tests can test the code that consumes the libraries in question to ensure that they satisfy the contract of mis-behaviour.

share|improve this answer

Sometimes it is not possible to completely hide away the unstable parts. What are the strategies for coping with such necessary workarounds?

It's important to realize that the software will keep evolving in the future. One layer of obscure workarounds is tolerable, but real problems will emerge if you start building workarounds on top of workarounds. Therefore refactoring is absolutely required before the layer of workarounds is going to exceed one. Of course it would be better to do it cleanly in the first place, but it simply doesn't go like that in the real world.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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