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

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?"

Comments

any questions?

[yagu]

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.

Re:any questions?

[Stiletto]

If I were someone who is considering working for your company, I think the information is very relevant. If a company looks like they have something to hide about their turnover rate or about why the position is vacant, I would consider that a major red flag and have serious reservations about accepting the job.

As an interviewee, that's pretty much a standard question on my list: Who was in this previous position and why did they leave? If answered honestly it is very helpful.

Re:any questions?

[Anonymous Coward]

It tells you about the company's culture and is definitely the interviewee's business. If the interviewee had six jobs in the last 2 years, would you hire them? Why can't the interviewee make a similar inquiry into the company's practices?

Re:any questions?

[Anonymous Coward]

If you don't think your interviewees should be interested in your turnover rate, I wouldn't want to work for you.

Re:any questions?

[erp_consultant]

I disagree. I think that is a perfectly valid question. If the interviewer is unwilling or unable to answer then that in itself is the answer. A vacant position may be vacant for a variety of reasons - perfectly valid reasons such as company expansion, retirement, etc. If it turns out that there is high turnover then there is clearly a problem - noncompetitive salary, poor working conditions, incompetent management, etc.

Now having said all that, a lot of the coding work out there is mop up work. It would be nice if everything I worked on was original code but that's just not the case. I motivate myself in different ways by taking pride in improving the code beyond the way I found it. Sometimes poor code is not the fault of the developer before you. It could be due to imprecise and changing requirements. It could be due to poor technical leadership. It could be due to poor testing. Maybe the guy just did the best he could with the time he had.

In the end it doesn't matter whose fault it is. You were hired to fix it so fix it.

Re:any questions?

[SolarStorm]

I guess I would never work for you. I view the 3 month probation as a probation for both parties. Not only are you evaluating the employee, but I am evaluating the company. If we both like each other its a marriage. If one of us has issue we shake hands, part company and go for a beer. Currently we are in a situation where talented developers are in short supply. I am actually interested in a person who is asking questions about our work environment. It shows that they are looking for a place to stay, instead of the next pay check. Honesty in an interview, by both parties, is what will create a successful work relationship. Mistrust and deceit will invoke the probation clause.

Re:any questions?

[19thNervousBreakdown]

Really? It's a pretty pertinent question, if your average employee lasts a year, you can expect the job you're interviewing to last that long. Knowing that is fairly important if you want to make any sort of mid-term economic plans. And it's not like you don't get turnabout as an employer, in fact it's volunteered, right there on my resume, and it's at least as valid of a metric for who's going to be a good employer. You want to keep it private? That's fine, but I'm going to look on that about the same as you'd look at an applicant who wants to keep their work history private.

Same thing for why the position is vacant. Heck, it's practically the first words out of any interviewer's mouth, "Why are you leaving/did you leave your previous job?" How is this not an equally valid question for a potential employee?

You seem to be confused about something. Applicant is not a synonym for supplicant. I'm not coming begging, I'm coming negotiating a trade, and questions directly related to what I'm going to get in kind for my work shouldn't be off the table. Maybe you can find people who are willing to put up with your attitude, but they're going to be people with no other choice, and there's a reason they don't have a choice. Honestly though, I doubt you've ever hired anyone and are just trolling, but I do want to make sure someone young and naive who isn't in the workforce yet doesn't think stuff like this is normal. It's not. I've asked those exact questions at all but my first job, and never been looked at funny for it.

Re:any questions?

[astrodoom]

Your tone conveys an attitude that your employees shouldn't be interested in how the company is run, that's a huge red flag from my experience.
It's not prima donna to inquire about the history of the position. You should want employees who think they can succeed where someone else has failed.
I don't understand employers who think company operations are of no business to their employees. I may work for you, but I'm putting my livelihood and that of my family in your hands. You don't have to justify all your decisions, but some explanation of the direction and plan goes a long way.

Re:any questions?

[Anonymous Coward]

>If answered honestly it is very helpful.

Anyone unwilling to share their turnover numbers would probably be more than happy to lie through their teeth to you.

Re:any questions?

[hawguy]

