Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
It's funny.  Laugh. Programming IT Technology

How To Write Unmaintainable Code 437

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. '"
This discussion has been archived. No new comments can be posted.

How To Write Unmaintainable Code

Comments Filter:
  • by donnyspi ( 701349 ) <junk5 AT donnyspi DOT com> on Monday November 21, 2005 @12:42PM (#14082419) Homepage
    Our company's main system is written in FoxPro for DOS 2.6. The FP programmers here seem to have guaranteed lifetime employment :-)
    • scary, my companies main quoting/billing system was also written in foxpro by the owner, maybe ok when the operation was a mom & pop retail computer store, but now they deal with enterprise grade systems and services. The application doesn't really scale, one person can sieze up the whole application for the whole company (over 30 employees and dozens of contractors). Note this is not saying a bad thing about Foxpro itself, I've seen financial trading companies use it for dozens of people, this mainly
      • by devnull17 ( 592326 ) *

        Having worked at a similar mom-and-pop software shop that has outgrown its humble beginnings, I can say with confidence that there is nothing more dangerous to a company (and a programmer's mental health) than a boss who tries to involve himself in the software development process.

        Our flagship product was written (illegibly) in VB6. The codebase hadn't changed since VB3, and it wasn't very well-written to begin with. Our small development team spent about half of our time cleaning up after his architect

    • by vertinox ( 846076 ) on Monday November 21, 2005 @02:13PM (#14083318)
      Our company's main system is written in FoxPro for DOS 2.6. The FP programmers here seem to have guaranteed lifetime employment :-)

      I worked for a rather large ISP who in the process up and switched from a rather large home grown custom database program it had used for years to the corporate Vantive which cost them millions at the time.

      I asked my manager why would they bother doing such a thing when the old program worked just fine. He said "The guy who made the program died and know one knows how to code for it."

      I laughed for a moment and then by his blank face realized he wasn't joking...
      • by benjamindees ( 441808 ) on Monday November 21, 2005 @03:51PM (#14084233) Homepage
        Why is this so difficult for employers to comprehend?

        If you're paying someone to do a complex job (hint: if it costs $1 million to replace them, it's a complex job), and they die/quit/retire, find a smart person to replace them. Don't find two dipshits to replace them. Don't give Suzy the secretary a $2 raise to do their job (unless Suzy the secretary really is a smart person, in which case, why weren't you paying Suzy more to begin with?)

        I've seen it happen over and over again. Smart person runs entire company single-handedly. Smart person quits/dies. Company panics. Company spends ungodly sum of money to completely redesign whatever it is the smart person was doing. New system ends up missing functionality and costing the company loss of productivity.

        Every time, something tells me that if this person was smart enough to do everything they were doing, there was probably a reason for it. That's not to say they can't be replaced, just that they probably can't be replaced with any random dipshit, or any random piece of off-the-shelf software.

        So, if you're a manager/owner, and you find yourself in this situation: when smart person quits, put an ad in the paper, hire a headhunter, find someone with an IQ of 130 to replace them. Pay them 20% more than you were paying the previous person. Don't worry about whether the new person has experience doing exactly what the previous person did. Don't worry about redesigning anything. If something needs to be changed, the new smart person will be perfectly capable of changing it.
        • by hpavc ( 129350 ) on Monday November 21, 2005 @04:18PM (#14084481)
          They would say "we never really planned on keeping that peice of software [dead guys name here] wrote, but we never decided on a package or got funding for a package to replace and we had so many things going on ..."
        • by AugstWest ( 79042 ) on Monday November 21, 2005 @04:41PM (#14084719)
          Have you ever tried to hire that One Smart Person? Hell, even if s/he existed, they'd never make it past HR.
          • by Midnight Thunder ( 17205 ) on Monday November 21, 2005 @07:59PM (#14086481) Homepage Journal
            Have you ever tried to hire that One Smart Person? Hell, even if s/he existed, they'd never make it past HR.

            Yup, especially since HR adheres to the "check-box" policy off hiring. Do you have such a skill yes/no? This totally eliminates the people who actually can learn the stuff. I was speaking to one headhunter who said that one company wanted someone who could hit the ground running, because they had a tight deadline, and then as the project got closer to the finish date, and they still hadn't found such a person, they became fussier about thre criteria. This is akin is trying to find the ideal girl friend and upping the criteria when you don't find her.

            Okay must admit since taking a sabatical trying to find another job is proving to be a little harder than expected. And the fact that I am in IT doesn't seem to help me find the "beautiful girl, who is smart and funny and I spend my time with" ( match.com didn't help either ;) I will get both one day, but I am not sure how (maybe just a hopeless optimist?)
  • missing icon? (Score:5, Insightful)

    by BushCheney08 ( 917605 ) on Monday November 21, 2005 @12:43PM (#14082431)
    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...
    • Re:missing icon? (Score:3, Interesting)

      by gbjbaanb ( 229885 )
      Well, it did mention Java so it must be full of new funny ways you can break Java coding styles... forget that it contains references to all the old bad programming jokes from years past - eg. one section describes where the compiler only recognizes the first 8 characters so use_unit_update is the same as use_unit_setup.

      Its an old joke. with a new header. That's all. Next submission please.
    • by Golias ( 176380 ) on Monday November 21, 2005 @12:51PM (#14082531)
      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!
  • by rolfwind ( 528248 ) on Monday November 21, 2005 @12:43PM (#14082438)
    but why would you want to burden yourself by being bound to a program for the rest of its useful life?
  • by espergreen ( 849246 ) on Monday November 21, 2005 @12:44PM (#14082445) Homepage
    #!/usr/bin/perl
    &!@&/*!QW(*()@!@(I!@()!@)(!@*/\()!@&*(@!/*(&

    Ok, I admit it. I just banged on the keyboard :(
  • I guess not every joke has to wait until April 1.
  • not how it works. (Score:5, Insightful)

    by yagu ( 721525 ) * <yayagu&gmail,com> on Monday November 21, 2005 @12:45PM (#14082453) Journal

    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)

    • I can. (Score:5, Interesting)

      by Ungrounded Lightning ( 62228 ) on Monday November 21, 2005 @01:05PM (#14082686) Journal
      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.
      • Re:I can. (Score:5, Funny)

        by bataras ( 169548 ) on Monday November 21, 2005 @01:29PM (#14082927)
        Which chapter 14?

        Were you age discriminated?
        http://www.law.cornell.edu/uscode/29/ch14.html [cornell.edu]

        Or were you a whaler?
        http://www.law.cornell.edu/uscode/html/uscode16/us c_sup_01_16_10_14.html [cornell.edu]
      • My niece's boyfriend seemed to think he could get security like this by being the only network guy to know the passwords to the company's routers.

        I had to point out that if he had a boss who would not know why such a situation shouldn't exist would probably also not know why the network guy shouldn't be laid off.
      • Re:I can. (Score:5, Interesting)

        by TilJ ( 7607 ) on Monday November 21, 2005 @02:50PM (#14083681) Homepage
        Exactly. What many posters don't seem to realize is that if you make your irreplaceable, you've also made it impossible to be promoted. This isn't just internal to your current organization -- doing the same thing for year after year without making career progress looks like hell on a resume.

    • by Gruneun ( 261463 ) on Monday November 21, 2005 @03:19PM (#14083934)
      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. In fact, I can think of two people at two different companies.

      One kept the only copy of his source code on a laptop that he carried with him. The code was so horribly unmaintainable that none of us would touch it, though it was hardly an issue since we rarely got more than the pre-compiled libraries from him. The boss was so scared that he would lose the source that he falsified and submitted timecards for almost three months when the guy decided he was "unappreciated" and stopped coming to work. It goes without saying, but this manager was just as incompetent. In fact, I'm convinced the only reason either one survived as long as they did was through their symbiotic, parasitic relationship.

      The other guy put his code through an obfuscator, literally, that removed all the indentation, carriage returns, and comments, meanwhile renaming all of his class, method, and variable names to random strings of the characters n, e, and w. It also added random comments made up of the same random strings sprinkled with semicolons. Yeah, cute. During the unemployment interview, he stated that he had fulfilled his requirements, the code compiled and worked, there was never a formal standard for the format, and he couldn't be held responsible for the additional work of his former co-workers. I think what clinched his unemployment benefits was stating he had no hard feelings and maintaining that he was available for consulting work if the company had acted too quickly.
    • by irablum ( 914844 ) on Monday November 21, 2005 @03:28PM (#14084011)
      I was once brought back in even though my code was absolutely maintainable. I had left the company for other reasons ( Inner Mongolia ) but they brought me back because something didn't work. I spent 10 minutes figureing out that the problem was hardware, 5 minutes directing the tech on how to fix the hardware, and 2 hours and 45 minutes bullshitting with my former co-workers, all at $75 an hour.

      Ira
    • I can, too (Score:5, Interesting)

      by BaudKarma ( 868193 ) on Monday November 21, 2005 @03:42PM (#14084148) Journal
      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.
  • by ThatGeek ( 874983 ) on Monday November 21, 2005 @12:46PM (#14082466) Homepage
    How to really write unmaintainable code:

    Apply equal parts of Perl [perl.org] and Guinness [guinness.com]
  • Growth (Score:5, Interesting)

    by TheRealFritz ( 931415 ) on Monday November 21, 2005 @12:48PM (#14082500) Homepage
    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 ;)
  • by 0kComputer ( 872064 ) on Monday November 21, 2005 @12:48PM (#14082501)
    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!.
  • by antdude ( 79039 ) on Monday November 21, 2005 @12:49PM (#14082506) Homepage Journal
    A co-worker sent me these unmaintainable code essays [mindprod.com] back in August 2005. Taken from AQFL [aqfl.net].
  • by MajorDick ( 735308 ) on Monday November 21, 2005 @12:50PM (#14082517)
    I used to employ similar tactics on large non-residnetial contracts, not for myself but for our company, I leared this from my Grandfather and Uncle who did the same, 40 years after the construction a hospital my Uncle was called out of retirment (as a consultant to the firm that got the expansion) To show them "the lay" his price tag $250,000 for 1 year at 35 hrs/wk. He is in the process of building a new home with the proceeds.

    On the code side, things I wrote 10 years ago I look at and think who the F*** wrote this, but back to my plumbing, that was the first lesson I was "Taught" NEVER EVER Say something like who the hell did this this way and why, more often than not after being in the business IT WAS YOU !, sure enough about 6 major jobs I went on to think to MYSELF , who did this holy shit is this complex, well after a day on the job I realized it was ME!!!

    Never say "Who the Hell wrote this" out loud...a sure way to hang yourself when you practice this method of job security.
  • Not So (Score:5, Insightful)

    by AnalogDiehard ( 199128 ) on Monday November 21, 2005 @12:50PM (#14082525)
    Writing unmaintainable code does not make you irreplaceable and does not sustain your work duration.

    I have had way too many times in my contract work that I was assigned to upgrade unmaintainable code.

    In fact, I earned a reputation as a saving grace and the original coder was never called back and he earned a black eye as a poor coder.

    Now who do you think stayed on the job longer?

    • Re:Not So (Score:4, Funny)

      by trollable ( 928694 ) on Monday November 21, 2005 @02:06PM (#14083239) Homepage
      If you could upgrade the code, it means the original coder wasn't good enough. Writing unmaintainable code is not given to every one. Unmaintainable code is code you can only delete, not upgrade.
    • I'm with you.... (Score:3, Informative)

      by Belial6 ( 794905 )
      I always try to write code with a bus in mind. No, not a data bus, but a big steel diesel passanger carrying bus. The question is what happens if I get hit by a bus tomorrow. The company that I am currently contracting to, started at needing ~12 a month of work. After a few applications that even their least talented coders could make modification to, I am now at a steady 40 to 50 hours of work a week.

      Another benefit of coding to for a bus is that after a couple of successes, the people you work for
  • guilty as charged (Score:3, Insightful)

    by LWATCDR ( 28044 ) on Monday November 21, 2005 @12:51PM (#14082534) Homepage Journal
    I just can not stop using i as an index. My programing teacher learned FORTRAN first and when the taught me Pascal he used i in for loops so I do this day.
    • by psavo ( 162634 )

      I just can not stop using i as an index. My programing teacher learned FORTRAN first and when the taught me Pascal he used i in for loops so I do this day.

      If 'i' is obfuscation of 'index' then 'for' is obfuscation of 'for_as_long_as_expression_between_semicolons_is_t rue'.

    • "i" is a standard indexing variable name. Anywhere it's used in code, you can usually assume that you;re doing some sort of scanning over an array of some sort.

      So it's standard enough, I think.
  • TheDailyWTF.com (Score:5, Informative)

    by Str8Dog ( 240982 ) on Monday November 21, 2005 @12:51PM (#14082537) Homepage Journal
    If you need a daily reminder of "what not to do", I highly suggest bookmarking TheDailyWTF.com [thedailywtf.com].
  • This is ancient... (Score:5, Informative)

    by zimbu ( 99236 ) on Monday November 21, 2005 @12:51PM (#14082538)
    Roedy started this back in the 90's, you could at least have the decency to link to the latest version [mindprod.com].
  • by markv242 ( 622209 ) on Monday November 21, 2005 @12:55PM (#14082568)
    The kind of coder who deliberately writes bad code just to maintain their employment is always the first coder shown the door. Always. It is a complete urban myth that not commenting spaghetti code will keep you in a job. There is always someone else willing to do your job, no matter how specialized you think you may be.

    • by ergo98 ( 9391 )
      The kind of coder who deliberately writes bad code just to maintain their employment is always the first coder shown the door. Always. It is a complete urban myth that not commenting spaghetti code will keep you in a job. There is always someone else willing to do your job, no matter how specialized you think you may be.

      I am amazed that so many people don't realize that this was a joke. It's a joke people. Are all of these people replying seriously 16? I have to suspect so, because this was immediately iden
      • by SeanDuggan ( 732224 ) on Monday November 21, 2005 @02:14PM (#14083332) Homepage Journal
        I had a professor assign this essay as required reading for our Computer Science class. While none of us (hopefully) are deliberately employing the tricks and techniques in there, I'll bet every one of us can look through there and find one thing that we've been guilty of doing whether it was inane variable names, inaccurate comments, or bizarre variable scope issues. By reading through, it forces you to confront your laundry list of faults and decide which ones need to be fixed.

        And as for the maintainer interpretting it, you're absolutely right that most people just throw up their hands. It's hard to interpret someone else's code for anything past the trivial. Doable, but hard enough that rewriting it often is a good way. Heh, besides which, it's amazing how many times I've thrown up my hands, rewritten the code, and by the experience found that I understood the original code.


  • ... *even those who spend all their time reading slashdot* .....

  • Use pictograms and arrows to ensure that everyone will understand what you are writing.

    My favourites:
    "Always look for the most obscure way to do common tasks."
    "People who come after you have no business modifying your code without thoroughly understanding every line of it."
    "Wherever the rules of the language permit, give classes, constructors, methods, member variables, parameters and local variables the same names."
    "Never perform code coverage or path coverage testing. Automated testing is for
  • Had to stop (Score:3, Funny)

    by 00_NOP ( 559413 ) on Monday November 21, 2005 @01:07PM (#14082709) Homepage
    I was laughing too much and getting strange looks in the office. Personally I use perl to guarantee employment, but there's a look to work on here.
  • by decipher_saint ( 72686 ) on Monday November 21, 2005 @01:12PM (#14082758)
    I don't need no instructions to know how to rock.
  • by digidave ( 259925 ) on Monday November 21, 2005 @01:18PM (#14082815)
    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.
  • Old old old (Score:5, Informative)

    by po8 ( 187055 ) on Monday November 21, 2005 @01:21PM (#14082854)

    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?

  • by wuice ( 71668 ) on Monday November 21, 2005 @01:45PM (#14083064) Homepage
    I know this article is somewhat tongue-in-cheek but it's actually a prevelant mentality. As someone who have watched people write unmaintainable code to ensure their own job security...

    If the code is unmaintainable, the end product is probably bad. If the end product is bad, you're not protecting your job but making a case for your worthlessness. Even if the end product is good, most companies would favor a fresh, new person who can differentiate themselves from you by writing a more friendly, maintainable version of the same. When I have come in (back in my indie days) to update or maintain a system that is unmaintainable, I have always made a good case for a more ambitious bid (and more money) to recreate the system from scratch (or recreate as much of it as is necessary) in a more standard, maintainable format.

    Besides, as all you open source geeks know, this is (job) security by obscurity, and while it may cause a major inconvienence for your employer, it's not going to force them to keep someone they want to can. IT kids are in for a rude awakening (or have already gotten one) if they think we're still in the era where you're irreplacable, where some other code monkey couldn't come in and do the same or better of a job of what you're doing for less money in a heartbeat.

    Here's a hint, find a place that you actually ENJOY working for, that treats their employees well and isn't looking to pull the plug on them at the most convienent time.. And then give them the best work you can offer. Be willing to take the lumps as a line employee for a while and actually earn a career in that company.
  • by NecrosisLabs ( 125672 ) on Monday November 21, 2005 @01:48PM (#14083089)
    A couple years ago, I showed these rules to another developer. We had a good chuckle, particularly about
    Misleading names
    Make sure that every method does a little bit more (or less) than its name suggests. As a simple example, a method named isValid(x) should as a side effect convert x to binary and store the result in a database.

    The next day we had a meeting to examine a legacy application that we were going to be re-writing. Another dev was discussing the DataLoad method. Which loaded a flat CSV file.

    And validated the data

    And stored the result in a database.

    It is very hard to look professional in a meeting when your face is beet red and your eyes are screwed up tight to keep from breaking out it gales of laughter.
  • Bad, BAD Advice! (Score:5, Insightful)

    by Roofus ( 15591 ) on Monday November 21, 2005 @01:48PM (#14083090) Homepage
    Make sure you're irreplaceable

    First rule of business: Don't be irreplaceable. If you can't be replaced, you can't be promoted!
  • From a language processor I worked on eons ago; I use it as an example of what's "great (:-/)" about PL/I:
    IF IF = THEN THEN THEN = ELSE ELSE ELSE = IF;
    Yes, it compiles (if IF, THEN and ELSE have the appropriate types).

    And how can you not love a language that has a data type for Pounds Sterling?
  • by gelfling ( 6534 ) on Monday November 21, 2005 @02:19PM (#14083390) Homepage Journal
    Once worked with a high functioning austistic named Chester (Cheddy) Abramowitz who typically coded COBOL as a monothlithic bloc from col 6-80 with no spaces, breaks, indents or lines. Moreover his dataset names were things like MASTER.BATE

    It kept him employed.
  • by Jboy_24 ( 88864 ) on Monday November 21, 2005 @02:42PM (#14083602) Homepage
    When writing a method that will do_something. Ask yourself, is this really the place to do that? Maybe you're being a little too forceful to do it right there?

    Perhaps you should create an interface (make it an inner interface to a public static inner class, yes its possible).
    Make sure you use a common naming convention so you can look up the class using Reflection.
    Then once you get your class, make sure you use another factory to get the class you feel comfortable to finally do something.

    Finally, put your "do_something" code in the constructor of the class.

    When your code base becomes 1,000,000 lines of this, you'll achieve the final Zen obfustication moment, when a new director of engineering asks you to document this and you can say, with a straight face, and in total honesty, "Its too complex to document"

                     
  • by Flyboy Connor ( 741764 ) on Monday November 21, 2005 @02:43PM (#14083614)
    Such bad code actually exists.

    For five years I worked for a boss who was in the habit of taking jobs that nobody else wanted. The good thing was that he would get paid a lot. The bad thing was that I had to dabble in unmaintainable code. At one time I even had to make changes in a program for which no source code existed anymore. That was not the worst job, though. The worst was a change I had to make to a program that had the simple task of printing a list of articles in stock, with their locations. It printed the articles in two columns: the left column contained articles of types 1 and 2, and the right column contained articles of types 3 to 9. I had to change the program so that it would print three columns: left column the same, but the right column split into types 3 and 4, and 5 to 9. Does not sound too difficult, right? I mean, even without looking at the code, purely knowing the function of this program makes you think "that should been done in no more than 2 hours."

    It took me two weeks. The program was peppered with functions that were copies of other functions with a very small change. The original programmer used ridiculous methods to fill print lines. The general way of printing a line is collecting information through a central function, and when that function has all the information it needs, print the line. In this case at dozens of points in the program the programmer tried to predict whether or not he would have enough information to print a line, and then do it. If I would have a design document, I would have rewritten the program from scratch, but of course no such document existed.

    Every little change I made to the program had unforeseen effects. When I started, I had (of course) made a test-print, which I could use to compare outputs. I made a small change, and suddenly the list contained less articles than the original list. Another small change, and suddenly the list contained more articles than the original list. I tried to assess what reasoning the program would use to include or exclude articles, but there was no way to determine that from the code.

    After two weeks of work the program printed three nice columns, with all the original articles there, and a few, very few, that were not on the original list. I could not understand why these extra articles were there, but if they should not be there, I thought it would be best if I would just implement a condition to exclude them, if I would know what that condition should be. So I called the company who used the programs and asked them about these extra articles. Their answer was, "My God, we have been missing those for YEARS. Now we'll finally be able to find them again."

  • by mabu ( 178417 ) on Monday November 21, 2005 @03:01PM (#14083785)
    I find it really disturbing that programmers are so insecure they need to deliberately make their code difficult to understand. That's just stupid. If you're a good programmer, you will have job security. If you're a crappy programmer, all the obfusification in the world won't give you job security.
  • by porky_pig_jr ( 129948 ) on Monday November 21, 2005 @06:35PM (#14085710)
    Perl, with its 'do the same thing gazillion different ways' is a perfect language to write completely unmaintaintable code.

    I've leared that the hard way, by starting my Perl education maintaining the code written by someone else. I've fought back by writing the number of apps in Perl, as well. Poor suckers kept calling me at my new job, long after I quit.

Real Programmers don't write in PL/I. PL/I is for programmers who can't decide whether to write in COBOL or FORTRAN.

Working...