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!
Free Design
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.
Use Logging
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.
Utilize Frameworks
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”.
Personal Style
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.
Summary
There you go. This advice will guarantee job security beyond retirement. If you look around there is plenty of proof. Good luck!
Another winning concept is to do heroic efforts to patch the legacy system when it goes down. Work like crazy a full weekend! Everyone will believe you are a hero, as long as nobody figures out your code is the reason it went down in the first place. This trick is proven (!) to work great, for years, at some companies.
Nice list! Without thinking very deeply, I’d like to augment it with two contributions:
Write your own utility classes
The fact that there are many well-tested and maintained libraries and frameworks for solving common everyday problems should not stop you from writing your own versions of them. After all, they will integrate with your system more smoothly. Every system needs its own version of StringUtils and FileUtils!
Enforce execution flow using mock frameworks
This is an advanced one! What if you could double check your flows and logic just to make sure they are right? Mock frameworks to the rescue. Turn every stub or dummy into a proper mock, make sure it uses strict verifications and sharp expectations. Not only will this produce readable unit tests, it will also enforce the program flow. Completely.
And do not forget to write your own mock framework! 🙂
Write lots of comments in your code. A comment to describe what each method and class does, in great deal of detail, but nothing about the overall purpose of the method/class. Each comment is ALMOST correct, just correct enough to be believable, but with subtle discrepancies to trip up any intruder stupid enough to read the comments. At random locations add a commented-out line of code that looks important.
Oh, and move anything complex and difficult into XML files and call them “configuration files” rather than code :o)