I would never hire someone who questioned turnover rates and asked why the position was vacant. It is, quite frankly, none of the interviewee's business and conveys a kind of prima donna attitude.

As a hiring manager, I like when a candidate picks up on things like that and asks about the high turnover rate - it shows that he is looking at more than just the technical side of the job and is interested in the entire work environment. I want to make sure he's a good fit and feels comfortable working in the environment, otherwise if he's there for a couple months, runs into the same frustrations as the other programmers that left, he'll just be contributing to the turnover.

I have nothing to hide and no reason to hide it -- it's not like he won't find out about it if he accepts the job. If the high turnover came from a recent management change and change in direction of the company, I want him to know about it from the outset. If the high turnover came because half the development team got together and formed their own, competing company, I also want him to know about it.

Re:any questions?

[erp_consultant]

"Applicant is not a synonym for supplicant" - Brilliant. What the parent poster here doesn't seem to realize is that good developers are not looking for a job. They already have one. And if you want to snare one of them you had better be able to answer their questions. Don't try to bullshit them, it won't work. If a prospective employer refused to answer those questions for me then the interview would be over right then and there.

Re:any questions?

[Rockoon]

I would never hire someone who questioned turnover rates and asked why the position was vacant.

Spoken like someone thats only taken a job that they had to take. Contrary to popular belief, the best time to look for a new job is when you are secure in your current one, as you dont have to take whatever your prospective future employer tries to ram down your throat.

If that prospective future employer is the kind that "will never hire someone who questioned turnover rates," then they only get the people that need the job, not the people that want the job.

Re:any questions?

[lightknight]

Indeed. I have noticed that they get offended when you ask the important, but prickly questions, yet have no qualms doing the same for yourself.

Like it or not, you're two beings trying to find out if you're right for each other. As such, it's better to ask those questions upfront, rather than spend a year of your life, only to find out the answer is disagreeable.

Re:any questions?

[lightknight]

Or when you have a few year's salary in your savings account. The "I can wait until the earth ices over" approach to finding a job tends to yield better results.

Re:any questions?

[lightknight]

Because apparently politics has infiltrated the recruiting process, and endeavours to bring the kind of changes that has seen Greece on the edge of a revolution.

Personally, I'd prefer not to work for a company where you had to constantly be on your toes about saying the wrong thing, and where advancement was determined by your place in the ass-kidding line. My own research of the industry ( as well as others) says that no company that engages in this kind of behaviour tends to last more than a decade. If anything, it's a sign that the company is doing poorly, and has the wrong people in the wrong places.

The founders of a company were interested in getting shit done / making a cool profit / achieving something great. When you replace that culture with one of perpetual fear, and a focus on inter-office politics, chances are your founders have left, and the new guys are trying to find a way to 'spin-off' the cash-making components in a sweet deal, so they can slowly cut, cut, and cut, until the company goes bankrupt.

That may make me unemployable, but it's true, and I stand by it.

Re:any questions?

[czth]

You can always ask, and they can always refuse. I do ask about why the position needs filling, but I haven't asked about turnover rates, partly because I didn't think to (true confessions: I just recently read Peopleware), partly because it seemed like something they wouldn't tell anyway. (The last place I interviewed at wouldn't tell me how many developers they had; I've worked there about a year and it's a fine place to work, but that was strange and I understand it comes from higher up. Fortunately, it's not a symptom of Terrible Things.) I wouldn't be surprised that a place wouldn't want to reveal turnover rates to someone that might not end up working there, or could even, if they were interviewing in a particular narrow field, end up working for a competitor.

It's a bit like employers asking about salary history: I don't get offended if they ask, but I politely refuse to reveal it. It is certainly a huge benefit to them to know it if they can get it. I mentioned to a co-worker that I never tell companies salary history, and he said something like, "You can do that?" Yes. Yes you can.

Re:any questions?

[MangoCats]

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?

[bertok]

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.

Re:any questions?

[MangoCats]

Have you forgotten the golden rule? They have the gold, you want the gold, they make the rules.

Re:any questions?

[Anonymous Coward]

