Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Ask Slashdot: How To Avoid Working With Awful Legacy Code? 360

kramer2718 writes "I have worked for about a decade as a software engineer. I am almost never hired to build new software from scratch, so my work satisfaction tends to be proportionate to quality of the legacy code I have to work with. Some legacy code has been good. Most of it is bad. I know a few questions to ask during an interview to determine the code quality: Are recent technologies used? Are there code review processes? Is TDD practiced? Even so, I still encounter terrible quality code. Does Slashdot have any advice for other questions to ask? Any other ways to find out code quality beforehand?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: How To Avoid Working With Awful Legacy Code?

Comments Filter:
  • any questions? (Score:5, Insightful)

    by yagu ( 721525 ) * <> on Tuesday October 23, 2012 @09:06PM (#41747101) Journal

    Not sure how those questions would indicate, you didn't specify. I could see some thinking "recent" technology means "good", but my personal experience provides little evidence to correlate "new technology" with good. I could even make a case that it's a red flag. (I worked on a disastrous project where by fiat we had to develop with .NET. Horrible)

    Code reviews? Meh. Some think they're doing code review, they're not... or they're horrible at it.

    I always ask what their turnover is, and why the position being filled was vacated. YMMV.

    • by Stiletto ( 12066 )

      Good advice, you could also ask if the engineers who originally wrote the code are still on the project and/or working at the company.

    • About the .NET i have to agree with you. This guy, he does not know what is the difference between property and method??? I know, i know, they are almost the same, just like the difference between idiot and genius :)
      • by murdocj ( 543661 )

        .Net has zero to do with good code vs bad code. .Net is a decent technology. You can produce good code with it, you can produce bad code with it. Personally, if someone displayed bias like that to me, I'd have serious questions about hiring them.

      • As far as the framework is concerned, they actually are the same thing and merely wrapped with syntactic sugar at the source level.

        Not that I'm implying they should be used the same way.

    • I overheard a conversation in a restaurant today that included "the kernel is a mix of custom C++ and JavaScript, it's really gnarly stuff..." if I heard that at a company I was considering working for, I think I'd run the opposite direction, quickly.
    • Re:any questions? (Score:5, Interesting)

      by bertok ( 226922 ) on Tuesday October 23, 2012 @10:33PM (#41747777)

      I'd disagree.

      Bad code is bad code whether it is old or new, but with new code you're much more likely to be able to use new tools, which are generally speaking vastly better than old tools.

      For example, with .NET you can use Visual Studio and with Java you can use IntelliJ IDEA. Both of them will give you powerful refactoring capabilities and help you navigate unfamiliar code. It's not just IDEs either, there are huge tool chains built around the new stuff, like static analysis and runtime capture such as IntelliTrace. Both of those do wonders for finding hidden issues in someone else's code. Even with C/C++ code you sometimes hit a wall with very old code bases that newer tools can't process.

      I once had to support an application written in Clipper for 16-bit DOS with modules written in a dialect of C so old that practically nothing could compile it. There is nothing out there to assist with that crap. You basically get a choice of your favourite text editor, and you should consider yourself lucky if you get syntax highlighting and stack traces after a crash!

      Meanwhile, I've solved issues in compiled binary code using Visual Studio. For example, I used the Concurrency Visualizer to figure out why iTunes hangs on my computer for hours. Turns out that one of its threads get stuck in a loop waiting for a synchronization primitive shared with the Bonjour service. I uninstalled Bonjour, and hey presto, problem solved! Solving issues like that in minutes instead of days or weeks is why I avoid anything written in languages other than Java or C# like the plague.

      • For example, with .NET you can use Visual Studio and with Java you can use IntelliJ IDEA. Both of them will give you powerful refactoring capabilities and help you navigate unfamiliar code.

        And both of those will let an amateur spit out craploads of poor code. Easy to use developer tools lower the bar for generating code quickly, not well written code.

        • I used to think this way, then grew up and realized that tools like IntelliJ and Eclipse are useful and have features that give me more insight into the code I'm working with and help me do my job more effectively. The tool is just a tool, and any tool will let you do things you're not supposed to do if there are not processes in place to prevent it. This is where the attitude of the business, coding conventions, code reviews, unit tests and other processes come into play.

          Put more simply- if this were con

      • Re:any questions? (Score:5, Insightful)

        by purpledinoz ( 573045 ) on Wednesday October 24, 2012 @02:10AM (#41749009)

        Bad code is bad code whether it is old or new

        And bad code is written in all languages. I would have to say, bad code is the norm. It is very difficult to maintain a clean code base. Code rots over time, and effort is required to keep it clean. The problem is, at least in my experience, a lot of software developers don't really understand data structures and patterns properly. There are even the few who cling on copying and pasting code all over the place. On top of that, management pushes time pressures on the developers.

      • For example, with .NET you can use Visual Studio and with Java you can use IntelliJ IDEA. Both of them will give you powerful refactoring capabilities and help you navigate unfamiliar code.

        That one sentence hits the most important nail on the head for me. Many people subconsciously tend towards considering all code they did not create themselves to be bad code. That is not to say bad code does not exist but there is a string preference that most of us have for things being done in the manner we would do it. Once you get beyond this you often realise that the code is not so bad after all or that we have written code just as bad ourselves in order to get something done.

        If you are forced into ta

    • Re:any questions? (Score:5, Interesting)

      by Darinbob ( 1142669 ) on Wednesday October 24, 2012 @12:38AM (#41748585)

      I've been few places where code reviews are thorough or mandatory. Sure it's tried now and then but eventually it slacks off and the code reviews are sort of perfunctory, mostly about finding flaws in the code rather than cross training or finding design improvements, and the review comments are acknowledged but aren't necessarily acted upon (yes, he implemented his own function instead of using an existing one, but we need to ship soon and can't stop just because Bob the Pedant says so).

      On the other hand there must be a lot of people who do come from such places, because you meet them and they either express amazing feigned surprise, or they become condescending, or they try to start up a grass roots movement to completely change the company. You meet some people who are just absolutely in love with formal software engineering but who seem to have no real love for programming or engineering apart from that.

      The ultimate problem is that pragmatism will trump idealism. You have to ship the code, you have to meet the deadlines, a few bugs won't matter if there are workarounds, you're paid to add features or fix bugs but not to redesign things that already work, etc.

      As far as legacy code. I've been programming professionally for around 30 years. All of my jobs have dealt with legacy code, every last one. That includes graduate school and summer jobs. Sure, some jobs had some original programs written from scratch, but no job was ever purely that way. Of the legacy code, none of it would match my own personal standards. That's not because I'm better than everyone, but because my standards aren't the same as everyone else's.

      So I would think that someone just is not going to be able to escape this. Most software is written under the gun. Avoid start ups, they always have to write code as fast as possible and get it barely working before the funding runs out. Avoid long standing corporations as they've code code decades old and processes and politics that get in the way of quality code. Avoid being a contractor as you'll have to change styles and designs and processes every few months. However if you avoid everywhere that has bad legacy code you will also avoid some of the more interesting and fun jobs that exist. Even if you do find something that is a great code base you may not recognize it as good because it's style and design might be radically different from what you prefer (ie, I think unix v6 code is awful, but it had very different goals and was written under a really restrictive environment).

      What matters more than anything really is comments and documentation. No matter how good the code is it will be useless without that.

    • by gorzek ( 647352 )

      It doesn't seem like most of the replies actually address the submitter's question. Here are the things I look for:

      * Does the company use any kind of source control management system? If they say "no" or don't know what that is, RUN AWAY.
      * What development methodology do they use? Agile, waterfall, RUP, something else? If they don't know, RUN AWAY.
      * How is requirement specification done? If they can't explain this in even a little detail, RUN AWAY.
      * How is release management done? Are there automated builds

  • It's not the code (Score:5, Insightful)

    by Anonymous Coward on Tuesday October 23, 2012 @09:08PM (#41747115)

    It's you. Stop being such a prick. The next guy hired to clean up your mess probably says the same things about you.

    • It's not the code

      Actually it is. But the language / framework plays a fundamental role in helping developers to write maintainable code. I've always been a C / C++ lover. However when it comes to sharing the code among many mixed-level programmers on a big non-system project, I had to admit - that was not easy - that C / C++ are not the best candidates. Of course some projects do require a low level language, like C, or even assembly (eg operating systems), but - this is another subject but it matters - these projects do no

      • by murdocj ( 543661 )

        I worked at one company for many years where all the code was C on a variety of UNIX platforms. We used our common libraries, code was shared, life was good. C is a fine candidate for code sharing, as long as people are paying attention, using lint, etc. Yes, C allows you to play fast & loose, so you need to be a bit experienced and disciplined, but that helps in any development environment.

  • Ask the questions you are talking about. Phrase them as ways of showing your background in those areas. Ask what kind of standards they follow, so as to see if you know them. Ask if they are maintaining legacy code, to show you have experience. If the answers are too much for you, move on.
  • one question (Score:5, Insightful)

    by j00r0m4nc3r ( 959816 ) on Tuesday October 23, 2012 @09:12PM (#41747153)
    "Do you have a code sample I can look at?"
    • by SuperMooCow ( 2739821 ) on Tuesday October 23, 2012 @09:24PM (#41747257)

      10 print "Yes we do."
      20 print "You're looking at it."
      30 end

    • Re:one question (Score:5, Insightful)

      by dubbreak ( 623656 ) on Tuesday October 23, 2012 @09:40PM (#41747371)

      Heck, just ask to look at the codebase. It's not like you'll be able to pick up any trade secrets in 30 minutes. Better yet have someone that currently works there go through some of the general ideas and show you the problem areas. A good employer should be willing to do this.

      Another option is to talk to existing employees. At my previous place of employment we'd have a Q&A with at least a few devs that work on the project the prospective candidate will be working on. They know how good or bad the software is. What about bug/defect tracking? How far buried are they in bugs, or are they actually adding useful new features rather than treading water in a sea of shit code?

      I've done the treading water in someone else's codebase. It's no fun. In that instance it was fixable but management wasn't willing to put sufficient resources (people/time) into solving the issues. At the same time management was frustrated that "soo much time is spent on maintenance". Well yeah, it's shit broken code with no unit tests written, no test harness of any sort, object oriented code written by two engineers that had never written anything object oriented, were new to the language it was coded in and had never worked on a software project of its magnitude. Oh, and the one remaining employee that wrote the original code is not willing to fix anything himself or even discuss the issues (he's CTO, so he's above that). A company's key product that generates the majority of their $10mil revenue, but they are only willing to put a couple devs on it (while the CEO puts as much staff as he can into his revenue sucking pet project). That kind of stuff is good to know going into a project.
      • Re:one question (Score:5, Insightful)

        by Nerdfest ( 867930 ) on Tuesday October 23, 2012 @09:53PM (#41747455)

        It's too bad too, as the time spent cleaning up code to improve readability, maintainability,and frequently performance generally pay off quite quickly if you're still adding features or tracking down bugs. I also find that cleaning up legacy code by extracting the intentions and implementing it cleanly can be very fulfilling work, right up there with developing something new. Done in a pairing environment, it's a great way too teach junior programmers what *not* to do and why.

        • I completely agree. There is a lot of opportunity in fixing code. I did get to work on some modules, but nothing like what was needed. I also got to work with some co-ops (uni students) I was in charge of adding testing support (good, but not valuable enough to management to put a full time employee on it) and to work on a replacement for one of the modules (which has yet to be integrated, a year later, even though it bests the original implementation by a long shot). Ultimately we learned a lot from each
    • by Dan667 ( 564390 )

      for (var never_use_this=0;never_use_this>100;never_use_this++) {
      print "oh, no\n";
    • The premise here is that working with crappy legacy code is somehow not fulfilling. I have worked in jobs with reasonably efficient and well commented legacy code that was boring to maintain because it mostly involved brain-dead incremental changes. I've also worked with complete shit storms that were incredibly satisfying to re-factor and clean up (ex VB "developer" that wrote an entire java application in one method with 10,000 lines of "if then" nesting, I'm looking at you).

      Sometimes the worst sample cod

  • by dougmc ( 70836 ) <> on Tuesday October 23, 2012 @09:13PM (#41747155) Homepage

    Work for a startup. Any place that has been around for any significant length of time is likely to have legacy code.

    Realistically, a startup could very well have legacy code too, but it's likely to have much less if it has any. In effect, you'll be the one making the legacy code for those who come after you (or yourself, if you stick around that long.)

    Not sure why legacy code is such a problem though. If it works and works well, why replace it? And if it doesn't work, it should have already been replaced.

    • If it works and works well, why replace it? And if it doesn't work, it should have already been replaced.

      Sure, it may work well and it may be well written. But its cheaper to tack new features on the side. It starts off being cheaper for the first few rounds, until the quality of the code suffers, then there is never enough time or budget to fix/rewrite it.

      I'm working on 12 year old Java code at the moment. It was all "blah blah J2EE blah blah EJB blah blah MVC blah blah MDD" when it was built in 1999. It now has several controller classes over 6000 lines a piece. Multi-hundred line methods. Its horrible, bu

      • Of course the company that treats its software products is still profitable, so there's no motivation or reason to change anything. Add a few features quick and "cheap" which sells a few more units and continues cruising on.

        Very few companies are concerned with software maintainability. Yes, it saves money long run, but the types of people that tend to end up running companies that make software are short sited business types that are concerned about turning as big a profit as they can the next quart to y
      • by Kjella ( 173770 )

        Sure, it may work well and it may be well written. But its cheaper to tack new features on the side. It starts off being cheaper for the first few rounds, until the quality of the code suffers, then there is never enough time or budget to fix/rewrite it.

        Not to mention risk, because there's code that'll break. For example let's take a conflict I once had where the database guidelines said table name + "Id" was the primary key, while the other column names would be defined by an external standard. Works great with lots of legacy code written until the standard defines a field $fooId in table $foo and we have two conflicting definitions. Simple case of namespace collision, trivial to solve with a prefix right? Unless you realize you can either break all the c

    • by hawguy ( 1600213 ) on Tuesday October 23, 2012 @09:39PM (#41747363)

      Work for a startup. Any place that has been around for any significant length of time is likely to have legacy code.

      I've found that in many cases, the code written at a startup is even worse that legacy code - it was written to get the product out the door as quickly as possible, with the belief that it will be rearchitected and rewritten "in the next release".

    • And if it doesn't work, it should have already been replaced.

      Yep. Should have. Wasn't though. You know, budgets and such.

    • by phantomfive ( 622387 ) on Tuesday October 23, 2012 @09:47PM (#41747425) Journal
      I think his complaint wasn't that it doesn't work, it's that it's hard to work with and a pain to understand.

      And this is unfortunately true of almost all code, no matter how well written. Coding is hard, and if you have 100,000 lines of code, it's going to take a while to figure it out.
    • You seem to have missed the key adjective "awful" in the title/question.

    • by sjames ( 1099 )

      Coulda woulda and shoulda and a couple bucks will buy you a cup of coffee. Sure the awful legacy code SHOULD have been replaced, but was it? Meanwhile, there are various criteria for 'works'. The most commonly used is does it do what we need done right this moment. The more important for a developer is can it easily be modified to do what needs doing tomorrow. Code that meets the first criterion could easily be in use for many years until suddenly what needs doing changes.

      Meanwhile, the question wasn't abou

  • One warning sign: (Score:5, Insightful)

    by Sheetrock ( 152993 ) on Tuesday October 23, 2012 @09:16PM (#41747183) Homepage Journal
    If the company relied on one programmer to handle everything, beware.
    • Re:One warning sign: (Score:4, Interesting)

      by Anonymous Coward on Wednesday October 24, 2012 @12:13AM (#41748463)

      Been there. Caused that. Was the lead programmer.

      Left comments in the source to the future programmer, with apologies in some spots, explanations in others. Dates, meetings, sometimes pasted snippets of emails.

      Yeah, it's bad practice in code, but it was the only way to make sense of some of the "OMFG, WHY?"

      Or... "Why is this variable getting read twice in a row, and why are you counting on it being different?!"

      Sometimes even I couldn't keep track of it. My network-processing architecture diagram was 16 by 10 feet when I left.

      You know, it's kind of crazy when I could have visitor patterns, mixins, factories, singletons, proxies ... all the proper paradigms. Spliced in beside same code that has gotos, and mixed ssh connections with fixed keys over system pipes hitting remote databases.... json embedded in XML, socket libraries rewriting data on-the-wire through a streaming tcpdump with a filter, and re-sending via netcat after editing it....

      What can I say -- I was young, and I was good enough to be incredibly, horribly dangerous. I was the guy who got the previous lead programmer's job -- he was slow, wrote mediocre code, did a bad job testing, and couldn't sysadmin for shit.

      It took him weeks to write simple tcp services -- worse than that, he'd do it by hand instead of reusing the hundreds of libraries out there.

      I could pop up new servers in minutes or hours. Extend our protocol stack on the fly. Script releases and deployments to swap two versions of the code in and out with an advanced queueing system that ran several versions of our framework simultaneously small corp wouldn't pay for vmware...

      Of course I got his job.

      I brought in version control, ticketing systems, releases, and all types of unit tests back when their software shop was releasing php servers with version control on the client computer....

      main_system.php.2012_10_13_v4 ...

      But what mattered ... and why they kept me was that when they asked for something, and I gave them the quotes, they would /always/ choose "quick and dirty, fix it later" -- and I gave them that. Awful, horrible hacks done up in a day or two. No respect for myself or my time. No respect for my future sanity. Hell, half the time I'd overestimate the projects intentionally and clean stuff up on the sly. What I could anyway.... which would usually only be the tiniest standalone portions and modules.

      Fastforward six years -- they never once paid for "clean it up" save the one time I had to quote a month to change a single dynamically constructed image. After that, there were serious talks about cleaning stuff up, but it never happened.

      Tests fell out of maintenance, programmers couldn't deploy, build, or run a test suite. The system stack was so convoluted it would take a shellscript that only ran on my desktop four hours just to set stuff up...

      Every single one of those problems management bought and paid for. Not because as the only programmer I didn't know better -- but because they chose it.

      And yet, I just found out that the boss's old friend has become the director of dev two years after I left. The same guy who had set up the database years before I'd started. The same DBA that turned off foreign keys and integrity checks in the database. The same DBA that setup a raid 0 system. The same DBA who advised scaling the system and faster web apps through XML and XSLT.

      I'm sure his expensive consultants are getting their share of WTF's in my code if they can even unwind it.

      Each and every one of those WTFs was for a legitimate business purpose. That purpose being --I needed to sleep, eat, shit, and get my job done.

      When you call a programmer to fix something at 3 in the morning, 7 AM, or to release something by 4 in the afternoon -- there's a cost.

      If you get it done fast, most of us aren't good enough to design it well, write it, te

  • Work for a startup that has no legacy code.

    • But they only pay in "monopoly money" ... The bank don't take that.

      Seriously, if working with old code is that much of a problem, you should have moved from coding to architect by now. Improve your project management skills and use that to sell yourself as "modernizing" your new employer's code base. Although when older alanguages and paragidms are used, it's often because you've got interconnected parts of legacy systems... Like moving from RPG III to RPG ILE, there are interconnected pieces... And the b

  • by stanlyb ( 1839382 ) on Tuesday October 23, 2012 @09:23PM (#41747245)
    Do you use CVS? Any kind of? No?.....
  • by Grail ( 18233 ) on Tuesday October 23, 2012 @09:30PM (#41747293) Journal

    How about you fix you?

    Rather than trying to avoid horrible legacy code, admit that the world is built out of horrible legacy code. Get hold of Martin Fowler, “Refactoring” and Michael C Feathers, “Working Effectively with Legacy Code” then develop your skills at working with legacy code to turn it into better code.

    After all, that new beautiful code that you wrote for that last job is now someone else's horrible legacy code.

    It is a matter of perception & expectation management.

    • After all, that new beautiful code that you wrote for that last job is now someone else's horrible legacy code.

      This. The best thing you can do is to make the code you write amazing. Not amazingly clever, but amazingly clean, robust, and re-usable, and documented as if you were going to show it to the world and suddenly have thousands of people dependent on your ability to do so.

  • The key is to find a place where you can work unseen to create your own horrible code with the hopes that in time you too will become the stuff of legend.

  • No one likes dealing with legacy code. Any given developer has had to sit down and wade through code that's some combination of poorly designed, undocumented, non-functional, over-engineered, slow, tedious, failure prone and in all other ways apparently designed only to make your life some sort of hell of bleeding eyeballs and migraines - and that's just the code they wrote 3 months ago. Other people's code is worse.

    Having written code for nearly 2 decades now, what I can tell you is this: It doesn't mat

    • No one likes dealing with legacy code.

      I do and I've known one other programmer who was really good at dealing with legacy code.

      I don't find puzzle-type games interesting, but some really crappy code, useless variable names that change across functions, no comments and poor structure and you have a challenge you can dig your teeth into.

      If there's an understanding of how crappy and critical the code is, you can stay immersed for a long as it takes. You can become the long-haired hippie in the sandals who people make way for in the halls (a

  • Charge by the Hour (Score:4, Insightful)

    by dmomo ( 256005 ) on Tuesday October 23, 2012 @09:36PM (#41747343)

    Other people's bad code keeps me in business. If half of this crap were written well, no one would need me. Don't avoid bad code, dive in, clean it up where sensible, and move stuff forward.

  • Does it matter? (Score:4, Insightful)

    by kiwimate ( 458274 ) on Tuesday October 23, 2012 @09:38PM (#41747351) Journal

    I'm not sure where the story title "How To Avoid Working With Awful Legacy Code" came from, but it already sounds bad. Let's go on.

    I have worked for about a decade as a software engineer.

    So you've got enough miles under your belt to know more or less what you're doing, without being amazing. Ten years isn't very long for a discipline like programming, unless you do very basic stuff and never have to worry about optimization, for instance.

    Some legacy code has been good. Most of it is bad.

    Yeah? Really? See my comment above. By the way, the guy who comes after you probably says the same thing about most of your code. He's probably at least half right, too.

    my work satisfaction tends to be proportionate to quality of the legacy code I have to work with

    Perhaps I'm being unfair, but you do come across as a bit of a prima donna. And again, if you've only been doing this for ten years, then you probably aren't justified in being so snotty.

    My work satisfaction tends to be proportionate to how much I get paid and how nice the other people are. If it was a party and fun all the time, it wouldn't be called "work". Yes, I enjoy my job. Yes, I know people will doubtless respond with "life is too short to work at a job you hate". But getting paid a small fortune can make a job an awful lot more fun. Look, I've worked for complete jerks, and sometimes you just have to walk away. I've done it. And then, sometimes, you just have to suck it up and be a grown-up.

    If you can afford to turn your nose up at work that doesn't meet some random enjoyment factor criterion, then you're in a very fortunate position, and I hope you are grateful for how lucky you are. If you are in that kind of position, then you probably don't really need to be asking this question. Pick and choose as you want.

    And if the code is really that bad, look at it as a challenge to your abilities, gleefully rub your hands together as you contemplate an extended contract and some security, and put together a spreadsheet to show how much money you're about to rake in. You never know, it might work and make the job a little bit more appealing, even if the code quality isn't up to your superior standards.

    Are recent technologies used? Are there code review processes? Is TDD practiced? Even so, I still encounter terrible quality code.

    That's because there are a lot of mediocre coders, just like there are a lot of mediocre sys admins or plumbers or chefs. Putting formality around someone doesn't make him a better coder.

    Does Slashdot have any advice for other questions to ask?

    How much does the job pay?
    How long is the job?
    Is it time and materials, or fixed price?
    What if the contract takes significantly longer than expected?
    Will you give me a recommendation if I do a really good job?

    What are you trying to get out of this question? Presumably you are going to add the factors together to determine if the legacy code is "good" or "bad". Then what? If it's kind of half-baked, in your estimation, you're going to turn down the gig? That's probably going to annoy the contracting company if you keep doing it. "What didn't you like about this job offer? The hourly rate was good, it was a short drive, it met these other criteria...". "Yeah, but the code wasn't up to my standards. Now, kindly hand me another glass of champagne and do try a bit harder next time, peon."

    Good luck with that.

  • Get an MBA (Score:5, Insightful)

    by Greyfox ( 87712 ) on Tuesday October 23, 2012 @09:51PM (#41747443) Homepage Journal
    Because as a software engineer you're going to have to deal with horrible legacy code. Some of it might even be yours.

    The worse the code is, the more latitude you have to improve it. For most non-trivial projects, you should never replace something that's already there and working. The first instinct of the new programmer is that "this is horrible and I could do better writing from scratch." Sure, except that there are decades of business logic in that code, no requirements and things that look like side effects may actually be important. Assuming you ever get done, it will take much longer than incrementally improving the current system, take MUCH longer to deliver useful results and probably be less functional and as much of a mess as the existing system.

    If instead you make a list of things that need to be improved about the current code base to make it less atrocious, prioritize it (I find by number of weekend phone calls any given feature's implementation would eliminate works great) and start working through them, you can make some serious quality changes in just two or three months. Improve error handling, refactor areas where code was cut-and-paste, set it up so a crash doesn't completely shut down production, and start organizing objects into sensible trees. By the time you're done you may have nearly completely rewritten the application, but kept it running while doing so and delivered immediate quality improvements to its users. It's every bit as much fun and challenging as writing new code.

    • Yea, if you're a good cook, cooking for another professional Sheff may be fun... but there's something to be said about serving lobster to someone who's never had anything but day old McDonalds before. My place is FILLED with horrible horrible code... some of it goes back to the 70s. There's nothing else like hearing someone complain about some horrible process that's been around for years because X program sucks and can't do certain rudimentary things... and it makes them have to come in on the weekend at
      • by Greyfox ( 87712 )
        I'm not saying leave things the way they are, just because you leave that old code in place while you improve it. Take a project I did back in 2000, perfect example. It had been written by a couple of guys who kind of knew C and their focus was more getting it to work than the design. Whole thing crashed a lot, and did batch processing on an entire directory of files. Of course, it it crashed while processing a file, it would restart, crash on the same file, and we'd get called on the weekend.

        So first thi

  • All Code Is Shit (Score:4, Interesting)

    by TexVex ( 669445 ) on Tuesday October 23, 2012 @10:01PM (#41747507)
    Look, if you just want to be able to only write fresh stuff, you're useless. Your new code will become "legacy" code next month. Requirements are likely to change, or at least be refined. This is because project managers are not prescient and nobody ever really understands the real requirements until an alpha gets put into the hands of the end user.

    It won't be long before you're going to have to go back and deal with the turds you yourself are crapping out. You might not think they're turds, but they are. That's because you're not prescient either. And if you spend too much of your energy striving for the most elegant, perfect code, then you're also constipated.

    You're a better engineer if you can effectively reverse engineer other people's turds and polish them up a bit. If you can somehow find within yourself the ability to feel a bit of pride in addition to the disgust of dealing with other people's crappy code, you'll be happier in your lot.

    You haven't made your bones as a programmer until you've spent five minutes cursing the idiocy of a programmer that came before you, whose crappy code you are having to fix, and then you look up the revision history to see who the offender is and discover that it was YOU.
  • It could be that you suck, and people think you're not good enough to write stuff from scratch.

    It could be that nobody in your organization writes stuff from scratch.

    It could be that you're so good at fixing other people's crap code that you're too valuable to work on new stuff.

    In any case, you need to either leave or start agitating.

  • by tchall ( 1146319 ) on Tuesday October 23, 2012 @10:14PM (#41747617)
    You COULD ask to see their "Life Cycle Management" documentation folder(s)

    IMHO... If they don't understand the question you're probably going to want more money...

    One of my former students called me years back with the announcement that the brief (two hours or less) "Life Cycle Management" addendum I'd made to the Systems Development/CASE class I was teaching got him a promotion to a senior analyst position... That was the one area that none of the other candidates could discuss...

    Apparently it wasn't something that everyone was teaching as part of the process of developing maintainable code and data structures...

    My NOT being a full time programmer OR teacher might affected how strongly I've felt it necessary to include that subject.. but whenever I've had to go back to a former project... having a fully documented system has kept me from the necessity of reinventing the wheel...

  • Are you taking jobs where you have to channel the previous developers and write code indistinguishable from them? do your jobs involve just transcribing someone else's crappy code char for char like some 14th century monk? Or, do you get to write code? I've supported plenty of legacy code. In all occasions that involves me, writing code. Optimizing, bug fixing, refactoring, adding new features (i don't know what else you could possibly do to legacy code) all involve writing code. So man up and write good co
  • Does the Architect own a tanto? Has been required to use it?

  • by Mabhatter ( 126906 ) on Tuesday October 23, 2012 @10:26PM (#41747727)

    This request is like applying for a job being a plumber that doesn't work with shit. Sure, there are plumbers that only do new construction and never have to clean up a stinking mess of broken shit pipes.... Good luck landing such a gig.

  • ... is to be an employee with a single-digit employee number in a start-up company. Beyond that, you will have to deal with the Big Ball of Mud []. Deal with it.
  • I haven't been in the industry for ten years, or even near it, and I know that unless I'm being hired specifically to create something new I'm going to be working with existing code. And I've worked for some very, very small companies where the code I'm working on has been written by people who've been short on time and resources. It's looked like total butt. It's been slapped together with bubble gum and bailing wire, and I've done my best to leave it better than I found it for the poor sap who comes behin

  • by istartedi ( 132515 ) on Tuesday October 23, 2012 @10:34PM (#41747781) Journal

    There's a decent chance he really is better than the previous guy. Just how do you propose that he "fix himself"? Sometimes there really is lously code. I'm always reminded of the story about the guy who left code where all the variable names were things like ass_function(), butt_fucking_variable(), stinking_anus; I'm not kidding. Totally non-descriptive, every permutation on posterior. Look me straight in the eye and tell me that ain't bad code, and that he should "just get used to it".

    I'm also surprised nobody has gotten modded up with an answer that's obvious to me: In-place re-write, preferably in collaboration with several other programmers, according to best practices. Just go through, replace the worst functions, write plenty of tests, rinse, lather, repeat until you have a performant, robust and maintainable codebase.

    • Would upvote if I had modpoints.

      The problem is, if the management would be semi-competent OP wouldn't have asked this question. The most probable thing to happen is management gets scared of the cost of the rewrite but keeps demanding new features.

  • by wtansill ( 576643 ) on Tuesday October 23, 2012 @10:54PM (#41747963)
    Certainly don't become trapped with a dying language, but do not arbitrarily rule out working with legacy code. Think of it as a challenge instead:

    1) You always learn something even if it's negative (don't do that!!!)
    2) You gain insight into another's thought process. Sometimes that's scary, but again, you learn something - a new perspective, perhaps.
    3) Really bad code can let you pull off the impossible - improving performance, reducing resource utilization, etc. You can become the "go to" person, with the job security and good performance evals that come with it.

    Give it a shot before turning up your nose.
  • Awful code (Score:4, Funny)

    by WaffleMonster ( 969671 ) on Tuesday October 23, 2012 @11:49PM (#41748323)

    Don't whine.

    Don't use TDD.

    Don't assume use of modern language features yield better code. []

  • Relish it (Score:4, Insightful)

    by countach ( 534280 ) on Wednesday October 24, 2012 @02:51AM (#41749171)

    I've worked with awful code many times. Early in my career it drove me crazy. After doing it a lot, I'm used to it. Frankly, a lot of the jobs maintaining the crap are easy jobs, and there is a certain skill and satisfaction in dealing with it. Plus, nobody else wants to do it, so you have a job for life and can name your price. My suggestion is don't avoid it, learn to love it. Embrace it.

  • The two things I ask about are a design document and an automated QA system.

    Don Knuth's Literate Programming is the very best way to write a design document, but even much less than that is better than nothing. The worst case is having nothing but uncommented code. I once had a programmer tell me that he didn't need to comment his code: the names of the variables provided enough information. He was coding in Macro-10, a language that limited variable names to six characters.

    The automated QA system is crucial for maintenance. You need a test for every feature described in the documentation, plus one for every bug fixed, to make sure it doesn't come back. The QA system must be automated or management will insist you skip running it because a bug fix has to ship "right now", and you don't have two days to run the manual tests. Having a QA system that can be run after each build is so important that it should be the first thing you write when taking over legacy code. If you aren't allowed to write it because fixing bugs or adding features is more important, pass on the project.

    When I started programming I didn't have to deal with legacy code, even though I was at a large university. That was because when I started programming there was no legacy code: we wrote everything ourselves. A friend of mine wrote the original recursive binary to decimal conversion subroutine for the DEC PDP-1, and was astonished when it worked the first time. The world has moved on, however, and the situation I was in no longer exists.

The rich get rich, and the poor get poorer. The haves get more, the have-nots die.