Slashdot Mirror
How To Write Unmaintainable Code
An anonymous reader writes "Make sure you're irreplaceable -' In the interests of creating employment opportunities in the Java programming field, I am passing on these tips from the masters on how to write code that is so difficult to maintain, that the people who come after you will take years to make even the simplest changes. Further, if you follow all these rules religiously, you will even guarantee yourself a lifetime of employment, since no one but you has a hope in hell of maintaining the code. Then again, if you followed all these rules religiously, even you wouldn't be able to maintain the code! You don't want to overdo this. Your code should not look hopelessly unmaintainable, just be that way. Otherwise it stands the risk of being rewritten or refactored. '"
#!/usr/bin/perl
:(
&!@&/*!QW(*()@!@(I!@()!@)(!@*/\()!@&*(@!/*(&
Ok, I admit it. I just banged on the keyboard
Assuming this is tongue-in-cheek. My experience has been no matter how poorly written or unmaintainable something is, it offers little insurance to the author for keeping a job. I've been handed the reins to maintain countless "gone" employees' code. And, if the code isn't maintainable and the program is important or desirable enough, companies just limp along with the deficiencies. I can't think of a single occasion where someone was kept because of fears of maintaining their code, nor where someone was brought back to maintain their 'unmaintainable' code.
(+/- 2 sigma complainers -- reply here)
How to really write unmaintainable code:
Apply equal parts of Perl and Guinness
What are you eating? isItVeg?.
I've heard fellow programmers suggest this before, but the way I see it, you are hurting yourself and here's why: when you become an absolute specialist in one area (in this case your particular implementation), you will be pigeon-holed into this role with no chance for growth.
;)
A much better approach to job security is to adapt to the needs inside the company and make sure your skills are needed. This will also lead to more opportunities for pay increases and general healthiness of your psyche.
In the end, what makes you interesting as a developer should be your ability for problem solving and not your ability to obfuscate your work, unless, of course, your intention is not to work
In skimming the article, I realized that an obfuscator does exactly what hes describing. I know its a joke article, but if you really wanted to have unmaintainable code in .net for example... just compile, obfuscate, disassemble, check in viola!.
Top 10 Reasons To Procrastinate
10.
...it generates a root exploit.
Ummmm, where's the foot icon? It's good to know that the author considers this a joke, but I'm afraid that Hemos might not be in on it...
If you've seen the Slashcode, you would know why this joke would be lost on Hemos and the rest of the staff here.
Zing!
Information wants to be anthropomorphized.
Roedy started this back in the 90's, you could at least have the decency to link to the latest version.
I can't think of a single occasion where someone was kept because of fears of maintaining their code, nor where someone was brought back to maintain their 'unmaintainable' code.
I can.
My very first programming job - which went on for years and where I did a bunch of stuff - but was quite underpaid. There were two of us programming when the institution in question had a financial crisis and could only keep one. My code was maintainable, the other guy's wasn't. So I got the boot.
And had a new job at higher pay in a better situation 25 minutes after letting it be known that I was available.
Before it was a matter of writing code that *I* could maintain. After it was a matter, not just of principle, but of practicality. By making myself NOT indispensible I made myself valuable.
I went on to a long carreer of mixed consulting and salaried positions, doing software for 35 years, and now hardware and system architecture. (And I once got the layoff because my code was the only stuff that worked, if you can imagine that. From another doomed company.)
The potential value-added in software and computer hardware has been so extreme that management can be AMAZINGLY pathological and still keep a company afloat for a couple years - and then find another job after it crashes. (Investors prefer someone with management experience crashing companies to someone with talent but no management experience. B-( Meanwhile the ones with management experience NOT crashing companies are too expensive or too busy.)
I'm now at six figures, stock options, one house paid for and another in progress, three cars, yacht, putting non-working (at the moment) wife with four degrees so far through more school (so she can do something she LIKES professionally), and held on to the current position through the slump, chapter 14, and out into the recovery. A big part of that was achieved by religiously making myself dispensible.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
The joke's on you! Slashdot beat digg by 6 YEARS: How To Write Unmaintainable Code Posted by Hemos on Thu Nov 18, '99 10:32 PM
Yeah... still a dupe.
Right now I have to maintain an unmaintainable web app. Let's put it this way...
- This app was originally written in PHP/FI 2.0 in 1997. There were also some C cgi apps and a few Perl scripts.
- Due to performance problems the entire dynamic site was changed to a statically rendered site, so after changes were made to a page that page was rendered as an HTML file.
- In 2000 it was updated to PHP 4 and the app had a core feature bolted on, essentially confusing the difference between a city and a county. This resulted in a worst DB design I've ever seen. I'm talking about splitting up core pieces of data that need to be together, using ambiguous field names (rid means different things in different tables. Some tables relate to each other on field names that seemingly have nothing in common. Some field names have typos, etc).
- The code was written first by a team of six programmers, then by a smaller team of three other programmers and finally by some weird guy who I was supposed to work with when I got hired, but a few days before I started he decided he didn't like computers anymore and he went into the grow-op business instead. My boss claims that maintaining the horrible code base made him go crazy and I'm inclined to believe that.
- Two records in the same table of the database may look the same in all ways, but they are actually entirely different things. The only way the app knows which one to use where is because that data's unique id is hard-coded into the app.
- I am rewriting our site search engine from scratch because touching the old one is dangerous. Altering small harmless-looking bits of code can actually break unrelated pages, but that breakage isn't noticed until that other page is re-rendered into a new HTML page, so I was finding out about problems weeks after I caused them. Arrrg!
- I have been unable to get the app working on any server I have setup. If the live server goes down we're toast because there is no dev box. The app relies on a horrific web of interconnected scripts, cron jobs, strange directories, and it even uses an older version of itself to perform some mysterious actions. I've got an image of the server's hard drive I can use to recover it from.
I have finally convinced my boss that this thing needs to be rewritten *now*. It's a house of cards with our business resting on top.
The global economy is a great thing until you feel it locally.
Roedy Green's fine How To Write Unmaintainable Code has been widely cited all over the web since its original publication in 1997. Surely at least a mention of the author and date of the article could have made the front page, so that those of us who've already seen it multiple times could know to skip it?
I worked security at this place while I was going to school. Think mid '80s
They had won a contract from a major hotel firm to design and run their reservation system. The whole system was written by one guy, who by all accounts did an absolutely superhuman job. Of course, the company had to choose whether they wanted the job documented well, or completed by deadline. You can guess what they chose.
Our hero stays busy for a few years, maintaining code and writing new modules, but there are still a long row of empty loose-leaf binders where the documentation should be.
Company gets bought out. After a couple of months, the new owners announce that they're going to rewrite the whole reservation system from scratch, and retire the old system. Our hero comes in next day and demands a large raise. Management declines, hero gives his two weeks, and management cuts him his check and escorts him out the door.
Management then brings in a team of consultants to keep the old system up and running until the new system is ready. Problem is, the team can't get anywhere. Nothings documented, calling the code "spaghetti" would be a compliment, etc etc etc. Meanwhile, they're getting requests from the customer for changes and updates which they can't process. In addition, system crashes now take hours to solve instead of minutes, which is bad because part of the companies revenue is based on system uptime.
After a few weeks, management finally throws in the towel, and realizes they'll have to bring the guy back and pay him what he wants. Except... they can't find him. He's moved, and left no forwarding address. Nobody knows where he is.
Management had to hire a private detective to track the guy down, and they finally found him up in the mountains in Colorado, doing whatever. They convinced him to come back, but I wouldn't want to be managements negotiator in that meeting.
It's the land of the brave, and the home of the free
Where the less you know, the better off you'll be.