In this day and age with unstable economics, constant change in how to work with software, new languages and databases popping up from nowhere, it is important to cement yourself into your position at work.
Follow this guide and be sure of never being fired, no matter what.
The more critical to business your system is, the less likely you are to get fired if you work legacy style. Nobody else can do your job – you are safe.
Furthermore, you get to decide a lot of things. If you say it can’t be done, then it can’t be done! Who else knows what can be done with your legacy system?
So now you are probably eager to know how to come in to such a position, the legacy system specialist. Listen to this advice.
Write Unit Tests
These days, we are expected to write automatic tests. Back in the old days nobody had to deal with that. So write tests that do not verify anything and make sure the test cases have names that convey nothing, such as “test1” or “testFunctionFoo”.
Divide the System
It is important that you and your colleagues cooperate to create legacy code. By that I mean, divide the system in responsibility areas (not to be confused with the actual, logical structure of the domain). Each area has one designated person who is in charge of all code within that area. Not only in charge of the code, but also the only one able to read and understand the code.
You don’t touch my stuff and I don’t touch yours – cooperation!
Everybody wants to be free and you are no exception. Nothing should stop you from doing design the way you think it should be done. Since nobody else is touching your code, why would they have a say about the design? This is guaranteed to produce a legacy system with everyone applying their personal design to their parts of the system.
Be sure to use the logging system of your choice. Log at random occasions with obscure remarks like “wally 34 before foo”, assuming Wally is not your name. It is the name of the guy that used your desk before you.
File Formats Done Right
Each time you interact with another system using file exchange, create a new file format. Never mind that the same information has been exchanged before and that reuse threatens your legacy plans, just come up with a reason and do it.
Needless to say, the documentation of the file format should look superficially good but should not mention crucial details.
The standard frameworks and protocols may be enough for the job but that does not build a legacy system. Find a framework that is “better” and start using part of it. No need to overdo it, just ensure that your code gets tangled up with it.
Adapters are poison to legacy, remember that.
Document the Architecture
There may be whining about this from people not working with software. They know nothing!
However, like with the tests, it is easy to avoid that discussion. Use a tool like Word and document the architecture. Yeah, really, just be sure to write at least 100 pages. Perhaps you can find some examples on the internet.
In the documentation write at principal level, such as “avoid high coupling”. Use examples that show earlier versions of the code. Convey nothing.
When somebody asks for the document, mumble something about it being “slightly outdated”.
It is also important to work on your personal appearance. Dress in worn shirts and baggy jeans. Grow a belly and practice a dark eyed glaze to use when people approaches you. Avoid hair cuts. Males can benefit from growing a mustache while females can do wonders with an ill-fitted bra.
There you go. This advice will guarantee job security beyond retirement. If you look around there is plenty of proof. Good luck!