Require triple what the job is worth if they get pissy with you in an interview. This is a brief example of one I felt was being run by a slimeball. This position was for high level hardware repair and this was after a lot of sputtering about questions asking about available test equipment, schematics, source code and other documentation. i.e they did not want to release this or provide decent test equipment.

The company was one that had shipped all it's manufacturing overseas, all it's engineering to India and laid off everyone except their 'core incompetency' and then stuffed a small room temps who would fix their 'manufacturing partners' fuckups.

E: "How much backlog is there?"
A: "And how is that relevant?"
E: "You've promised temp to perm and I'd like to see if you're going to work me until the workload is down then dismiss me in under 5 years."
A: "Gasp sputter gasp."
E: "Yea I thought so. My price is triple the offered rate. I'm worth it for a short term project."
A: "Gasp sputter gasp"
E: "Yea I thought so."

You need to find this out in the beginning. Working for asshats sucks.

Re:any questions?

[SplashMyBandit]

They can't 'spin hay into gold' without people to do it for them (since often the person hiring has a different set of skills than you provide). If you are skilled they need you at least as much as you need them.

Plus, with regard to the 'gold' thing, apart from behemoths, most companies will not last long without productive people (some companies only have enough to make payroll for a few months).

I also believe that there are more companies out there than truly skilled individuals. It is easier for a good individual to get a good job than for a good company to fill all positions with good individuals. That means there is a 'balance of power' in hiring that is not tilted too much either way.

Re:any questions?

[fluffy99]

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.

Re:any questions?

[phantomfive]

It is certainly a huge benefit to them to know it if they can get it.

More importantly, it can be a huge detriment to yourself.

Re:any questions?

[ohnocitizen]

Very true, but how they respond might offer you some insight. Perhaps they are caught off guard, or are a bit *too* smooth. If you walk out of an interview with a gut feeling a company is not going to treat you right, and you are fortunate enough to have other options - listen to that feeling. I've learned that lesson the hard way.

Re:any questions?

[erp_consultant]

That's a good question. Personally I would tell the prospective employee the truth. If you lie they will figure it out eventually and they will leave for another job. The cycle of turnover continues. By telling them, yes we've had 'X' amount of turnover, you are at least starting off on the right foot by telling them the truth. Own up to it and tell them what you're doing to fix it. I would rather the prospective employee decide right then and there that they are not up to the challenge and not accept the job than accept it under false pretenses.

Would I lose a few good candidates? Probably. If a company has high turnover they have got bigger problems than the person sitting across from you at the interview table. A good manager is going to get to the root of the problem and fix it so that the company is a compelling place to work. When you've done that you no longer have to ask people to work for you. They want to work for you.

Re:any questions?

[czth]

No. The libertarian position is that a job is a transaction between a buyer and seller; see for example Tom Mullen's article "What is a Job?":

The employer is the buyer and the employee the seller, selling his services to the employer for a mutually agreed upon price. This is a voluntary transaction for both parties, just like the buying and selling of lawn mowers or breakfast cereal. The buyer offers to purchase services at the price he can afford and the seller decides whether to accept those terms or not. Both parties are free to decide not to go through with the sale at any time. Unless a specific term of employment has been agreed to, both parties are also free to cease doing business at any time. The employee can quit the job (refuse to continue selling the service) and the employer can terminate employment (refuse to continue purchasing the service).

Supply and demand play a role in the price and benefits a person will be able to negotiate, certainly. But the hyperbole about machine guns does nobody any good. The fundamental libertarian principles is the non-aggression principle (non-initiation, not pacifism). Neither forcing people to work, violence against competitors/workers, or opposition to unions (just against being compelled or forbidden to join one) are libertarian principles.

Re:any questions?

[Darinbob]

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.

Re:any questions?

[bomb_number_20]

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 construction, I'd say it's not the hammer's fault the house was poorly built.

Re:any questions?

[purpledinoz]

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.

Re:any questions?

[Ash Vince]

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 taking a horrible shortcut due to a looming deadline or to work round an issue somewhere else in the system you probably do not consider that to be bad code but a pair of new eyes looking at it for the first time would, especially as the big somewhere else you were having to work round may well have been fixed by then so you hack no longer has a reason to exist anyway.

