×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

Soulskill posted about a year and a half ago | from the flex-your-burger-flipping-skills dept.

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

360 comments

any questions? (4, Insightful)

yagu (721525) | about a year and a half ago | (#41747101)

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? (0, Interesting)

Anonymous Coward | about a year and a half ago | (#41747161)

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.

Re:any questions? (5, Insightful)

Stiletto (12066) | about a year and a half ago | (#41747199)

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? (2, Insightful)

Anonymous Coward | about a year and a half ago | (#41747333)

>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? (5, Insightful)

Anonymous Coward | about a year and a half ago | (#41747247)

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? (0)

Anonymous Coward | about a year and a half ago | (#41747683)

Because you're just a lowly pleb. Kiss hiss boots, bitch, thanking him for seeing it within his grace to offer you a chance to be his drone!

Re:any questions? (3, Insightful)

Anonymous Coward | about a year and a half ago | (#41747251)

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? (5, Insightful)

lightknight (213164) | about a year and a half ago | (#41747651)

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? (5, Insightful)

erp_consultant (2614861) | about a year and a half ago | (#41747297)

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? (0)

Anonymous Coward | about a year and a half ago | (#41747591)

In my experience, it has been bad management every time.

I am not going to say the manager was bad, but who he listened to was trying to sell some sort of magical management panacea for productivity - while the instructor of these courses had never had any experience actually doing the stuff covered in the coursework.

I have seen entire companies collapse after having management attend these training seminars. Managers came out so "blessed with insight" that no-one could work with them or please them.

If a boss knows another way is better - it helps a lot if he can demonstrate/teach this to his underlings personally, An edict is not sufficient training, and will lead to much frustration which will result is terribly sloppy project execution.

If the boss doesn't know what he's doing, why is he the boss?

Re:any questions? (5, Insightful)

SolarStorm (991940) | about a year and a half ago | (#41747305)

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? (5, Insightful)

19thNervousBreakdown (768619) | about a year and a half ago | (#41747307)

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? (4, Informative)

erp_consultant (2614861) | about a year and a half ago | (#41747405)

"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? (5, Interesting)

astrodoom (1396409) | about a year and a half ago | (#41747317)

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? (5, Interesting)

hawguy (1600213) | about a year and a half ago | (#41747349)

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? (4, Insightful)

Rockoon (1252108) | about a year and a half ago | (#41747463)

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? (4, Insightful)

lightknight (213164) | about a year and a half ago | (#41747677)

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? (1)

sjames (1099) | about a year and a half ago | (#41747499)

The employer will look at the candidate's employment history, why shouldn't he look back?

Re:any questions? (0)

Anonymous Coward | about a year and a half ago | (#41747567)

If I ask why your position has high turnover or why it is vacant, and you tell me the truth, and I decide not to take the job because of it, then we both just saved a lot of time (and money) by not having yet another turnover situation.

The question doesn't convey any sort of attitude as you claim. Jobs are a big commitment for most people. It merely conveys that the person has a concern for their future, and it is certainly the interviewee's business.

Re:any questions? (1)

lightknight (213164) | about a year and a half ago | (#41747579)

75% of the the coding industry is filled with prima donnas. Good luck changing that.

The same kind of obsession that gives you a prima donna gives you one the one guy who is willing to spend 72 hours without sleep to fix that one, major, annoying bug before launch, and justifiably is treated like the princess because of that.

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.

Re:any questions? (0, Insightful)

Anonymous Coward | about a year and a half ago | (#41747663)

Better to have a well rested team that won't create that one major, annoying bug.

You can have passion for something without being obsessed and controlled by it.

Re:any questions? (0)

Anonymous Coward | about a year and a half ago | (#41747661)

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.

That's okay. Based on what you just spewed out, I would never hire you either. It is, quite frankly, beyond arrogant.

Re:any questions? (1)

Stiletto (12066) | about a year and a half ago | (#41747211)

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.

Re:any questions? (1)

stanlyb (1839382) | about a year and a half ago | (#41747269)

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 :)

Re:any questions? (1)

murdocj (543661) | about a year and a half ago | (#41747577)

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

Re:any questions? (0)

Anonymous Coward | about a year and a half ago | (#41747669)

Disastrous because you had to develop with .NET? Why?

It's not the code (5, Insightful)

Anonymous Coward | about a year and a half ago | (#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.

How To Avoid Working With Awful Legacy Code? (1)

Anonymous Coward | about a year and a half ago | (#41747263)

Don't use Windows. Duh

Re:It's not the code (2)

hcs_$reboot (1536101) | about a year and a half ago | (#41747389)

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

Re:It's not the code (1)

murdocj (543661) | about a year and a half ago | (#41747605)

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.

no (1)

xdcx (2711191) | about a year and a half ago | (#41747129)

no. you cant determine the code quality until you look at the source code, unless you are talking with another programme

Re:no (0)

Anonymous Coward | about a year and a half ago | (#41747319)

Speak for yourself. I make serious scratch working on an open source project. Yeah, the code is awful, but I wrote it. It's intentional. Nobody else wants to touch it. Job security baby!

Simple, ask directly (2)

jfdavis668 (1414919) | about a year and a half ago | (#41747139)

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.

Interviews are a two-way process (0)

Anonymous Coward | about a year and a half ago | (#41747149)

You're interviewing them as much as they're interviewing you. Ask to sign an NDA so you can examine their code base to see if you actually want to work there.

one question (4, Insightful)

j00r0m4nc3r (959816) | about a year and a half ago | (#41747153)

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

Re:one question (4, Funny)

SuperMooCow (2739821) | about a year and a half ago | (#41747257)

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

Re:one question (0)

Anonymous Coward | about a year and a half ago | (#41747633)

Or even worse:

10 print "Region.......Product......Sum(Sales)"
20 print "Southeast....Rayban XL....1344531.22"
30 print "(23012 records read on 12 partitions)"
40 end

Re:one question (5, Insightful)

dubbreak (623656) | about a year and a half ago | (#41747371)

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 (5, Insightful)

Nerdfest (867930) | about a year and a half ago | (#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.

Re:one question (1)

Dan667 (564390) | about a year and a half ago | (#41747609)

sure

for (var never_use_this=0;never_use_this>100;never_use_this++) {
print "oh, no\n";
}

You want to avoid legacy code? (4, Insightful)

dougmc (70836) | about a year and a half ago | (#41747155)

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? (1)

viperidaenz (2515578) | about a year and a half ago | (#41747225)

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, but I can see it used to be not bad. It was the 12 years of butchering that turned it into the steaming pile it is now. Probably doesn't help I don't work for a software company they just hire a bunch of contractors to do the work when ever they need changes.

Re:You want to avoid legacy code? (1)

dubbreak (623656) | about a year and a half ago | (#41747483)

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 year (exec bonuses are at stake!). In reality doing things "right" will mean less cost the entire life of the product. Yes, initial profits will be delayed, but over the life profits will be higher due to lower maintenance costs (and maintenance is the majority of a software's life cycle).

Your example is a little different as it sounds as though it was on the right track initially, but someone up top push some quick new features. Which works for the first while, but then coupling starts making any additions down the road hell. Of course they pay the price to do those additions (poorly) because rework costs even more than a feature that takes 50-100% longer than it should to implement. And it gets worse and worse, and eventually the product is dropped because it costs too much to do anything to or you've burned too much customer good will with your buggy POS. But hey, it was a good run and they made profit and got bonuses and have this shiny new product to drive into the ground.

Re:You want to avoid legacy code? (5, Insightful)

hawguy (1600213) | about a year and a half ago | (#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".

Re:You want to avoid legacy code? (1)

dubbreak (623656) | about a year and a half ago | (#41747393)

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

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

Re:You want to avoid legacy code? (3, Insightful)

phantomfive (622387) | about a year and a half ago | (#41747425)

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.

Re:You want to avoid legacy code? (1)

dcollins (135727) | about a year and a half ago | (#41747509)

You seem to have missed the key adjective "awful" in the title/question.

Re:You want to avoid legacy code? (0)

Anonymous Coward | about a year and a half ago | (#41747637)

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

At my company we have plenty of legacy code that works well. We also have plenty of legacy code that does not work well, that has not been replaced, and people work in the program every single day.

Maybe you just don't notice all of the bad code that hasn't been replaced, because your too busy staring at the unicorns outside your office?? :P

Careful with that axe, eugene. (0)

Anonymous Coward | about a year and a half ago | (#41747163)

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.

Re:Careful with that axe, eugene. (4, Insightful)

hawguy (1600213) | about a year and a half ago | (#41747381)

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.

Ask the dev interviewing you what they think? (0)

Anonymous Coward | about a year and a half ago | (#41747171)

Ask the dev interviewing you what they think about their code base? Maybe ask them outright if their code sucks? I do that.

Re:Ask the dev interviewing you what they think? (0)

Anonymous Coward | about a year and a half ago | (#41747495)

"I do that"

I assume you ask that question all the time. Which is why you don't have a job.

Developer Tenure (1)

Anonymous Coward | about a year and a half ago | (#41747175)

That's what I would go after... if you only have the "old guys" then the environment is usually not something I would enjoy - too much inbreeding of ideas, no new technologies and such... Not necessarily bad code - just outdated. If there are only junior people there, then its a mess, nobody has the needed experience or a vision of a better future.
All decent code bases I ever touched in a commercial environment had a few older guys that stuck with the product cause its stable, easy work and a few newer guys because its a easy to learn, guided environment...

One warning sign: (5, Insightful)

Sheetrock (152993) | about a year and a half ago | (#41747183)

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

Re:One warning sign: (0)

Anonymous Coward | about a year and a half ago | (#41747219)

Oh darn that is ME!!!

To my replacement: I am so sorry. I did not know

Re:One warning sign: (1)

Anonymous Coward | about a year and a half ago | (#41747239)

What if the one guy was someone like Dennis Ritchie?

Re:One warning sign: (1)

busyqth (2566075) | about a year and a half ago | (#41747421)

What if the one guy was someone like Dennis Ritchie?

1) I question whether you have ever read Dennis Ritchie's code. 2) Dennis Ritchie didn't work alone. If he had, he wouldn't have done the things he did.

Re:One warning sign: (1)

metallic (469828) | about a year and a half ago | (#41747465)

Doesn't matter, odds are that the programmer was being dragged in so many different directions at once that consistently focusing on code quality is pretty much an impossibility. And I'm speaking from experience.

Simple answer (1)

stox (131684) | about a year and a half ago | (#41747197)

Work for a startup that has no legacy code.

Re:Simple answer (1)

Mabhatter (126906) | about a year and a half ago | (#41747673)

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 boss needs a tax formula recalculated, not a full refresh, as much as the boss may want it too.

Suck it up, princess (0)

Anonymous Coward | about a year and a half ago | (#41747201)

With the economy being the way it is, you're being picky about the quality of the code you work with? Either you are good enough that you can pick and choose your jobs or the world is going to give you a reality check right in the nutsack.

Remeber, half of coders are below the mean (and more than half are below the average).

New Technologies are not often nice code. (0)

Anonymous Coward | about a year and a half ago | (#41747203)

Recent technologies doesn't mean that it is good code.

f2c is great code but it is not new technology.

Some of the best stuff is just plain ANSI or even K&R C

(Some of the functional languages are good if they are using them they probably know what they are doing)

Not an option (0)

Anonymous Coward | about a year and a half ago | (#41747207)

If you are a professional programmer, you will deal with legacy code, that's part of the job. It takes getting used to. The difference between a hobbyist programmer and a professional is no longer technical skill, since even hobbyists can learn amazing and difficult things from places like Wikipedia. The difference is that the professional is comfortable and capable of working in group projects and dealing with mountains of shitty legacy code. It really comes down to that.

It's part of the job (0)

Anonymous Coward | about a year and a half ago | (#41747231)

Seriously, your own code becomes "legacy code" at about the point it isn't fresh in your head any more. Maybe that's as recently as 1 month after you write it, maybe it's longer, but if you're going to be a professional programmer, you need to accept the fact that maintaining legacy code is part of the job.

my two cents. (0)

Anonymous Coward | about a year and a half ago | (#41747243)

there are some red flags, first one is you are the only one working at this particular Project and no one else around knows anything about the internals, another red flag is if it is written in a framework like struts, JavaBeans, or a very old websphere, another warning is if the Project is not under any source control system, or if it is driven by a cmmi process.

your questions are not very good since code review is not important, TDD often drives awful code, more important is that the codebase have a sane build process, good versioning and is simplistic in its design, too many layers and the thing spirals down quickly.

Fnially is very important you can test your code in your own machine, very often you see that the software can't be quickly tested and depends on systems/databases not available in your work environment.

Depends on company culture (1)

uberbrodt (1064400) | about a year and a half ago | (#41747253)

If they have a culture where the developers are allowed to focus on code quality, then if it's "bad code" (as subjective as that term is) you'll have a shot at fixing it. Code quality is a result of developer experience and the required development pace; the worst situation you can be in is where 100% of engineering time is spent on feature development and bug fixes, with no time allotted for maintenance work.

But like a poster above said, if you really are just sick of legacy code, work for a startup; that's what I did.

you gets what you puts out (0)

Anonymous Coward | about a year and a half ago | (#41747259)

If you are getting consistent compiler warnings about deprecated calls then considering a rewrite is in order. That is provided you still have the original code and are not just reusing old binaries. Legacy binaries without access to the source is a part of the problem. Sometimes the old saw "if it ain't broke don't fix it" can come back to byte you.

Become thine enemy (1)

Anonymous Coward | about a year and a half ago | (#41747267)

Find a job where you get to write code from scratch. Amidst all the changing requirements, last-minute fixes, impossible deadlines, and lip-service paid to best practices, you'll quickly meet the enemy, and he is you.

Turn the question into a plan. (0)

Anonymous Coward | about a year and a half ago | (#41747271)

You may come off as sounding like not a team player or whiny. Probably the old code was written or maintained by the interviewer, you do not want to offend anyone if you are serious about the job.

Sound intelligent and turn your questions about what you are working with and trying to turn it into a plan of how you can hit the ground running and keep doing the job in question for years. Usually if you are hiring you dont want someone who is going to sit there and whine about legacy code for years.

You can justify your questions about how old and how much time it takes to maintain by saying that you are thinking of how to make things better by seeing where things are at right now. Draw on past experiences and quantify what you have achieved, eg.. 20% less support tickets or x hours less a month doing ..

Just dont sound like a whining know it all... /shrugs.

Stay with a company and prove yourself (1)

Anonymous Coward | about a year and a half ago | (#41747281)

I have been coding for almost 20 years. I've been hiring people for a good part of that time.

Most employers reward their tenured developers with the new projects. The reasons are not always perfect, but, the simple answer is that they cut there teeth on legacy code, they understand the requirements, and they should know the pitfalls to avoid. If you are moving around a lot, you will find it more difficult to work on new stuff.

That being said, most companies want to put their best person on the job. If you have tenure but never showed initiative, dedication and team work attitude, you will usually be looked upon as not interesting to the leaders who are trying to show management that they have e right people to carry out a new project. After all, a new project is a risk to management that you are mitigating with proven people.

There are times you bring exactly the right experience to a company and you get fast tracked. New teams sometimes need entry level type devs to fill in to write he muck code. Or you get into a startup. These tend to be why people get the fun stuff right off. But most likely, they want you to prove yourself and understand the problem before you get the reward of new development.

Work for start ups (0)

Anonymous Coward | about a year and a half ago | (#41747283)

Duh.

Legacy Code is not the issue here (5, Insightful)

Grail (18233) | about a year and a half ago | (#41747293)

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.

Re:Legacy Code is not the issue here (0)

Anonymous Coward | about a year and a half ago | (#41747447)

+1.

I'm a year into my first contracting role, after a decade at startups, and (while I had a good idea what I was getting into) I was still shocked at the quality of the code.

However, I realised the opportunity that a poorly written code-base on an important legacy platform represented. A year in, and this platform is now stable (where crashes were the norm), performs all major operations in less than half the time, uses a quarter of the resources, many further improvements have been identified and planned, the team is re-energised... and I look like a hero, for doing little more than bringing my outside experience to bear.

Re:Legacy Code is not the issue here (1)

PhrostyMcByte (589271) | about a year and a half ago | (#41747557)

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.

Questions to Ask (0)

Anonymous Coward | about a year and a half ago | (#41747299)

"Define Technical Debt."

"Define 'refactor'."

"How much time does your team spend on technical debt?"

"Tell me about a few times where the main focus for the product changed direction?"

"Tell me about a major refactoring your team recently did."

No (0)

Anonymous Coward | about a year and a half ago | (#41747313)

It doesn't matter where you go, start-up, long-time corp, self-employeed. If you wrote it and moved on to another project or maybe even a different part of the same project when you get back to it, it's legacy code. You think you wrote the perfect chunk of code but when you get back to in a month with a new perspective you'll be wondering "why'd I write it this way?"

The only code that is not legacy code is the code that has yet to be written.

doing it wrong buddy (1)

LodCrappo (705968) | about a year and a half ago | (#41747327)

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.

In a word: Nope. (1)

quietwalker (969769) | about a year and a half ago | (#41747339)

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 matter much. We all want to live in a land of beautiful code - if we didn't, we wouldn't get so upset when we see horrible code. However, the end game is: does it work? Yes, you want to wipe it out and start from scratch, and yes, it'll be a joy to work with after that (until the next guy shows up), and yes, it takes forever to make a change, and yes there's no unit tests, and yes it's loaded with bad hacks - but for a business the real questions are "does it work?".

If the answer is 'yes', you're fighting an uphill battle to correct it. If you are lucky enough to be able to put a cost on it - time or dollars - that could be saved by refactoring, then perhaps you have the ammo required, but if you can't give a realistic metrics-backed analysis of it, then there's no business need to fix it.

Think about that for a bit: The need to fix it is not based on how broken you perceive it to be, but on entirely separate measures of no worth to you that require discrete and specific values.

        (Besides, if you spent that time analyzing, now you know the system pretty well, so you're the new expert!)

More realistically, there's always going to be a next, new thing that needs to be built. If you spend all your time fixing problems that aren't 'too' broken, you'll miss all the chances you'll have to work on the new stuff, where you don't have to work on legacy code at all!

So the advice to you is what all good programmers should hate to hear, but know in their hearts to be true: Spend as little effort on it as possible, and move on, until it becomes a large enough problem that it requires attention, not just deserves it.

Oh - and if you have a good dev manager, ignore all that. Tell him it needs to be refactored, let him work out the priorities and schedules, and you're set. Also, while you're visiting Fantasy Island, tell Ricardo Montalban that he was awesome in Star Trek II.

Re:In a word: Nope. (0)

Anonymous Coward | about a year and a half ago | (#41747459)

the answer to "does it work" for a piece of software with no unit tests is never "yes", unless someone is bullshitting you. without the bullshit, the best you can hope for is "as far as we can tell at the moment".

Re:In a word: Nope. (1)

Art Challenor (2621733) | about a year and a half ago | (#41747627)

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 (and not just because you never shower).

Charge by the Hour (3, Insightful)

dmomo (256005) | about a year and a half ago | (#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.

Maintenance vs new development (0)

Anonymous Coward | about a year and a half ago | (#41747347)

Ask how much of the work is legacy vs new development.
  Ask how long the product has been live.
Ask what the top 3 issues are with their existing code.

Does it matter? (3, Insightful)

kiwimate (458274) | about a year and a half ago | (#41747351)

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.

ask, "Why do people use your software?" (0)

Anonymous Coward | about a year and a half ago | (#41747357)

This question is good because, code is only good if companies can see the financial benefits of investing in it.

If their answer to "Why do people use your software?" is something like:

"Well, customers use us because we have local support people! we are also cheaper than any other local competitors."

Then you just know you will encounter bad, legacy code. In an ideal world, they would answer...

" Well, we face a lot of competition and keeping ahead is expensive. But, our software is the best. because we understand where we add the most value and focus our efforts on those areas. We are defiantly not bloatware!".

You are a developer and you want to avoid code!? (1)

conman09 (2759149) | about a year and a half ago | (#41747387)

"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." This statement makes absolutely no sense. Your job satisfaction should not be solely dictated by the amount and perceived quality of legacy code you are so "forced" to deal with. Working with existing code is a fact of life in this industry, get used to it. Instead of figuring out how to get around it by asking sneaky interview questions, learn to live with it. Also, why beat around the bush? Why not just ask the interviewer "How clean is your current codebase and how steep is the learning curve"? If they give you a sketchy answer... well I'll let you figure that out. I read this post and I think: "Maybe this guy chose the wrong career".

Re:You are a developer and you want to avoid code! (1)

Anonymous Coward | about a year and a half ago | (#41747469)

I'm road worker and I often repairing spotty patches. The thing is, I'll only work on pristine roads. Makes sense, yes?

The only way... (0)

Anonymous Coward | about a year and a half ago | (#41747415)

Strangle your boss. Take over his company and write software from scratch. lol

The most important step (1)

klingers48 (968406) | about a year and a half ago | (#41747433)

Step 1: Avoid any and all circumstances where you have to modify shell scripts that dynamically build batch-processing scripts run through Peoplesoft SQR.

Step 2: There is no step 2.

Get an MBA (4, Insightful)

Greyfox (87712) | about a year and a half ago | (#41747443)

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 (2)

Charliemopps (1157495) | about a year and a half ago | (#41747589)

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.

I write messy code... (1)

sitarlo (792966) | about a year and a half ago | (#41747475)

...and I make loads of money with it because it all works. You should focus your interview questions on the company's design and quality culture. I do appreciate clean, elegant, standards conforming codebases, but that's all academic exercise for the programmer. Users could care less as long as their software works the way the need/expect it to. Maintainability is important, but not as important as user experience. If the software does what users need it to do it will require *less* maintenance. Also, forget newer technologies because that just isn't important at all. Good projects use the *right* tool for the job despite current trends. Yeah, the stuff we have now is boatloads better than last decade's stuff, but you can still create useful software in FORTRAN or C. I stopped caring about code style when Sun first opened sourced Java. That codebase was barely readable but millions of people were happily using it. The fact is sausage tastes great, but the consumer *never* needs or wants to know how it's made. Ok, one step further here and some advice from a 25 year software trenches veteran: learn to appreciate and admire bad code. Learn to view it as a challenge presented to you so you have something to do to earn a living. Adversity is the avenue to opportunity.

All Code Is Shit (3, Interesting)

TexVex (669445) | about a year and a half ago | (#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.

Dont code .... (1)

geggam (777689) | about a year and a half ago | (#41747543)

Seriously...

System Operations is the art of keeping code running that should not be.

The ugliest module. (1)

MouseTheLuckyDog (2752443) | about a year and a half ago | (#41747581)

Ask them what is the crudiest and crustiest "module"/"unit"/"library" that is a part of their code. Then ask them to describe it and how they deal with it. If they claim there isn't one, then you know they are lying and head for the hills. If they can't think of which one is the worst then that spells trouble. Otherwise the answers to the question tell you a lot about the company. Also ask how they deal with regressions.

Quit and find a new job? (1)

mveloso (325617) | about a year and a half ago | (#41747615)

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.

How To Avoid Working With Awful Legacy Code? (3, Interesting)

tchall (1146319) | about a year and a half ago | (#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...

.

It's pretty obvious (0)

Anonymous Coward | about a year and a half ago | (#41747643)

You need to see it beforehand.

Anything other than that is assuming the people that wrote shit code won't lie to you. They will.
At least ask them what architecture and patterns the code adheres to and ask to see the internal standards the code was written to.

WTF does TDD show? You can write a system that completely does what it should do with TDD and everything is fucking different which is the main part of shit code. I'm not saying TDD is bad, I'm saying that it doesn't show the quality of the code.

All too often, this is true: (0)

Anonymous Coward | about a year and a half ago | (#41747667)

All too often, this is true:
"Awful Legacy Code" = Code One Didn't Write themselves and don't want to take the time to learn, to be shit-talked as much as possible so one gets to reinvent the wheel.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...