Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming

How To Develop Unmaintainable Software 211

Posted by Soulskill from the just-do-what-comes-naturally dept.
jones_supa writes "Greg Jorgensen specializes in debugging, fixing, maintaining, and extending legacy software systems. His typical client has a web site or internal application that works, more or less, but the original developer isn't available. Greg lists some things you can do in your own software projects to keep him in business. In summary, the list goes as follows: Customize your development environment a lot, don't make it easy for the next programmer to start working on the code. Create an elaborate build and deployment environment and remember to leave out the documentation. Don't bother with a testing/staging server but instead have secret logins and backdoor URLs to test new features, and mix test data with real data in your database. Don't bother with a well-understood framework, write everything from scratch instead. Add dependencies to specific versions of libraries and resources, but don't protect or document those dependencies. For the icing of the cake, use the coolest mix of cutting-edge programming languages."
This discussion has been archived. No new comments can be posted.

How To Develop Unmaintainable Software More

How To Develop Unmaintainable Software

Comments Filter:

  • and I was still replaced.

  • Old news (Score:4, Insightful)

    by Pharmboy ( 216950 ) on Tuesday October 15, 2013 @05:36PM (#45137487) Journal

    This is old news. These methods have been around at least as long as C has. It only works in isolated situations and doesn't make you a good programmer. Or person.

    • Re:Old news (Score:4, Insightful)

      by lgw ( 121541 ) on Tuesday October 15, 2013 @05:47PM (#45137583) Journal

      Not every programmer was around when C was new. Everyone needs to learn these lessons, and preferably not the hard way.

      I'm mean, you'd think anyone starting a major project today would use version control, that shouldn't even be a question, right? Right?! Sigh.

      Some of his other stuff on his page is quite entertaining as well, like this one on Abject-Oriented programming [typicalprogrammer.com].

      • Re: (Score:2)

        by pjt33 ( 739471 )

        I'm mean, you'd think anyone starting a major project today would use version control, that shouldn't even be a question, right? Right?!

        And then you come across "modern" frameworks which can't be version controlled without database dump scripts.

        • Re: (Score:2)

          by lgw ( 121541 )

          It's exasperating. You can always choose instead to use a framework where all the DB stuff is generated from text files, and use proper source control and build processes - but you'd have to find those things important in the first place.

    • Re:Old news (Score:5, Interesting)

      by hurfy ( 735314 ) on Tuesday October 15, 2013 @06:23PM (#45137883)

      lol, 25 years ago we had ONE programmer able to maintain our software as he had done much of the customization of an out of the box accounting system. Bloody thing was so complex to start with noone wanted to touch it before we fixed it up, much less afterwards. Upto 10 Megabytes worth of code but no more than 32K loadable in memory. Must have been 100's of small chunks of code all calling each other in and out of memory every other keystroke.

      I managed to customize some reports but that was only part i ever dared to touch.

      The real kicker...written in a version of BASIC.

      Actually a pretty impressive system and worked well for 15 years. Always wondered how they managed to write such a monstrosity. Kept picturing a blimp hanger with a flowchart wrapped around the walls.

      • Apart from the small size, that looked a lot like something I was stuck with for a while. The source for that project varied from 100MB to 250MB, because of slightly different customised versions for clients. It was written in an ancient dialect of BASIC that runs on no current system, so it had to be emulated. It could have been replaced in 6 months by two dedicated programmers for far less than it cost to buy the rights to the whole thing in the first place, but only one of us was that dedicated. There wa

    • Re: (Score:2, Insightful)

      by girlintraining ( 1395911 )

      This is old news. These methods have been around at least as long as C has. It only works in isolated situations and doesn't make you a good programmer. Or person.

      A lot of that list is pretty damn arrogant, or at least naive. Let's start with just the ones the submitter quoted;

      Don't bother with a testing/staging server but instead have secret logins and backdoor URLs to test new features

      If you're so well known you can dictate terms to your employer, then maybe you can get away with this... for awhile anyway. But most of us, who code for a living, have to do the best with the tools we're given. We can ask for a testing server, but whether we get one is another matter entirely.

      As for 'secret logins' and 'backdoor URLs'... every login is supposed to be secret. If you can get a li

      • Re:Old news (Score:5, Insightful)

        by lgw ( 121541 ) on Tuesday October 15, 2013 @07:15PM (#45138311) Journal

        Well understood frameworks tend not to be highly optimized. If you are dealing with something where performance is absolutely critical, writing it 'from scratch' will probably get you better performance than taking one of those 'well-understood frameworks' out for a drive.

        Sure, of course, why not. It's not like your time is valuable or anything. And naturally, you will make this decision before coding starts, and thus before any measurements that the framework was actually slow, or for that matter that it was part of the perf bottleneck of the system. Nothing says "job security code" like elaborate cryptic algorithms to improve asymptotic performance of some in-memory task on a system where CPU never got above 5% in the first place.

        Let's not forget how bug free a framework used widely by thousands will be - there's no job security there at all if there's no bugfixing! But if we write our own, then there will surely be some horrific bug in the field that we can work until 4AM to fix, and management will call us heroes!

        The main thing, of course, when writing your own replacement for some common library that some new hire would already know is to avoid any documentation, and ideally abandon the effort halfway through, because the project ran out of time, only ever use 10% of what you wrote, and never document which 10% - heavens no!

        To make doubly sure that no new hire could ever support this code, remember to follow this key element of Abject-Oriented Programming: [typicalprogrammer.com]

        Documentation
          It's said that code should be written for people to read, so it follows that documentation is written for no one to read. Documentation should be written for every new module and then maintained as changes are put into production, or at least the next time thereâ(TM)s a lull in the workload.

        A good time to write documentation is when someone in the department gives two-weeks notice: use that time to make sure the departing team member documents all of their code.

        Cluttering up the source code with lots of comments explaining what the code is trying to do is distracting and slows down the compiler. That's why abject shops that follow "best practices" keep documentation in a document management system where programmers can't accidentally delete it.

        Sage advice, I'd say.

        Bottom line here is that this 'list' is just the logical conclusion of a career of mediocrity spent shifting blame around instead of working the problem. Real programmers can use anything

        Perhaps you missed the part that the author of TFA makes his living answering panicked calls to bugfix production legacy code, presumably because some "real programmer" did in fact "use anything", and this advice is based on long experience of what makes code unmaintainable. My own experience/advice lines up with his rather well in this area, I'd say.

        • Re:Old news (Score:4, Insightful)

          by girlintraining ( 1395911 ) on Tuesday October 15, 2013 @11:10PM (#45139883)

          Sure, of course, why not. It's not like your time is valuable or anything. And naturally, you will make this decision before coding starts, and thus before any measurements that the framework was actually slow, or for that matter that it was part of the perf bottleneck of the system. Nothing says "job security code" like elaborate cryptic algorithms to improve asymptotic performance of some in-memory task on a system where CPU never got above 5% in the first place.

          You devoted considerable effort to coming up with a response. Yet you failed in every way to realize that the point being made was that good programmers often depart from guideline, and with good reason. If this was less a list and more an advice column, then I wouldn't have picked it apart. But it comes off as a "dos and don'ts" list, and frankly... such a list has neither educational nor informational value.

          But whatever, if you want to continue down this path, okay then; Look smartass, you can't test a framework against your own hand-crafted code because you don't know how your hand-crafted code is going to perform until you build a prototype. So fucking duh, yes, the test happens after. And if you'd sat down on a whiteboard and stenciled out a block diagram of what your app, or at least the part of it you're working on, does... you'd already know which branches are going to be most used, and where special attention needs to be paid towards optimization. I already provided the caveat that where performance is critical. I'm not talking about business apps or databases when I say these things. I'm talking low level shit like how they're building switches that begin writing out a new packet while the previous packet is still incoming to gain precious milliseconds in high frequency trading. You aren't writing that with .NET or whatever framework you're upset I dismissed from consideration. PERIOD.

          Also "But if we write our own, then there will surely be some horrific bug in the field that we can work until 4AM to fix, and management will call us heroes!" is about the most moronic thing you can say. Management doesn't consider your project resulting in piles of overtime "heroic". It considers you a poor performer and will be looking to replace you.

          Perhaps you missed the part that the author of TFA makes his living answering panicked calls to

          Yes, I got that. Wanna know something? Ask a police officer how honest the average person is. They'll tell you the average person is a slimy son of a bitch who's probably packing heat and looking to kill you and everyone you ever loved or knew. Wanna know why? Because that's their day in and day out experience. Ask a surgeon how to fix a problem, and every answer will involve a knife. It's the same everywhere.

          You got suckered in by assuming one man's personal experience counted as fact. It doesn't. I recognize that in his particular line of work, he runs into these problems all the time, but that doesn't mean they were bad choices at the time they were made... it means that by the time it got to him, it had become a problem. And that's all.

          Look, bottom line here is that when you code professionally, you are engaged in a massive balancing act between deadlines, error checking, other people's contributions, etc., etc. Coding professionally is an organic process, and while everyone knows what the best practices are (documentation, QA, modularity, readability, etc.) these are ideals to strive for, not things we can actually achieve on every single project. That would take a level of super-human ability that nobody yet born possesses. It's like the old adage in IT: "Cheap, Fast, Right. Pick any two."

          My own experience/advice lines up with his rather well in this area, I'd say.

          My own experience is that a mind intent on something refuses to admit to better things. In programming professionally, I've come to refer to this as target fixation -- they get tunnel

          • Re: (Score:2)

            by lgw ( 121541 )

            You got suckered in by assuming one man's personal experience counted as fact. It doesn't. I recognize that in his particular line of work, he runs into these problems all the time, but that doesn't mean they were bad choices at the time they were made... it means that by the time it got to him, it had become a problem. And that's all.

            Crap code is crap code.

            these are ideals to strive for, not things we can actually achieve on every single project.

            Right - sometimes when the crunch is on we write crap code. Hopefully there's time to clean it up. But the crunch doesn't make the crap code good, it merely makes it necessary.

            My own experience is that a mind intent on something refuses to admit to better things. ... I've come to refer to this as target fixation

            You are still talking about code, right?

        • Re: (Score:2)

          by GWBasic ( 900357 )

          Let's not forget how bug free a framework used widely by thousands will be - there's no job security there at all if there's no bugfixing! But if we write our own, then there will surely be some horrific bug in the field that we can work until 4AM to fix, and management will call us heroes!

          Counter that with the amount of time I've spent wresting design flaws due to well-known but poorly-chosen frameworks.

          Don't pick a framework because you assume that you're supposed to:

          • Choose correct design patterns
          • Prefer well-encapsulated libraries with clear purposes
          • Only use frameworks that directly add value to your chosen design patterns

          The issue with frameworks is that they often touch all layers of a program, or product. If the wrong framework is chosen, (or built,) then the entire project must be refa

          • Re: (Score:2)

            by lgw ( 121541 )

            Sure, but there's usually a good choice available. Rolling your own approach to dealing with the DB because ORM just won't work for a project is one thing (and that's often true because most ORM is too inflexible), but that's not "rolling your own framework". If what you're about to write will end up looking like an ORM framework, then just don't - do the research and pick one the meets your needs. If what you're about to write will look nothing like an ORM framework than maybe. (Or similar logic for ot

      • How often are the things done by frameworks performance critical? Last I developed a site in django, the most time consuming operations were database queries (which are easily done outside of the Model system if one so desires), but writing the sql manually would take much more time for very little benefit. Likewise, rolling your own templating system is virtually worthless when dealing with your average site: the db queries simply dwarf the render time and a half decent caching system will further reduce t

      • Re: (Score:3)

        by Draknor ( 745036 )

        I think you are missing the author's points in your rebuttal.

        Testing server -- maybe it's not ALWAYS possible with expensive enterprise-y server software, but just about anyone can spin up a VM on their dev machine to simulate (with varying degrees of accuracy) a production environment.

        Secret logins & back doors -- you mean you've never created a "god" or "super admin" account (or "secret URL") that could access all kinds of technical / debugging info that regular admins/users shouldn't see? Having suc

      • Well understood frameworks also have widely disseminated and well understood (by the very people you would prefer didn't) vulnerabilities, not to mention unfixed bugs that persist because they're in the framework, not in your code.

        There are a lot of very good reasons to write your own code. The presumption that your own code is poor code, or that it isn't worth the time, makes assumptions not in evidence about every programmer who has done so.

        Sometimes frameworks/libraries/etc are the way to fly, especially

      • Re: (Score:2)

        by Ubi_NL ( 313657 )

        what language is "cgi-bin"?

  • Great little article (Score:5, Insightful)

    by Anrego ( 830717 ) * on Tuesday October 15, 2013 @05:38PM (#45137501)

    Every one of these points hits the nail square on the head.

    The key to take out of this is: document document document! At minimum you should have a set of instructions to re-build your dev and build environment. "Insert the <your company> dev workstation image v4" is not allowed to be a step! Your elaborate continuous integration multi-tree setup and mountain of environment setup scripts and template directories are great until the guy who set it up takes off and you have to upgrade something. Ideally a set of instructions talking to the motivation of certain decisions, roadblocks encountered, etc.

    One thing the article doesn't have is have lots of 3rd party tools and keep the license servers/license files on whatever box is most convenient for the dev working on it at the time.

    • "my code is self-documenting."

      A statement that is always true as long as no one else has to read it.

      • Well written code is self documenting, or extremely close to it. A well done build and deploy process is as well, using Maven/Jenkins, etc. Documentation can consist of "get this out of Git and build it with Maven". Things aren't as opaque as they used to be.

    • Every one of these points hits the nail square on the head.

      The key to take out of this is: document document document! At minimum you should have a set of instructions to re-build your dev and build environment. "Insert the <your company> dev workstation image v4" is not allowed to be a step! Your elaborate continuous integration multi-tree setup and mountain of environment setup scripts and template directories are great until the guy who set it up takes off and you have to upgrade something. Ideally a set of instructions talking to the motivation of certain decisions, roadblocks encountered, etc.

      One thing the article doesn't have is have lots of 3rd party tools and keep the license servers/license files on whatever box is most convenient for the dev working on it at the time.

      He left out the best method: Hand write everything in assembly language...

  • Use a language that no one ever heard of (Score:3)

    by jfdavis668 ( 1414919 ) on Tuesday October 15, 2013 @05:44PM (#45137561)
    We inherited a system written in a language we never heard of. It wasn't just uncommon, it was way out there. Unfortunately, It was a while ago and I don't remember what it was called. We ran the system, but had to rewrite it immediately. Luckily, the reason we inherited it was because the old system was crap, and the customer was willing to pay us to redesign it. If the previous vender had put a little more effort into it, we wouldn't have been able to take the business.
    • Back in the early '80s, I did some work at JPL. Much of our work was done in a language that we were the only two people who'd ever heard of it: MPL. Why? Because it was a custom pre-processor that my partner had written for PL/1 to add all of the syntactic sugar automatically. No, I never knew why he didn't just include a set of macros and use the regular pre-processor. For all I know, it wouldn't do quite what he wanted it to do.
      • PL/I was the first language I actually learned. Did some work in Fortran before that, but all I could do was modify a program someone else already wrote. That was the strange thing about this obscure language. I had run across so many, PL/I etc, APL, COBOL, SNOBOL, Scheme, Lisp, Prolog, Pascal, Ada, Smalltalk, C. You think I would have at least heard of it. It bugs me I can't remember what it was called. It wasn't a variation of some other language.

    • APL works perfectly with Twitter Bootstrap. Send me some money and I will tell you how...

    • Re: (Score:2)

      by djbckr ( 673156 )
      I had a similar situation. I inherited a company program that was written in a language called Magic [stackoverflow.com]. It was some sort of table-driven record-based language that, to code, literally went up one side of the screen and down the other. It was as bad as it sounds.
      I rewrote the software in Delphi (this was back in the 90's) and it was orders of magnitude faster.

  • Frameworks (Score:3, Interesting)

    by Tablizer ( 95088 ) on Tuesday October 15, 2013 @05:51PM (#45137611) Journal

    Don't bother with a well-understood framework, write everything from scratch instead.

    Is this saying only use widely-available frameworks (to do it "right"), or don't write your own frameworks from scratch? I have time-tested C.R.U.D. frameworks I often use for web projects that I've improved and tuned over the years. They are reasonably well-commented.

    • Custom work is ok, as long as two requirements are met:

      A) it works
      B) it is easy for a new guy to pick up.

      Those are the main benefits you are getting from a well known framework, so as long as you hit those requirements, you are fine. A lot of people who write their own custom frameworks fail at both, they are constantly trying to fix their framework, debug it, get it working, which is a mess.

      • A) it works
        B) it is easy for a new guy to pick up.

        Those are the main benefits you are getting from a well known framework,

        Just because a framework is well known does not imply either of these two things are true.

        • The point of it being well-known is that you can easily hire people who know how to use it, so that is why B is important for custom frameworks......if you can't hire someone who already knows it, then it better be easy for newcomers to learn.

          For A, of course not all well-known frameworks work, but you can know which ones to avoid, or at least what kinds of troubles you'll run into. I suggest avoiding PHP, but if you use it without being aware of the drawbacks, it's your own stupid fault.

    • Re: (Score:2)

      by lgw ( 121541 )

      Is that "whooshing" sound you hear familiar to you? I suspect you've heard it before.

  • Just get a hold of lex & yaxx, antlr or your favoriate tools and write your own language. You could probabyl abuse Lisp macros anough to do this too. I once worked with a company where the lead programmer had invented Hugh-BOL, and that's what they coded in.

    Now, I do admit that a DSL it the best approach from time to time, but there is an limit...

    • Just get a hold of lex & yaxx, antlr or your favoriate tools and write your own language. You could probabyl abuse Lisp macros anough to do this too.

      It seems you are already well underway!

  • Programmer not the whole story (Score:4, Insightful)

    by jasnw ( 1913892 ) on Tuesday October 15, 2013 @05:55PM (#45137647)

    Yeah, yeah - code clean, test-test-test, document-document-document, have separate test/run machines that are configured the same, yada yada. This is all well and good, and any halfway-decent developer knows all this. However, software development is not done in a vacuum and each and damn near everything mentioned is involved in cost/time benefit analyses when crunch-time comes (which it always does). With some exceptions, when I see a company that's saddled with horrible old legacy codes that nobody can understand, often a large measure of this is paybacks (for not adequate funding and poor schedule planning) being the bitch that they are. How to do things the best way are well known, it's just that the best way is more expensive (in the short term, which is the only term business understands these days) and takes more time than the average business will wait. If the bottom line is get something done that sorta-kinda works as fast/cheap as possible, you get spaghetti code that even the guy/gal who developed it can't follow.

  • The nastiest project I ever took over was written in Perl by ten diferent programmers eah using diferent features of Perl

  • Bad management (Score:5, Insightful)

    by EmperorOfCanada ( 1332175 ) on Tuesday October 15, 2013 @06:01PM (#45137719)
    Often it is how a project is initially managed that results in an unmaintainable system. A few simple mistakes can send a project straight to hell from the very beginning. A simple one would be to allow the senior management to firehose new features at the project far faster than the developers can build them. Another would be to allow the wrong people to pick the core components. That is how bad databases/languages/operating systems can be chosen. Then you get the next layer of wrong when people simply code and architect badly.

    An example from my past was a company that I interviewed with (and was offered a job at) that was using Lotus notes to build a huge educational system. They had a PhD as the head of development and they were keeping the details secret until they made their offer. When they told me Lotus Notes I just laughed; I thought they were joking. I told them that building their system out of Lotus Notes was like building a car out of sand and white glue. At first you will quickly have the broad outline of a car but that as you start to work on the hard bits that you will never finish; Ever! A couple of years later the company imploded with no real product just a bunch of sales demos.

  • All Code is Terrible (Score:3, Funny)

    by TempleOS ( 3394245 ) on Tuesday October 15, 2013 @06:01PM (#45137723)
    You will never find good code in a project. All code is awful. Every programmer who looks at a project says it's shit.

    • Re: (Score:2)

      by Kaenneth ( 82978 )

      At first glace, Code is like an unassembled jigsaw puzzle.

      Without the reference picture (specs) it's much harder to figure out how it goes together.

      • For code, "Structure is the key to understanding." That is the missing thing from many pieces of documentation, an overview that gives the structure of the code. Specs are a good way to get that overview.

  • No such thing as 'unmaintainable' software (Score:3)

    by johnlcallaway ( 165670 ) on Tuesday October 15, 2013 @06:05PM (#45137749)
    Only lazy developers. I've worked on plenty of legacy software over the years that other people wouldn't touch, and the common thread was they were either too lazy or just not smart enough. It takes determination, patience, and a lot of detail to work on it. But it was all far from unmaintainable. And the end result was I was the one kept around during layoffs instead of the guys that said "I can't do it" (translation ... it's too hard for me.)

    OK .. no source code at all pretty much makes it difficult to maintain. Or not being sure if what is in use is the current code.

    As for the 'use a framework' .. what BS. Frameworks come and go. What is well used today can be a long forgotten, unsupported mess 5 years from now. Like NetBeans and Swing?? All those GUIs I wrote 5 years ago probably now fall into the 'unmaintainable' software category, even though all the code is actually there, and anyone that understands GUI programming at a basic level can still make modifications. It's not easy (i.e. not for the lazy), but it's possible. And how many times has a framework version made upgrading difficult because of extensive changes???

    It's OK to use Hibernate, ICE, and all that stuff that makes the job easier today, but learn how stuff actually works and only use it when necessary. It will make you more valuable in the long run, and the code more maintainable in the future. If I hear one more ignorant programmer tells me 'But Hibernate can write SQL that way even if it is more efficient' I'm going to shove a SQL manual up their ass and tell them to actually learn something.

    • Re: (Score:2)

      by ranton ( 36917 )

      Only lazy developers. I've worked on plenty of legacy software over the years that other people wouldn't touch, and the common thread was they were either too lazy or just not smart enough. It takes determination, patience, and a lot of detail to work on it. But it was all far from unmaintainable.

      When someone says that code is unmaintainable, they obviously don't mean that it is impossible to maintain. You can even disassemble binaries if absolutely necessary. If the effort to maintain the code exceeds the benefit of maintaining the code, it has effectively become unmaintainable in any practical sense.

      I do agree that maintaining code is more difficult than creating new code, and on top of that it is a less desirable task for most developers. I had to leave one company because they kept putting me pr

  • Support Debian's build system, keep Greg employed!

    That is all...

  • ... says the self-taught programmer... (Score:4, Insightful)

    by MasterOfGoingFaster ( 922862 ) on Tuesday October 15, 2013 @06:11PM (#45137799) Homepage

    Hey, glad I could keep you in business.

  • Not only will the code be a bug-ridden hodgepodge but the comments will be written in unintelligible English as well.

  • be sure to mess up SQL Server code as well.... (Score:4, Funny)

    by ClassicASP ( 1791116 ) on Tuesday October 15, 2013 @06:17PM (#45137847)
    Use long looong looooooooong stored procedures (20,000+ lines long) with lots of spaghetti SQL code and very little documentation. And never use identities and primary keys; instead just get the max ID number on the fly and use source code to get the next integer-up for the next record insertion to a given table. Make sure the table and field names have almost no relevance to the data they hold. use views liberally, and query one view on top of another view on top of another view on top of another view. If possible try and work something out to where there simply isn't any relational design to the database at all, and instead just use redundancy everywhere. Or, if you really want to be nasty, you could go the opposite route and figure out some kind of a mindbending rubix-cube-like puzzle where there is only one table with only 3 fields in the entire database, and nearly all table data of any sort is stored in one field in that table, and just rely on a myriad of SQL joins to emulate the behavior of relational database design.

  • He Didn't Delve Into Specifics (Score:5, Interesting)

    by Greyfox ( 87712 ) on Tuesday October 15, 2013 @06:36PM (#45137983) Homepage Journal
    How about "Set up a global int l and set it to 0, and a global int O and set it to 1. Or sometimes l, depending on what file you're in." This works better or worse, depending on your font. Or in C++, have every class inherit from every other class. I've seen this done.

    A couple times I've run across some jackhole who is in love with dynamic shit and who wants to check java object code into an SQL database and dynamically load it into a program. Nothing quite spells fun like wondering where the hell the code is branching to, and spending two days figuring out it's to an object in a database the code to which has been lost 4 years earlier.

    For a long time there in the '90's and a bit later, version control wasn't a normal thing. If you had to get management approval to set one up, that usually would start up the sinking feeling about that job sooner rather than later. Nothing quite like having to justify the addition of something they should have never written a line of code without in the first place. Nevermind trying to get overhead for writing unit tests. Assuming unit tests are even possible. For most of the projects I've run across, the coupling is so tight there's no way to get in and test discrete functionality of anything.

    For the guys not using version control, "Lose the source code" is a good one. You don't even have to be malicious about it (Though malice helps.) Just build the thing on your personal dev box, deploy the executables to production and never mention it when you leave. Bonus points if they walk you out during a layoff.

    "Don't set up a build system" is another good one. Gotta love those projects where you have to run a top-level build three times before it produces an executable!

    • Re: (Score:2)

      by sconeu ( 64226 )

      A buddy of mine inherited some code that was written ENTIRELY in #defines. Needless to say, it used a crapload of global variables.

      Another one that I inherited was a 5000 line source file... OK maybe that's a minor nuisance... BUT... the guy had written it both left AND right justified. He didn't believe in indenting, and all comments (and every line had one, including of the "add 1 to i" sort) were right justified.

      This was on an old Unix System III machine, so I wound up running it through csplit(1) to

      • Re: (Score:2)

        by Greyfox ( 87712 )
        Ah ctags and cscope are underrated. I used them a lot on a job where I had to read the C standard library and write tests for it. There's so much UNIX crap out there no one knows about. The only other place I've ever seen Lex and Yacc used were by the guy who wrote Awk for that UNIX system. I wrote a trivial Adobe PPD parser with them once, because why not? It didn't implement the full spec, just the bits of it I needed, and it'd pull the data out and build XML tables with it. Oh yeah and some jackhole aske

    • How about "Set up a global int l and set it to 0, and a global int O and set it to 1

      This reminds me of, "have a config file... and read in environment variables... in a library, not your main() function.". I've seen that first hand. Damn I hated that, since I tend to prefer config files over environment when practical. I just sort of forgot about the environment, not having used it for a long time. So I'm like, "Why doesn't this work on the other machine????" and somebody who knew about it is like, "t

      • Re: (Score:2)

        by Greyfox ( 87712 )
        I don't think I've ever seen a setjmp/longjmp in any C code I've ever maintained. I'm not sure a lot of C programmers even know it exists. Or setting signal handlers. I've written the only signal handlers I've ever seen in production C code. I had an AIX segv handler that tried to recover enough to print a stack dump before dying. It even worked a few times. You can pretty much bet if it forks, no one else will be able to follow any explanation you can give about how it works. Same thing goes for clone. Mos

    • Damn, I'm having a programmer PTSD moment here. I had to refactor an extensive set of code where the only named variables were "q" and "x". They didn't even have a consistent meaning across network boundaries. I had to methodically *break* every method and determine what the variables were *supposed to be* by the nature of the errors that it generated.

      If variables had been sanely named, it would have been a 2-3 day project. It took me 2 months to break each piece and refactor it into something sane and read

  • Terrible for the client, maybe.

    Terrible for the job security? Maybe not, under the right circumstances. Not everyone has lawyers to negotiate fat maintenance contracts.

    Doesn't make it right, but just saying.

  • Then Quit in a Huff When it's Only 2/3 Finished. (Score:3)

    by rueger ( 210566 ) on Tuesday October 15, 2013 @06:49PM (#45138077) Homepage
    At one organization I inherited a fund-raising database developed with much arrogance in Filemaker Pro. Except that the FMP "Guru" quit in a huff when it was only about 2/3 functional.

    Despite this the thing was used - with many, many crashes - for two years because it was the best thing that they had. And because Mr. Guru was a pal of half the staff.

    Did I mention that Mr. Guru also refused to hand over any of the logins that would allow someone to fix or administer this thing?

    We eventually wound up moving over to MS Access (GOD YUCK EVIL!), and massaging, fixing, cleaning, importing ten years of data, each year on a different format, file type, or with different fields. We actually managed to turn it into a reasonably useful fund raising tool. I mean, aside from the downside of using MS Access.

    Documentation? HA HA HA HA!
    Instead we had lots of on-screen buttons though that didn't do anything because he never quite got around to it.

  • Documentation is overrated (Score:3)

    by 140Mandak262Jamuna ( 970587 ) on Tuesday October 15, 2013 @07:22PM (#45138389) Journal
    Documentation goes out of synch with the code very quickly. The only thing worse than working on someone else's code without documentation is working on someone else's code with incorrect documentation. The problem is so old Dijkstra allegedly said, "Always debug code, not the comments".

    Oh, yeah someone will tell me I am doing documentation wrong. How come "you are not doing agile right" is a valid response but "you are not doing watefall right" is not?

    • Re: (Score:2)

      by edelbrp ( 62429 )

      I think you can also document in a way that is also up to date. For example, do you document the who/what/when/why for version commits? Sure. Do you put in-line comments in the code, e.g. "We need to revise the code below at some point to account for ABC"? I hope so. Do you have a stash of reference scripts/how-tos so you don't have to reinvent how to do semi-routine complex actions, like deployment? What about an active system to keep track of to-dos, priorities and who they are assigned to, what hap

  • The guys who wrote the software at my previous job were masters of it. I don't know all their secrets, but some of their finest work included: single character named global variables that were reused indiscriminately, code in stored in a database that was then evaluated inline that did things like changing variable values and declaring functions and other fun stuff, 500+ line functions that tried to do a little of everything, and liberal use of copy and paste.

  • Nothing wrong with writing from scratch (Score:3)

    by FuzzNugget ( 2840687 ) on Tuesday October 15, 2013 @07:53PM (#45138673)

    As long as you document, label and organize your code coherently and logically in a solid language, coding from scratch (or near scratch using libraries of your own) can be a good thing. It avoids pitfalls like vulnerabilities that affect common code bases, massive libraries that take friggin' *ages* to load on an i7 with a fast internet connection or relying on the developer(s) of library X to add feature Y ("sorry, we can't add that feature yet Mr. Client, it's uh ... because of complicated programming reasons, basically, we're relying on a third party and we don't know how to do it ourselves")

  • In other words, put the business unit in charge of your programming department.

  • Web and Embedded (Score:2, Informative)

    by Murdoch5 ( 1563847 )
    I work on a lot of web / embedded development and without a shadow of a doubt the worst aspects of most developers are:

    1) Comments - 98% of programmers can't write a decent comment.
    2) Object Oriented - This term usually means the code is structured like a child got let loose on the code and it can't be managed. Not always but usually if you hear object oriented design the code will be crap.
    3. Formatting - Don't use spaces, use tabs! I should be able to open your code on Linux, Mac or Windows in any ed
  • Come up with an excuse to write utility code that generates the production code and/or SQL. Then lose the utility code after the production code is up and running. Machine generated code is mostly incomprehensible, so even you won't be able to modify it without all sorts of subtle and not so subtle side-effects.
  • except like a lot of us developers I've seen most of this.(Just not the cutting edge language. The other stuff, I've seen that at my current job.) If he wanted to sum it up in one sentence it'd pretty much be "STOP FIGHTING YOUR TOOLS. THEY'RE SUPPOSED TO HELP YOU!"
  • pair programming & code reviews. fire, sue for sabotage. its not that far from admins who hide stuff and try to blackmail.

  • Don’t forget the documentation to match!

    HOWTO: write bad documentation that looks good [kuro5hin.org]

  • A reason in two parts, actually. One is job security; if you have so much institutional knowledge and your employer is too cheap to have redundancy for that knowledge (by hiring more people or spending man-hours sharing the knowledge with another employee), and that knowledge is mission-critical, you can get away with being all kinds of lazy/incompetent and you won't get fired. The CTO at our company has had his job for the last 15 years or so purely because he's the only one who knows how some of our stu

Slashdot Top Deals

No spitting on the Bus! Thank you, The Mgt.

Close