But then again, I am currently employed maintaining a legacy ASP system that runs on SunOne ASP (ex Chillisoft) so I know a fair bit about truly bad code. Thankfully we are throwing it in the bin and replacing it with Zend Framework and PHP. This is far from a perfect platform but it is far better than what I am used to.

Re:any questions?

[man_of_mr_e]

I shouldn't bother asking (because when people make these general statements, they never back them up when queried)...

But what Libraries in Java are you referring to that you are forced to buy in .net?

Re:any questions?

[Ash Vince]

People who think that programming is just a 9-5 job where you punch in, turn on your brain, do work, punch out, turn off your brain, are the bane of this industry. They'd be just as happy washing cars for 18 hours a day, and aren't necessarily interested in solving an annoying problem once and for all. They're just interested in a job, any job, so long as it's doing rote work and getting paid an hourly wage. No passion for technology.

I think that is a little overstated to be honest.

I have worked with truly amazing developers who had that mindset to be honest, they had spent years learning their craft and simply felt they had nothing to prove any more. They turned up on time everyday, did the hours asked of them but no more, took absolute pride in their work but also did not overly object if they had to do something in code they did not like the idea of.

This last part is very important, sometimes as developers we are required to implement things we do not like, but we just have to get on with it. We can explain why we think it is bad form to do it in that manner, but if the alternative takes 10 times as long then commercially it may make sense. The obsessives you put on such a pedestal often throw such a hissy fit when asked to do this it can make them a pain in the arse. They might be right from the perspective of a pure academic looking at the code, but there are some times other priorities.

Re:any questions?

[Anonymous Coward]

My brother who works in construction does the same thing. He calls it the "fuck off quote". Most people turn you down and you walk away with a smile. A few accept but you're on triple rates so you do the job, however shitty, with a smile.

Re:any questions?

[FictionPimp]

It depends on your history. If you spent a long time at previous positions, then after a few months at the current position you look for work, your answer to the new employer has a nice history of facts behind it.

"As you can see, I typically stay at a company for the long term. Unfortunately, the work environment at my current employer was not the environment I was led to believe during the interview process. Had I know that I would have never left my previous employer. Which is why I am currently searching for a company that is a better fit for my talents."

Re:any questions?

[gorzek]

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? Is there a defined process for deployment, upgrades, patches, etc.? If not, this is a red flag, at the least.
* Are developers required to write unit tests? If not, this is another red flag.
* What is the defect rate per 100 or 1000 hours of development time? Do they have any available metrics on whether their software quality is improving or not? If they aren't even tracking this, again, that is a red flag.

If their development department is disorganized, you will be able to tell from the above questions. If that is the case, odds are there is little or no discipline in terms of actual coding, as well. A common answer to some of the questions above is, "we'd like to do those things, but we just don't have time." Again, this means they do not understand the total cost of quality. You must invest in good quality practices up front or you will never get out of the "firefighting" mode. If you go into a company that's lacking the things described above, you can expect chaos, little attention to good development practices, poor software quality, unpredictable release schedules, and probably long hours to make up for all of it.

It's not that these problems can't be fixed--I've made a career out of doing that--but if you, as a developer, just want to work on interesting products and get them out the door, then shaping up a dysfunctional development organization is probably not what you are signing up for.

Re:any questions?

[ircmaxell]

Actually, this touches on an interesting point.

Everyone thinks that high turnover is a bad sign. And it is. But very few people think of what extremely low turnover means.

If a company has 40% turnover each year, that's a sign that something's wrong in the organization. There's a reason that people are leaving so quickly. If the average tenure is only 14 months, that's not a good sign. But on the flip side, it could be that same 40% that keeps turning over. Imagine that they have a small team, and are trying to grow it. High turnover in the growth area could mean that they just haven't found the right fit. (in this case, the average tenure could be 3 or 4 years, even though the turnover appears so high). That could indicate the quality of applicants, or that their interviewing process sucks. So turnover by itself is hard to understand. But turnover with average tenure tells a more complete picture.

