You're fresh, you're agile, you're fast, and you can code like the wind. But are you writing maintainable code in a way that makes it as easy as possible for others to change it down the road?
Yes, you say? Why?
Don't you know that it will all be obsolete in a year? Don't you worry that some future developer will spoil the pristine beauty of your carefully crafted solution? Don't you admire the occasional fragile, irreplaceable legacy ball of mud? Wouldn't you rather write zombie code that no one but you can understand, code that is regarded with fear and awe, code that will live forever in the enterprise because that no one dares to touch?
It's not easy, but you can do it. With a little effort, you can cultivate the habits and discipline that will enable you not only to write legacy code immediately but also to surpass that level of "meh" and write the ultimate survivor—zombie code that continues to walk the earth long after you're gone. Here's how:
Test nothing
Tests are a waste of time—they give the illusion of confidence and might reveal how things work to someone else. If you have to write tests, write them last, and just assert true. Definitely don't write tests first or use them to guide the design—code developed that way is far too easy to understand and change.
Never refactor
First of all, if it ain't broke don't fix it. Second of all, no one has time to evolve into elegance and simplicity. Test-driven development, if required, can be subverted into red-green check in or just check in, if you can get away with it. After all, "technical debt" is just something they made up to sell software-metrics tools.
Write inscrutable code
Obscure the intentions of your code—make it all about the implementation. Above all, name classes and methods to restate what they do, not their responsibilities. Names like GetPriorPurchasesOfSameProduct are much too long and informative. ScanForLike would be much better. Or better yet, just Scan. Simple, generic names rock!
Use generic names like Buffer, Temp, and X as often as possible.
Use abbreviations and acronyms to name interfaces.
Use generic structures not only to save time and effort but also to obfuscate type information.
Keep strongly typed structures in untyped collections.
Make arrays out of everything.
Copy and paste a semi-related structure into new code, then change it to fit the different data and situation, but don't rename any of the fields or update any of the comments.
Occasionally (but not too often) give variables names that imply the wrong types, such as naming a floating-point numeric value "MessageText."
Pass values using Object or String, and never encapsulate value types.
If you must name constants, name them the same as their value, or use Greek letter names.
Comments are an opportunity to add noise and misdirection—embrace them with wild abandon. The best comments simply restate what the code is doing and then stay the same after the code is changed.
Keep in mind that the person reading your code should only see a reflection of what it's doing at the implementation level: opening connections, fetching results, processing records, returning results, and so on. Under no circumstances should you use the underlying business domain terminology.
Write unreadable code
Reading other people's code is a waste of time, and it might corrupt your creative style. Insist on your own standards and conventions but never document them.
Whitespace is wasteful. Code compiles faster without all those extra characters, and the separation might make the code more readable. Put everything on one line, as long as you like.
Modularity is for the small-minded. You can keep the entire solution in your head, so why spread it across multiple classes and methods?
Complexity is beautiful and unnecessary complexity even more so. It's much better to use the latest language features that allow you to write two obscure lines of code than to write five lines with obvious effects. If anyone asks, claim it's more efficient and/or ridicule them for not knowing the esoteric features of the language you used.
Write inflexible code
Make as many architectural decisions up front as you can, and stick by them no matter what.
Don't share information
Never explain why your zombie code does something. In fact, avoid teammates, or at least avoid talking about the projects on which you're working. Your teammates might have suggestions, and suggestions are annoying, or you may accidentally reveal enough about what you're doing that your teammates understand it. Neither of these are desirable.
Don't do pair programming, ever, and avoid code reviews. That would just waste your time with questions you've already answered in the code. If cornered, just describe what the code does.
If you must interact with someone else, only do so via email, then wait at least two days between responses, and change your email address often.
Bypass or subvert any so-called "policies," "standards," or "processes" that might interfere with your nefarious plans. All those reasons they gave you, such as "quality improvements" and "saving time," are lies anyway.
On the other hand, if you happen to also be in charge of other developers, you can issue policies, directives, and process changes as often as you like, but never, ever explain why.
New developers on the team, especially fresh graduates, should be dropped into the deep end with no orientation, education, or support. Make sure their questions are ignored or ridiculed, and continually press them to deliver. If you really want to make them pay their dues, block access to Google and Stack Overflow.
No DevOps. Ever.
DevOps practices and practitioners should be avoided. Set up everything manually, just the way you like it, and change it whenever you want. Be suspicious of source control systems—check in your code only when everything is done. Be sure to use a pseudonym, and reveal nothing in the commit message.
You may not be able to avoid participating in continuous integration and/or delivery pipelines, but do so as infrequently as possible.
If you must document, document badly
If you must write external documentation, write it so that only you will understand it. Never define acronyms, and leave out a few critical steps—you had to work hard to figure it out, and so should everybody else. Then file the document somewhere inappropriate and give it misleading search tags.
Don't look things up
It's a sign of weakness. Figure out everything on your own from first principles. Other people's libraries are suspicious. Write your own frameworks.
Coding for the zombie apocalypse
If you consistently apply all these disciplines, your programs will become the walking dead, zombies that are forever decaying but never quite dying. Your efforts will haunt the codebase long after you're gone.
It's been said that one should write code as if the next person to touch it will be a violent psychopath who knows where you live. But that's unlikely to happen, because they'll be too busy fighting your zombie horde.
Just don't put your name on it.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
