This article describes how to write unmaintainable code and have an excellent paid job for the rest of your life. The key skill to unmaintainable code is the obfuscation of the code - besides poor design, no test cases and overly complex algorithms. If you really like to write well maintainable code, feel use this as input for things you shouldn't do in your next project.
At the first glance a method like
is difficult to understand, but for a developer with perfect knowledge of Klingon, it will be clear that you mean something like
If you are not fluent in Klingon , but familiar with other languages like Esperanto, French and/or elder dialects of Romulan you may also use these.
Source: Wikipedia - TOS-day of the dove klingons.png; fair use rationale;
For all others - with less foreign language skills - there are still some other helpful techniques to obfuscate your code.
As you can see, the method:
Yes, this is a good starting point, but there is still a lot to improve. Please, ensure that nobody gets a glossary of your abbreviations and use same acronyms with different meaning in each class.
Synonyms are also helpful; just use a thesaurus to bring more variance in your naming. The target should be - never use the same word with the same meaning in more than one class.
Starting from the quite good
you could now replace some characters with numbers like in
Use numbers and/or characters which are similar shape like in the following sample 
You will save a lot of time if you suffer from dyslexia and/or poor typing skills (people like me). In this case you will write things like
Please, never refactor these typos.
The use of CamelCase writing is a common practice in Java, but never use the correct beginning of words for an upper character. You have to admit that myCamElcase() reads not so easy.
Keep in mind, that for Java compiler myCamElcase() and myCamELcase() are complete different signatures. Please, ensure that you have both in your class and the implementation should do completely different things.
Some companies request extensive code comments. Fine, comments and especially JavaDoc is an excellent source for obfuscation and reduced maintainability.
The first rule is to ensure that all comments have no meaning, e.g. describe just what happens and not the why, use Eclipse Plugins to generate completely meaningless content. When you change the code never update the comments. Comments are like good red wine - they need "extended ageing in the bottle".
Another way is to spread fears amongst possible maintenance developers. Small inline comments like:
// Looks simple, but never ever change this or everything blows up later in production!
Yes, I know: "Unit test are really dangerous!" They could improve the maintainable if not carefully developed.
Let's assume in your company they have a policy that each code needs high code coverage and they measure it. No problem, just write:
In Java you need a lot of packages to create the illusion of a good architecture. At least 7 layers (from GUI to database) and with dozens of packages in each are helpful to convince the management about the worth of the design.
But ensure that each class is dependent from random packages in all directions. The best are cyclic dependencies over more packages. Don't forget "Cyclic dependencies are the GOTO's of the new millennium".
From the scientific point of view - it seems not to be clear if code clones matter. But in practice, they can help to write unmaintainable code.
Two things are important (i) with clones you increase the size of software and (ii) inconsistent changes of behavior and/or bug fixing leads to confusion. The most crucial point is the code size, because the time you need to do a change is direct proportional to the lines of code you have.
Because of this, clones really matter.
Learn from others, every day! Spend 20 minutes per day in forums, discussion pages and/or read about common bugs. Study the warnings of FindBugs (or other static code analysis tools).
This inspiration will help you to write the clever bugs. Because, the obvious are not good for your reputation.
Be evil but don't be discoverable as a developer who writes unmaintainable code!
Last but not least, never share your know-how. Write or better generate thousands of pages of documentation but never explain the architecture in two pages. If you have to train a potential
successor just answer questions and explain nothing.
If you really shared some know-how, then you could refactor the application the next morning.
By the way long method names are also helpful to express emotions (the method name is from real code - thank you Robert for writing this today).