Now, if turnover is under 1%, that could also be a scary sign. It could indicate that employees are never growing. That they are stagnating in their position and can't move on because their skills have gone rusty. That could also be a huge negative.

I personally look for moderate turnover. Somewhere between 5% and 20%. Signs that there's some new blood in the team, keeping complacency in check. It also may indicate that people are actually growing in their positions. Which is an awesome thing to look for.

So turnover by itself is a useless metric. It may indicate towards a good or bad thing. But the more important factor is not what the turnover is, but why it is what it is. Unfortunately, that's not something that's usually going to be easy to understand in an interview. But luckily, it should be pretty clear in the first few weeks of employment...

Re:any questions?

[GameboyRMH]

People who think that programming is just a 9-5 job where you punch in, turn on your brain, do work, punch out, turn off your brain, are the bane of this industry. They'd be just as happy washing cars for 18 hours a day, and aren't necessarily interested in solving an annoying problem once and for all. They're just interested in a job, any job, so long as it's doing rote work and getting paid an hourly wage. No passion

Haha sucker. I'm way past that shit. Your long hours, hard work and dedication will never be rewarded, you're just letting them rip you off harder.

Re:any questions?

[erp_consultant]

"On my current project, the release date is so tight that we have to do it the quick and dirty way" - I see this all the time.

Project managers always seem to be pushing to get the code done by a specific date - whether it's really done or not. Their job is to crack the whip to get tasks completed by a specific date so corner cutting is inevitable. What's worse is that in my experience almost none of them have ever done any real programming so they have no idea how complex it can be.

PM: "How long will it take to do programming task 'A'?"
Me: "That's impossible to say. There are too many dependencies and most of them are out of my control."
PM: "Well, I need to put a date on the project plan. Take a guess"
Me: "Why don't we just put a calendar on the wall and throw darts at it. That would be just as accurate."

And so it goes until I finally give in and give the PM some ridiculous date just to get him or her off my back. So when I find myself somewhere having to fix someones crappy code there is a very good chance that they just had this conversation with a PM. Then I just smile and get on with the task :-)

Re:any questions?

[man_of_mr_e]

There's no such thing as a Linq driver for Oracle. Linq is not a database technology. It's a *DATA* technology.

You need a database technology for Linq to do database work, such as Linq to Sql or Linq to Entities.

I assume you mean you needed an Entity Framework driver for Oracle, and Oracle does provide one... However it's only been available for about 2 years.

http://www.oracle.com/technetwork/topics/dotnet/index-085163.html

Before that, Microsoft had a "sample" that you could compile to access Oracle through EF. But, it's really not MS's job to provide drivers for every database out there, and technically, wouldn't you want a driver from Oracle rather than whatever Microsoft thinks is good enough?

It's not the code

[Anonymous Coward]

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

Re:It's not the code

[hcs_$reboot]

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 not fit most of the nowadays programmers. Non-system bigger projects do need to rely on a language that require programmers to follow stricter rules (than C for instance). Java is, based on my experience, a relevant code-sharing candidate, thanks to the files structure (packaging, class per file) and the language itself (stricter types, no operator overriding, not allowing some of the C fancy acrobatics - that I like personally but another programmer may not like / understand, ...).

Simple, ask directly

[jfdavis668]

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

[j00r0m4nc3r]

"Do you have a code sample I can look at?"

Re:one question

[SuperMooCow]

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

Re:one question

[dubbreak]

This.

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

[Nerdfest]

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.

Re:one question

[Max Littlemore]

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 code is an indicator of a fun job so the next question should probably be, "Are you open to me re-factoring this to make it more manageable?". Of course each to their own and YMMV...

You want to avoid legacy code?

[dougmc]

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.

Re:You want to avoid legacy code?

[hawguy]

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".

Re:You want to avoid legacy code?

[phantomfive]

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.

One warning sign:

[Sheetrock]

If the company relied on one programmer to handle everything, beware.

Re:One warning sign:

[Anonymous Coward]

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_v5
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

My favorite question

[stanlyb]

Do you use CVS? Any kind of? No?.....

Legacy Code is not the issue here

[Grail]

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.

Charge by the Hour

[dmomo]

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.

