Unmaintainable PHP
Tweet
With the recent unemployment rates, everybody realizes that job security is important. The best way to keep a job is to be irreplaceable. If no one can maintain the code you write, you have a job for life. Writing unmaintainable code is a special skill that seems to come quite naturally to certain developers. For the rest of you, here are some tips and tricks to get you started.
First things first
It all starts with the job posting. You should look for the right company, where you can spread your wings and achieve your unmaintainable potential. You don’t necessarily need to be the PHP guru in the company, but it sure helps. Look for job descriptions that mention migrating to PHP from something else, so you know you’ll be calling the shots. Or, search for misguided jobs posts that require 10 years of PHP 5 experience, plus fluency in FrontPage and Netscape Composer.
Once you land the golden opportunity, be vocal from day one. Speak up at meetings; let your opinion be heard. Talk about object-oriented design architectures, enterprise, shifting paradigms, how “good enough” is not good enough, and, of course, your personal commitment to excellence. Make sure everyone consults your opinion on the important initiatives.
The pillars of unmaintainability
Inspired by the most excellent unmaintainable code — a must-read for anyone interested in keeping their job — here are two important concepts you need to grasp and master:
- Make it impossible for someone to easily change something without breaking something else. The maintainer doesn’t have time to understand your code. Maintainable code means being able to quickly find something, understand how it works, and change it without breaking stuff. You can’t have that. No one should be able to simply search for something and find it where they expect.
- Your code shouldn’t look unmaintainable, because someone will suspect something. It just has to be unmaintainable. The code should look normal to the poor souls maintaining it, but take them by surprise when they least expect it.
Best practices
- Ban coding conventions. Endless flamewars have been fought over coding and naming conventions. You can’t have that in your fine organization. You have awesome projects to build, and you can’t afford to spend countless hours in discussion of tabs versus spaces. Plus, conventions are restrictive. If new hires are not used to your conventions, they’ll be miserable. Unhappy programmers are unproductive programmers; explain that to anyone who asks. Let everybody write in their favorite style du jour. As for your own code, rotate your conventions. Go
camelCaseon Mondays,all_lowercaseon Tuesdays, mix-and-match on Fridays, and Hungarian on every February 29th. - No comments. Your code is beautiful; it doesn’t need comments. If someone can’t understand it, maybe they are not so good after all. If, by any chance, you’re forced to write comments, then simply overdo it. Elaborately describe the most obvious and trivial code, and skip the rest.
// In the following block, // we add two variables, // variable a and variable b. // Both of them are integers. // Declare variable a, // and assign it the value 1. $a = 1; // Now, declare variable b, // and assign it the value 2. $b = 2; // Add the two variables, a and b, // declared and initialized above, // and assign the result to variable c. $c = $a + $b; - Standardize on Notepad. Let the others suffer and eventually leave the team. You don’t need to listen to them complaining all the time. And, if someone asks why Notepad is the standard, be ready to explain. It comes with Windows — the only OS for today’s productive programmer — and it doesn’t cost anything. I’m sure you’ll find references on the Web that explain how you can use any editor, including Word, to write code for web pages, but Notepad is for real gurus. And, after all, your company hires only gurus.
- No unit testing. Explain to anyone who asks that you are hired to write high-quality code that doesn’t have bugs, ergo it needs no testing. (A bit of Latin always makes you sound smarter.) Why would anyone in their right mind spend any time writing useless tests that confirm the obvious, that the code works? Some things in life just are — the sky is blue, the sun rises from the East, and your code works, thank you very much. Move on. (Like with comme
Truncated by Planet PHP, read more at the original (another 6472 bytes)
No comments yet.