Re:Charge by the Hour

[jmerlin]

Now if only this could get you on Dirty Jobs.

Does it matter?

[kiwimate]

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.

Re:Careful with that axe, eugene.

[hawguy]

If you are going for a position where legacy code is a reality - I wouldn't hire you if you asked a question that depicted yourself to be either rather irritated by or incapable of dealing with legacy code. Positive attitude in interview, whine all you want when you get the job.

It really depends on whether the employer considers the code to be "bad", anyway. My guess is many would not fess up to the code being poor.

But by all means, you should ask all of those questions and go ahead and let it be known to your future employer that you don't want to touch any crusty old legacy code - it gives him more knowledge about you and makes it easier to make the correct hiring decision. It might hurt you, it could even help you, but no matter what, it will help you to land in the kind of job you want.

Re:no

[Samantha Wright]

Oh code quality? Just from looking at the tags I thought this was a story about cod equality. Damn those herrings.

Get an MBA

[Greyfox]

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.

Re:Get an MBA

[Charliemopps]

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 the end of every month and have 10 people work overtime to do the process... Then you go back to your desk and 2hrs later tell them they don't have to do that anymore. I had a woman kiss my cheek before. And I am not a handsome man... so that's saying something.

Re:Get an MBA

[Greyfox]

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 thing I do is write a spooler for it that reads the directory and then launches the program with a file, then monitors the child process. If it crashed or its exit code was non-zero, it'd move the file off to a "Crashed" directory for investigation on Monday. That was pretty much the end of getting called on the weekend.

Next thing I did was go through and replace all the strcpys with bounded strncpys copies and fix a few double frees. That cut the number of crashes to almost zero. Then I set about fixing up the start code to make it easier to hook new parsers into the tool and added some tivoli performance monitors. Any new functionality was actually designed in and managed by the team.

When we were done, it was still undeniably the same application, but the original authors would not have recognized it. We didn't touch a few components that generally worked very well, fixed the things that annoyed us the most, were not afraid to redesign entire chunks of the code in one go, and generally improved the quality to the point where it was very easy to keep running. Of all the things I've done in my career, I think I'm most proud of what we accomplished there. It was a good team, good management and good customers providing good requirements. You almost never see all three of these things in the same place at once.

Right now I'm working on doing the same thing on a legacy application that someone wrote in perl, then someone else wrote a front end to in Ruby, that has some Java classes and shell scripts glommed in there just to make things interesting. My tentative plan is to slowly replace individual functional components with C++ until nothing is left but a bunch of stand-alone C++ applications and and a little glue holding them all together. Since I'm the only person doing this, I estimate it will take me into the mid 2020s get to that point. It's pretty interesting work, some of the most challenging programming I've ever seen, and I have to integrate with systems which I may or may not be able to look at the source code for. So if something breaks over there, I mostly just have to guess what's causing it. By the time I'm done, I'll have designed my way around a lot of problems. That's every bit as much fun as building something new, in my book.

All Code Is Shit

[TexVex]

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.

How To Avoid Working With Awful Legacy Code?

[tchall]

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...

.

Like a plumber that doesn't work with S41t

[Mabhatter]

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.

I'm surprised at some of the responses

[istartedi]

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.

The Joel Test

[czth]

Ask them how well they score on The Joel Test (see also this post with some suggested updates). This won't necessarily teach you about how much legacy code they have floating around, but it's a useful barometer. Part of what favorably impressed me about the place I am working now is that the VP I talked to (1) knew what it was, and (2) knew how they scored.

Ask how refactoring is viewed, if time is scheduled for specific cleanups of known "code rot"; if at least it is possible to include refactoring of relevant code as part of building new features. A too loose policy (which I've never seen but I suppose is possible) could be as bad as not budgeting for it at all; either can produce "legacy" quality code. Intelligent refactoring is part of the cost of maintenance (code "taxes", even).

Don't avoid legacy code

[wtansill]

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

[WaffleMonster]

Don't whine.

Don't use TDD.

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

http://xkcd.com/610/

Relish it

[countach]

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.

design document and automated QA system

[John_Sauter]

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.