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?

[Stiletto]

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?

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

[stanlyb]

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?

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

[sjames]

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

Re:any questions?

[murdocj]

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

[lightknight]

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?

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

[flimflammer]

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

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

Re:any questions?

[Anonymous Coward]

Interesting. Drones are flying higher every year now. It's good to be a drone.

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?

[MangoCats]

So, if you have high turnover rate, will you be telling that to prospective employees, or will you make up some BS about personal reasons, trailing spouse, etc.?

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?

[jhol13]

There is one thing that correlates with code quality: unit tests.

If there are unit tests with (any kind of) coverage over 80-90%, the code is much more likely to be good than bad.

But then, the OP needs a serious attitude change. I bet his/her code is not as good as he/she thinks, not by a mile.

Re:any questions?

[Yvanhoe]

.Net is a good technology. I like it and I say it as an OSS guy working most of the time in linux. The problem is not with .Net per se, it is with the notion that it is made to be easier to use by beginners, which wouldn't be a problem if companies did not believed that this made beginners suddenly able to make good code.

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?

[__aaltlg1547]

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.

Sure, they're going to TELL you that the last two guys who had the job hanged themselves in their cubicle.

Re:any questions?

[dbIII]

Very high turnover rates often indicate a disaster area that is not worth the salary and that in extreme cases can even be written off as a loss of time AND money. If somebody you meet there is the "old hand" at less than a year, the place is most likely doomed and you can not even be sure you are going to get paid.

Re:any questions?

[Kjella]

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?

Well unless they fired the last guy the employee left the company, not the other way around. People leave for all sorts of personal reasons that don't really tell me anything useful, so you'll only get any job-related reasons they'd like to tell you about anyway. Remember that hiring is a cost for the company, it's not in their interest to hire people that feel tricked or disappointed with the job and will leave again shortly so most of them are fairly open to discussing if this is a good match. Note that it only applies when talking to actual employees or management in the company though, not their hired recruitment agencies. They want to get you hired and cash their bonus.

Re:any questions?

[Christopher Fritz]

There is one thing that correlates with code quality: unit tests.

Good unit tests. Remember, just as there's good code and bad code, there's good unit tests, and there's bad unit tests.

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?

[Jiro]

There is nothing in the post you were responding to which said that the government should interfere. Libertarians don't believe in government interference, but libertarians are perfectly okay with people complaining, discussing the complaints, and refusing to work for employers with shitty working conditions.

There is a big difference between being happy with something and thinking the government shouldn't intervene. I'm not perfectly happy with Nazis speaking, but I don't want the government shutting them down either.

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?

[Anonymous Coward]

In the real world 'good code' equals 'code produced quickly' (or rather, cheaply). Nobody (worth considering) cares if it is pretty on the inside. It just should be good enough to sell.

Re:any questions?

[Anonymous Coward]

Refusing to answer is the wrong thing to do. Lie. Once they are on-board, they won't leave too quickly once they find out. Messes up their CV.

Re:any questions?

[czth]

Agreed - I meant to imply that; perhaps I should have written "advantage" instead of "benefit".

Re:any questions?

[phantomfive]

Yeah, I'm just being stupidly picky. :/

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?

[kaiser423]

Right, but a higher barrier to entry means higher learning curve, which means that even good developers will put out crap code for a while. I much prefer programming languages that allow good developers to produce good code form Day 1, not Day 789.

Re:any questions?

[socceroos]

Horrid. But true. And as much as you can try and tell your next potential employer that your previous ones were liars, it comes down to your word.

Re:any questions?

[socceroos]

This may be true, but it doesn't change the fact that it's still poor code - and, in the long run, a poor choice.

You only need to look as far as the current cyberwar going on around the planet to see the fruits of such stupid descisions.

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?

[Darinbob]

This is probably unimportant. People just tend to leave after a period of time, no one stick around in one place as a career anymore. I think 3 years is about average in silicon valley. You'll never be told why a position was vacated other than that someone left.

I have seen code where the same small group of people wrote and maintained it for many years, and it was abysmal because they never bothered writing it for the wider world to understand. I've seen code written by people with a high turnover that was very good as well.

Re:any questions?

[Darinbob]

But in silicon valley you can't answer that well. People leave because their friends wanted them to join them somewhere else, or because they thought they could get rich quick by leaving an established stable company and joining a startup, or because a spouse was relocating across the country, or even because they'd just been there long enough and wanted to see something else.

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?

[bfandreas]

The only problem I have with .NET is that we find ourselves constantly in a situation where we have to buy libs and components that are absolutely Free for Java.
.NET severely lacks organizations like the Apache group. And in some cases freedom of choice. There is 3rd party support. But not as much and under the same conditions as for Java.

Re:any questions?

[bfandreas]

I usually find that if the company in question doesn't think refactoring is part of the ongoing house keeping process then you will propably encounter bad code.
If you explain that if you need a change or a new feature the best approach most likely is to refactor the code until it is easy to implement AND their reaction is to ask why to touch perfectly running code then you are screwed.
If running extensive unit tests are not part of the build process then you are propably screwed.
These cases don't mean you don't want the job. On the contrary. You want the job plus the stripes to change their development process for the better. And that, friends, neighbours and fellow geeks is how we formerly simple coders made the transition into management. Not to whine about something is bad but to offer a solution and take the responsibility(and the paycheck) how to make things better.

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?

[Chrisq]

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.

I would be careful of leaving long gaps though. Take on some short-term contracts rather than have six months "unemployed" while you look for the ideal job.

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?

[Ash Vince]

There is one thing that correlates with code quality: unit tests.

Good unit tests. Remember, just as there's good code and bad code, there's good unit tests, and there's bad unit tests.

Exactly, I have submitted to bug to open source frameworks and had them sent back to me simply because the overly simple unit tests they were using could not replicate the issue. Unit tests are not a panacea and certainly not a replacement for decent functional testing.

Re:any questions?

[Hognoxious]

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 rather depends on whether companies are capable of recognizing a good person or not.

And in the current market, I'm not sure it's true anyway. There's plenty of people around who are good enough.

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?

[HungryHobo]

I find .NET to be quite nice really. the pain comes when you mix in older things like VB6 and try to get them to talk to each other.

On that note after working with VB6. sometimes. sometimes it's not just bias. some languages are just awful and make it hard to write good code.

languages are not all equal. some make it hard to spot bugs while others make it easy.

bad languages respond to a typo by working subtly incorrectly. good languages respond to a typo by refusing to work.

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?

[Lonewolf666]

It also depends on the type of the project. .Net is nice for applications that consist mostly of "business logic", but if you have to do a lot of low-level programming or use a lot of legacy DLLs, it becomes a PITA. Because in these cases, you have to put in extra effort to create data structures with guaranteed memory layouts, keep the garbage collector from killing them at the wrong time etc...
Now all of that is doable, but at some point you're IMHO better off sticking to C or C++ .

Re:any questions?

[Lonewolf666]

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.

To me it is more important if I get the time to do it right. Refactoring existing code and making it more robust can be rewarding too.

Maybe the guy just did the best he could with the time he had

Eek yeah. On my current project, the release date is so tight that we have to do it the quick and dirty way. Instead of porting everything to C# (for which there is not sufficient time), we have to keep a lot of the old Delphi code and stick it into the new application as DLL. I'm sure it will do wonders for maintainability ;-)

Re:any questions?

[JamesRing]

You're never going to get a straight answer about why the position is vacant, waste of a question.

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?

[murdocj]

Thinking about it some more, I agree that there are some bad (or at least limited use) languages out there. For example, Perl is fine for one-liners or quick & dirty scripts, but writing any kind of decent sized system in it is a disaster. But when people start arguing about .Net vs. Java or (even more ridiculous) VB.Net vs C# (two syntaxes for exactly the same function) then they are either ignorant, unprofessional, or both.

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?

[mangobrain]

If those answers are the truth, what's wrong with them? They don't say anything particularly bad about the workplace, just that the previous employee had other ideas about what they wanted to do.

Re:any questions?

[Kane Devaid]

Actually, almost all of the design decisions in C# (I can't speak for Java) are around pushing the author in the safest and most correct direction (just read Eric Lippert's Blog), and with the advanced refactoring support, it's easier to clean up bad code. In fact, when Roslyn is released, the refactoring capabilities and third party tools will increase by an order of magnitude. I know what language I would prefer my legacy code to be in.

Re:any questions?

[Rob the Bold]

This is probably unimportant. People just tend to leave after a period of time, no one stick around in one place as a career anymore.

Maybe not, but for a slightly different reason. The question was to identify code quality as a means to improve the chances for job satisfaction. So having the developers of the original undocumented/tedious/nightmarish mess still around means you can go and ask them what (the hell) they were thinking. It may not make the code any better, but it can mitigate the pain of figuring it out.

Depends on what would make a job more "satisfying" to the potential employee, of course. And any suggestion we come up with short of the problematic "work with the code for a while" is just an informed crap-shoot anyway.

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?

[SecurityGuy]

It's absolutely the interviewee's business. I ask this question. I'm not a prima donna, but I do want to know if the last guy left because he couldn't handle the 90 hour work weeks,or the people he had to work with are jerks, or if there's some administrative or bureaucratic hurdles that makes getting anything done impossible. On the positive side, I also want to know if the position is vacant because he's doing a great job and you promoted him. Even moreso turnover rates. If your turnover rates deviate significantly from industry norms, there's a reason. It's no different than looking at someone's resume and seeing a new job every year. It doesn't mean instant no-hire, but it does mean ask about it because it might betray some other reason that's an instant no-hire. It also might be totally innocent. The only way to find out is to ask.

It's actually a red flag if you'd act offended or not want to share the information. I want to accept a job at a work place where I'll be happy and productive, not one I'm going to want to leave in 6 months. When you deny me information I need to know if I'm going to be happy and productive, that nudges me to thinking I won't.

Re:any questions?

[jythie]

Actually the two are pretty similar. Companies also have mortgages to pay. Canceling or continuing a project is tied heavily into their ability to keep doing things like rending office space, paying employees, buying from suppliers, etc.

Re:any questions?

[cusco]

Then I take it you've never lived in a company town, a rural area, or anywhere that there is one primary employer. And don't say, "an employee can just move somewhere that there are better job prospects" until you've done it yourself with no savings. Libertarian ideals are great, until they meet the real world.

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?

[bfandreas]

We needed an Oracle driver for LINQ(granted, that should have come from Oracle) and stuff like POI funnily isn't provided by Microsoft out of the box.

Re:any questions?

[GameboyRMH]

Understatement of the year. Some companies don't like to hire people who are unemployed, never mind those with ZOMGEMPLOYMENTGAPS!

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?

[dohnut]

Yes, this.

There are (at least) 3 things that lead to bad code: 1) Poor Planning. 2) Time Constraints. 3) Mediocre (and even bad) Developers.

Planning takes time and it is difficult. We employ "Systems Engineers" to capture requirements, understand the existing code base, and then determine what work actually has to be done. Then the developer takes those plans and turns them into code. Unfortunately, and especially as complexity increases, you are going to: 1) miss things, 2) break existing things, and 3) run into conflicts that often require complete refactoring of some part of the code or an ugly kludge to get you by. On a large development effort you usually hit all 3 of those.

Time. Obviously time affects everything. There's never enough time, so it's very important to get the planning stage right. If you skimp on time with planning you will pay it back 10-fold over the course of maintaining your software. And then there's just the obvious stuff. How many of us are juggling multiple projects, bug fixes, documentation, etc. Priorities change week to week, day to day. Is it management's fault? Ultimately, yes, but their jobs aren't easy either.

Developers. Hey, most of us have been mediocre at some stage during our careers. Hopefully we all get better with age (I've only met one person who got worse) but some progress much more slowly than others. I've been coding since I was 9 (I'm nearing 40 now) and if I look at code I did even 5-10 years ago, it makes me cringe a little. The code works, but it is not as efficient or well organized as I would do it today (or so I've convinced myself).

We code in C++ where I work. Most of the developers have been coding for a long time. But they coded for a long time in 80's languages and transitioned with no training at all to C++ (which I consider a 90's language). People still roll their own lists (i.e. don't use or aren't aware of the STL), misuse the object paradigm, don't understand templates, still use pointers when they should use references, etc. Most are basically still C developers and they are perfectly competent C developers -- but we're using C++ in a highly threaded environment.

So, imagine, if you will, the state of a decade+ old code base for a massive, monolithic application which has to communicate with a (very) random and ever-changing assortment of hardware devices, protocols, etc. written in C++ by developers who never really learned C++. Also, the poor bastards that have to do the planning in this quagmire and the managers that are taking fire from all sides.

Yes, bad code is the norm (and, yes, I do enjoy my job).

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?

[Anonymous Coward]

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.

And so the cycle continues....

Your "other priorities" are exactly what is leading the OP to try to avoid working for companies with "awful legacy code".

It is your "other priorities" (and this is really a euphemism for "cutting corners" based upon some arbitrary desire to reduce time-scale, cost or other resource) that creates such "awful legacy code" in the first place!

Re:any questions?

[jessecurry]

I second this advice, although having a personal project that you spent time working on can stand in for the gap in employment.

Re:any questions?

[tsm_sf]

I ran across a custom-built proto-CMS written in C++ once... the proud owner describing what a genius the developer had been.

Re:any questions?

[SydShamino]

Expand your analogy a bit. Nailguns make it easier to build houses for good builders, because it's faster to put in a nail than by hand. On the other hand, nailguns make it easier for bad builders to make houses, because "When in doubt, shoot three more nails into it" becomes viable, whereas with each nail going in by hand the builder might think a little longer about where and how to put those nails.

Re:any questions?

[czth]

That's part of supply and demand. Libertarian ideas - self-ownership, non-aggression - remain great.

Re:any questions?

[cusco]

Non-aggression. That works really well when there is no government body keeping company management/owners in control [/sarcasm] Just ask any 80 year-old former miner and they'll tell you how restrained and cooperative mine owners were. My great grandfather had to move his family out of the company town in Marquette, Michigan in the dead of night so that the company enforcers wouldn't stop them. Henry Ford's company goons carried truncheons and machine guns to break up unionization meetings.

Like I said, nice ideals that don't work in the real world. Just like the Communists and Greenpeacers. Nice ideals, but not viable in reality.

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?

Re:any questions?

[rtfa-troll]

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

I think this is one of the benefits of asking such questions. People who have something to hide won't be interested in you. For example, I've started asking about patent policies in advance. This could clearly upset some employers. They won't offer me a job. Still, I'm employed and doing fine. Basically this filters out the jobs that I would wish I hadn't taken.

Re:any questions?

[rtfa-troll]

But in silicon valley you can't answer that well.

Hmm ... let's see...

People leave because their friends wanted them to join them somewhere else, or because they thought they could get rich quick by leaving an established stable company and joining a startup, or because a spouse was relocating across the country, or even because they'd just been there long enough and wanted to see something else.

Excellent answer

Even better if you can add "by the way, if you want to talk with Jeff, the last guy to have your post, I think he's coming along with us for a beer on thursday; he even promised he'd spend a day or so with the next guy to pick up the post when that's needed."

I have never understood the attitude that if you leave the company you become an unperson. I always ask the guys who work for me to give me a bit of warning before they hand in their notice and preferably to warn me if they start job hunting. Almost all of them have, and sometimes I've even had almost half a year's worth of an experts time where I knew he was leaving and he was willing to train up a bunch of people (it took about three!!) to replace him.

BTW: simple management question: how do you get Jeff to agree to come in specially to spend a day training up his replacement?

Re:any questions?

[triffid_98]

Really? I've found plenty of .NET ports for Java libraries I used to use. There are sometimes gaps, but I have yet to come up against any really serious ones.

Most of the paid libraries are for things like UI components, and with WPF styling you seldom need them.

Re:any questions?

[umghhh]

How true. I have one comment though:. you say that "pragmatism > idealism" and that it is then sort of bad. That is not entirely true, neither it matters that much. Pragmatism may mean for instance that because you value your own time and want to avoid waste in the future you actually care for structured, well commented code (whichever way it is done). What I wanted to say is that it is not pragmatism that stands in the way but idiocy. I would even go as far as to say that idealism is bad for developing working but also well structured and documented code because idealists do not like to cope with a reality and this means that instead of taking measures that help produce code that is readable and working they tend to do fancy things that do not put things forward forcing others to cut corners because they had to wait and ended up short on time etc. To say it differently: it is not very pragmatic to say: "code whatever important that it compiles" - you pay the price eventually also when you do not notice (because you have no direct comparison).

Re:any questions?

[glhturbo]

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.

No I'm not.

They'd be just as happy washing cars for 18 hours a day,

No, I would NOT.

and aren't necessarily interested in solving an annoying problem once and for all.

Yes, I am, but if it takes three 9-5 days instead of 2 9-9 days, so be it. I value my time away from work as much as (or more) than my time at work.

They're just interested in a job, any job, so long as it's doing rote work and getting paid an hourly wage.

No, wrong again.

No passion for technology

TOTALLY wrong.

Re:any questions?

[mcrbids]

I've been maintaining a codebase for 10 years, and it is rather difficult to keep everything crisp. It's harder as we grow (we now have 7 developers) to keep things cohesive because although there may be a "right way" to accomplish something, it's not as though everybody knows about it already.

So you do periodic code reviews, group sessions to discuss the "right way" to solve various types of problems as they arise, and just suck it up and do the refactors when the cost of doing so is lowest in comparison with current needs and urgency while simultaneously trying to keep things working for customers now.

Truth be told: it's tough.

Re:any questions?

[jgrahn]

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.

Yes. An euphemism for "this software used to be Joe's personal playground until he quit" or "all the developers are fresh from school and do what their teacher told them to".

On the other hand an organization can easily be too backwards, too.

Re:any questions?

[umghhh]

good flame congratulations!

Re:any questions?

[czth]

Still no. Corporations just pay off the government, and then you have two problems. The evil acts of some corporations no more reflect on libertarianism than the acts of murderers reflect on peaceful individuals.

Re:any questions?

[n7ytd]

Yes indeed, some customers are not worth having, at any price.

Re:any questions?

[ld a,b]

Your job is finding a way to both comply with their requirements and getting quality software out. If after thinking it through with your coworkers there is no way you could get it done, your job is then to tell them they are full of shit and go get us new requirements. If unresponsive repeat and rinse with their superiors.

Re:any questions?

[cusco]

So the solution is to remove the organization that is keeping them at least slightly in check? When was the last time that you saw a unionization meeting broken up by thugs armed with shotguns and lead pipes? Even WalMart doesn't dare go that far, because there are still laws against it. Occupational safety laws, workers compensation laws, consumer protection laws, and the like exist for a reason; if left unrestrained corporations destroy people and societies. The solution is not to get rid of the restraints, it's to fix the enforcer so that it is again working in our interest.

Re:any questions?

[Jane Q. Public]

About the questions, I would tend to agree. (I do not particularly agree about .Net being "new technology", but that's a side issue.)

Aside from using newer technologies, which I generally approve, I think there is an invalid assumption here.

TDD does nothing to guarantee good code. It just means the code works. It says nothing about any other quality. All code needs to work. But there is good code that works, and there is bad code that works, and TDD does not distinguish between the two.

That having been said, a shop that uses TDD is likely to use other good practices as well. There's just no guarantee.

Re:any questions?

[aled]

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.

No. Eclipse Java IDE doesn't generate code AFAIK. And refactoring is a very good tool. I don't think Visual Studio either.

Re:any questions?

[Lonewolf666]

GP here.
I have talked to the top project manager and told him that we would only be able to do a inferior version in that timeframe. My impression was that he understands the problem, but can't do much because the deadline is set from even higher up in the hierarchy.
Overall, it looks like top management pulled the date for the deadline out of their collective ass, instead of doing an estimate first :-(

Re:any questions?

[Ash Vince]

It is your "other priorities" (and this is really a euphemism for "cutting corners" based upon some arbitrary desire to reduce time-scale, cost or other resource) that creates such "awful legacy code" in the first place!

Keeping costs down is not really arbitrary though is it. You are getting paid to produce a commercial product, not a work of art. If the market will not stand for cost of making out of gold then you simple produce it out of lead with gold plating then tell the customer that is what they are getting for the price they paid, the solid gold option costs extra.

If you refuse to do this chances are you just lose work to people who do. We might not like doing it as developers but sometimes we have no choice in the matter, that is just a fact of life.

Re:any questions?

[dbIII]

The problem is many breeds of libertarianism seem to have a philosophy of giving those "murderers" free reign. Such a situation is bound to devolve into hereditary warlords with serfs, as shown with examples existing in some places even today, which is why I consider this philosophy is restricted to the very naive and the sociopathic (eg. so my cousin will be a slave under this system - why do I care? I get to be one of the slavemasters).

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

Re:It's not the code

[murdocj]

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.

Re:It's not the code

[TheLink]

But do you need C for the entire thing? I've had projects where a few things were in C (because they had to talk to the kernel etc) and the rest were in other languages.

We had a network protocol for one of the C modules, even humans could connect to it and do queries and commands. We did similar things for many of the other modules as well even if they weren't written in C.

If turns out a module would be better in X instead of Y, replace it and just make sure it uses the same protocols. You can also test stuff more easily via those interfaces. Create emulators etc.

Apparently Amazon expose _everything_ via service interfaces: https://plus.google.com/112678702228711889851/posts/eVeouesvaVX

If you use TCP connections, one thing that can bite you is Nagling. Turn it off. Set TCP_NODELAY on or equivalent. Otherwise comms latency can increase by 200+milliseconds. Nagling belongs in the 1980s, but for some reason some MMOs don't seem to turn off nagling on their clients and servers, maybe the only reason is the OSes have it on by default.

Re:It's not the code

[bfandreas]

...and that is why I keep a strict "complex is wrong" policy when it comes to code. We all wrote nail-bitingly clever code in all-nighters. But we all also had our problems to understand the same code a year or so later.

I once had an argument with one of my coders when I replaced something complex and propably efficient with something simple and definitely not efficient. I told him that even though what I wrote was O(n^2) it didn't matter. Especially when n=10. I really hate it when people optimize the wrong bits of code and leave a mess in the process. Or if they read the wrong book and suddenly use every single design pattern for what would otherwise have been 50 lines of straight forward code. Or try to bypass our company framework in a case which is not covered by it. In most cases they simply wanted to try something unnessesary clever.

We only have overtime about once or twice per year and employee and I'd like to keep it that way.

Re:It's not the code

[SecurityGuy]

How is this insightful? There is such a thing as good and bad code. I was once asked to port an app that did rather complex calculations in fortran. Nary a comment in the whole thing, and not a single variable that was named anything other than one or two letters. The notion that all code is equally bad is nonsense, not insight.

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

[Dan667]

sure

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

Re:one question

[dubbreak]

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

Lot's of great engineers in that company still, plenty of opportunity to fix things (I still wake up with solutions to various issues in that system), but it all boils down to management. Basically any code can be fixed. Stuff that's usable/stable can be DLLized (decoupled some how with a proper API) and the horrid stuff gets rewritten. I have yet to work on something that's a complete throw away. The issue is you need the support of management in order to have the resources required to do the work (unless you want to spend long unpaid nights working on code for the good of what is ultimately someone else's company).

I ended up leaving mainly out of frustration (that and a good opportunity). I started my own company and hired one of the students I had worked with previously. I couldn't be happier.

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

Re:one question

[DubThree]

I agree. Just like in life you learn from your own mistakes and the mistakes of others. Many times I want to just rewrite the code from scratch because I think it will be faster, but in doing so I would miss opportunities to learn from others mistakes. If I make the same mistake myself, then I haven't learned and it is my fault. If I don't give myself the opportunity to learn from it then I'm more likely to repeat the error or something similar. Anyone that thinks that won't work on the code of others is someone that thinks that their shit doesn't stink. I would not consider hiring them to work for me.

Re:one question

[kaiser423]

This! I actually enjoy working with old code every now and then, even if it's a sea of crap. It's kind of neat not to be solve problems yourself, the way that you would, but to see how other people solve problems, get in their mindset, their mind frame and learn how they think. Then see how them and others dealt with extending, maintaining, and refactoring. It's odd, they become like old friends. It's kind of intriguing to through code to get to know someone well enough to say "This is Fred's module, here's how to would have programmed it" and have an idea of how to fix it or refactor it before even looking at the code.

Re:one question

[jmerlin]

How did you test that 10,000 line java application so that you knew your refactor didn't cause regressions or new bugs?

Re:one question

[91degrees]

"No."

It seems a bit of an odd request to me. I think it would to a lot of employers, including ones that have beautiful code.

Perhaps you don't want to work for them, but if you're limiting yourself to companies with nice legacy code, and aren't protective of their propriety information, then you're reducing your employment options quite considerably.

Re:one question

[Max Littlemore]

How did you test that 10,000 line java application so that you knew your refactor didn't cause regressions or new bugs?

I didn't.

I looked at the business problem and re-wrote the entire thing from scratch. It took a week and ended up being a couple of hundred lines of code with ~15 classes. Solved exactly the same business problem with better reliability and performance which was what I was hired for. Seriously could anyone be bothered unraveling that much spaghetti just to figure out wtf is going on? I re-used some snippets, but most of it I threw away.

The end result meant that a single instance of the application could do what 7 instances were needed for previously, it allowed new network protocols to be quickly developed as plug-ins rather than being locked into a single protocol and it had indefinite uptime instead of needing to be restarted daily. That's satisfying stuff right there.

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?

[viperidaenz]

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?

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

[dubbreak]

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?

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

Re:You want to avoid legacy code?

[dubbreak]

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?

[dcollins]

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

Re:You want to avoid legacy code?

[Kjella]

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

Not to mention risk, because there's code that'll break. For example let's take a conflict I once had where the database guidelines said table name + "Id" was the primary key, while the other column names would be defined by an external standard. Works great with lots of legacy code written until the standard defines a field $fooId in table $foo and we have two conflicting definitions. Simple case of namespace collision, trivial to solve with a prefix right? Unless you realize you can either break all the code that assumes column name == field in standard or all the code that assumes table name + "Id" == table identifier. And you know such "basic" logic won't have test cases, it'll just randomly break some code here, some procedures there, reports will fail and trying to build an exhaustive list is an exercise in futility.

Chances are they'll do some kind of low risk hack like rename that field $fooId2 since there's nothing using that field yet since it's new and just hack whatever is using it. But then you've just created a booby trap for everyone else, like say code that's trying to auto-generate/update the table structure from new versions of the standard. No special case, push into system, system goes boom. What's worse is that hacks have a tendency to multiply, if you do that once then people will think that's an okay way to solve their problems and before you know it you'll have a dozen places your code will break if you "do it right". Sadly the only code that'd be easy to rewrite is the code that doesn't need rewriting.

Re:You want to avoid legacy code?

[sjames]

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

Meanwhile, the question wasn't about GOOD legacy code, he's apparently fine with that.

Re:You want to avoid legacy code?

[dougmc]

In my experience, it's pretty much awful "by definition".

If it wasn't awful, people wouldn't be calling it legacy code. They'd be calling it good code, no matter how old it was. It's a derogatory term, at least in my experience. And the older the code is, no matter how skilled or conscientious the authors were (though of course these things do often delay it), the higher the odds that people will start referring to it as the derogatory term "legacy code".

Really though, if I look the term up on wikipedia, they've got a bunch of different definitions --

1: source code that relates to a no-longer supported or manufactured operating system or other computer technology.
2: code inserted into modern software for the purpose of maintaining an older or previously supported feature.
3: it can also apply to executable code that no longer runs on a later version of a system, or requires a compatibility layer to do so.
4: source code inherited from someone else
5: source code inherited from an older version of the software.
6: code without tests

Personally, I was thinking of #4 and #5, and in general, if they're "good" code, people don't really call them legacy code so much -- it's just "the" code.

But in spite of my own preconceived idea of what the term means, if the original poster really wanted a useful answer, he probably shouldn't have used such an ambiguous term -- or if he did, he should have been clear about which definition he was referring to.

As I see it, how to avoid it was the wrong question to ask -- as you really can't avoid it. But what you can do is look for a place with good programming practices (and is open to your own good programming practices, if you're such a person) so at least the code can last as long as possible without getting labelled "legacy code". Though really -- if your code stays in use for decades, that's a testament to your code that goes beyond mere "maintainability" or "elegance", however these things are defined.

Re:You want to avoid legacy code?

[drew_eckhardt]

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

Having done software professionally for 20 years, delivered five non-trivial products built from scratch to customers for business critical applications (things like block storage on a shared nothing cluster of x86 boxes and a highly available cellular base station billing interface), and worked on at least a dozen other products I disagree (three big company re-orgs in 18 months and some consulting exposed me to a lot).

Fast or good is a false dichotomy. You can have both or neither and as an added bonus choosing "fast and good" also nets "less expensive" which is the mythical holy trinity.

Do things right and you'll make your initial profits sooner - either because customers start buying that product sooner or you pivot and get your next try out there in less time.

Software (whether packaged that way, as a service, or as a hardware appliance) products are about nested feedback loops within the larger business cycle of market needs leading to customers paying you repeating as you flesh out a complete product, build a surrounding ecosystem ecosystem, go vertical, etc.

Within that are the loops surrounding things engineers identify with like writing software, writing tests, fixing bugs, and making releases.

The things you do to make maintainable code reduce the time it takes to deliver a viable product to customers on the first AND following cycles.

Unit and regression tests reduce the time to fix the bugs you inevitably introduce. There's much less wasted effort when you write code, the relevant tests find a problem immediately (as opposed to waiting for a release to drop to QA or going through multiple release candidate - QA cycles followed by shipping to a customer that finds the problem), you have more information which leads to a quicker fix, and you have no context switch overhead. They also give you more latitude in what the people you have work on because there's little risk added by people working on unfamiliar code when there's enough pre-checkin coverage to make getting bugs to QA or customers unlike.y

Meaningful comments surrounding what you're doing facilitate neural pathway formation leading to a deeper understanding, more "aha!" moments, and fewer bugs. They get you back on track sooner after the inevitable context switch for tactical issues.

Refactoring reduces your bug count and time spent on problems because non-existing lines of code can't have bugs.

Things continue to improve as you get nuttier:

I was turned on to simulation (link your shipping product code to mock objects at a low level gaining control over scheduling (make it deterministic and get atypical timings via pseudo random or state search methods)) and model checking by a Digital Systems Research Center alumni I was working with on another clustered block storage appliance. It seemed neat and useful until I spent an afternoon moving a lower piece of the stack into the simulated environment and found the buffer reuse problem which had been holding up our release for a month. "Neat" became "you'd be dumb not to" for some class of software. In a subsequent commercial life I did the right things again and solved memory corruption problems which showed up under certain event orderings in hours where co-workers did not and took weeks for the same sorts of issues.

Tool building can pays huge dividends too:

A good logging system is not core to your business and something which people usually skip. However in practice it takes much less time to build a system which logs 300,000,000 (on a four year old pre-production dual socket Nehalem box) entries a second via a printf API into a circular shared memory buffer which survives process termination and allows development trace level logg

Re:You want to avoid legacy code?

[Darinbob]

Startups create some really awful code. Sure the early guys get to design stuff on their own from scratch, but they're often designing on their own without making sure all the different pieces work together well of that they all follow common style and design rules. That's a big problem with people who really hate working with lousy code I find, they tend to have very hard and strict standards which they will not budge on even if it is different from what the rest of the team uses.

Re:You want to avoid legacy code?

[91degrees]

The worst code I've ever worked with was from a startup. Unless you join the startup right at the beginning you still end up having to work with what's there and you don't have any opportunity to rewrite it.

Trouble is, a lot of startups are formed by intelligent people without a lot of industry experience. They see a clever idea and fall in love with it. This means that to use the code, you have to understand exactly how and why certain design decisions were made.

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.

Sometimes customer requirements change. It may be a simple request that in good code requires changing a single configuration value, and in bad code requires changing several hardcoded values, and extensive testing because of comples requirements.

Developer Tenure

[Anonymous Coward]

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:

[Sheetrock]

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

Re:One warning sign:

[Anonymous Coward]

What if the one guy was someone like Dennis Ritchie?

Re:One warning sign:

[busyqth]

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:

[metallic]

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.

Re:One warning sign:

[adnonsense]

Seconded... I've corralled the company's system into something approaching sanity, but no time for any kind of documentation apart from the odd comment in the code (usually starting with "FIXME!"). There's also a plethora of sub-systems I have trouble managing even though I wrote them myself - mainly due to having to throw them together at short notice while working on something else at the same time.

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

Re:One warning sign:

[UnknownSoldier]

Mod parent +interesting.

I nominate this story is (almost) destined to become a classic as Mel the programmer is:
  http://www.cs.utah.edu/~elb/folklore/mel.html

You've touched upon something that I think separates the novice "code monkeys" from the experienced developers. The experienced realize we (sometimes) write crap code and aren't afraid to learn how to do our job better. The novices *think* they are some hot-shot programmer but don't realize how much they have yet to learn. ;-)

I guess the holy trinity never changes:
  "You can have it good, fast, or cheap. Pick two."

Although there are those that say scope is the 4th dimension; othere say in practicality there is only time vs features.

Interesting References:
* http://www.startuplessonslearned.com/2008/10/engineering-managers-lament.html
* http://office.microsoft.com/en-us/project-help/the-project-triangle-HA010351692.aspx

Re:One warning sign:

[Big Hairy Ian]

Doh!! I was that programmer!!

Re:One warning sign:

[grodzix]

I'm in such position right now. Mobile banking app I'm working on at the moment has been written by 3 consecutive people, at least two of them I've noticed have been learning the platform on this project. They had no tester, so they were their own QA. App has been live for about 1,5 year. Now, here is me, after 0,5 year at new job I'm still fixing bugs without actually implementing anything. I've got tester so unfortunately he (unlike me) has plenty of time to find lots of issues with the app. I'm trying to refactor the code, but I don't have enough time as I'm busy with fixing my predecessors mess. Well, that isn't something they've taught me at uni (and they should have).

Re:One warning sign:

[tomhath]

Came here to make this comment. Occasionally you'll find a super-programmer who gets it right, but most of the time his code is so convoluted and poorly documented that nobody else can stand to get near it.

Re:One warning sign:

[GameboyRMH]

'Sup lone codemonkey buddy!

I know I have one piece of code with an apology in the comments -_-

Re:One warning sign:

[GameboyRMH]

We need to form a support group. Overworked Lone Coders Anonymous.

Simple answer

[stox]

Work for a startup that has no legacy code.

Re:Simple answer

[Mabhatter]

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.

Re:Simple answer

[jmerlin]

Every day at 5, I rm -rf *. I don't even have legacy code that's a day old. When people say "it sucks when you read your own 6 month-old code and have no idea how it works or what you originally did," I have no idea what they mean, because I just remember how I solved the problem and recreate it. I love being WET (reWrite Every Time).

My favorite question

[stanlyb]

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

Re:My favorite question

[Rob the Bold]

If they know what CVS is, and they do use it... You know you're in trouble.

I know, I've been stuck using CVS, but I think the OP meant "some kind of source control" versus "none at all" -- not "CVS" in particular. He did state "any kind of" - but as always, I could be wrong.

There is a still worse answer: "we use our own system". Unless their business is writing version control systems, they've picked a bad one.

Re:My favorite question

[Bigby]

CVS can be used as the product or the acronym describing all the different kinds of concurrent versioning systems.

Re:My favorite question

[Actually, I do RTFA]

CVS, no.

We go to Walgreen's, why?

Depends on company culture

[uberbrodt]

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.

How To Avoid Working With Awful Legacy Code?

[Anonymous Coward]

Don't use Windows. Duh

Become thine enemy

[Anonymous Coward]

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.

Stay with a company and prove yourself

[Anonymous Coward]

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.

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.

Re:Legacy Code is not the issue here

[PhrostyMcByte]

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.

Re:Legacy Code is not the issue here

[mbadolato]

Get hold of Martin Fowler, “Refactoring” and Michael C Feathers, “Working Effectively with Legacy Code”

I would also add Robert C. Martin's “Clean Code” to that list. for a lot of great advice on writing code. It doesn't matter how many years you've been writing code (I'm at around 30 years of doing it), that book has very valuable information that you'll be able to use.

Re:Legacy Code is not the issue here

[rwiggers]

Hit the nail.
If you have at least a little experience, you've already at least once gone through the codebase and asked who's the idiot that wrote that, checked the answer on the version control system to find that the idiot is yourself.
On the other hand, sometimes the legacy code is so much patched that it's easier and faster to rewrite it. If this code is that much patched that you can't even follow the code flow anymore, bugs left are only the scary ones anyway. Rewriting that code is a high risk task, since many errors already solved will be done again, but may still be worth it.

doing it wrong buddy

[LodCrappo]

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.

[quietwalker]

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.

[Art Challenor]

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

Re:In a word: Nope.

[stanlyb]

After so many years of development, i found out that there is a silver line: Don't refactor it. Just do it. From the very beginning. Sounds simple, ain't so? But it becomes simple only after having 10+ years of real development experience.

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:Does it matter?

[Kjella]

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

My work satisfaction tends to be proportionate to how much I get paid and how nice the other people are.

Good for you, different strokes for different folks. Personally I would be extremely frustrated at work if I felt lost in a kafkaesque maze of bad code where solving the most trivial bug is an exercise in traversing ten layers of "enterprise" abstractions with misleading names and hidden side effects written by a spattering of random contractors and lowest bidding outsourcing companies with no overall design or architecture. Doesn't matter if the pay is good, the people are nice, if I feel I'm pouring effort into it and two drops of results come out the other side I'd not survive in that job for long. For sure getting paid and getting along is important but one of the main drivers for my happiness at work is feeling productive, doesn't matter if I drown in meetings or bureaucracy or bizarre logic if I can't get much done I'm not happy. YMMV.

Re:Does it matter?

[dbIII]

The problem, which can in cases be a barrier to promotion or even a complete loss of job, is that spending a lot of time maintaining code is seen by outside parties as being non-productive. You become known as the guy that does nothing and the obvious dead wood to remove when changes are made, then the guy to blame when somebody else touches whatever you were maintaining and finds the problems you have not fixed yet.

One developer I know worked very hard for three years to turn a slow, unstable and unsellable piece of shit into a collection of useful software that began to generate a lot of revenue for the company, yet was thought of as a guy that did nothing for three years by new management. He was fired and not given a reference.

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.

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

[conman09]

"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:no

[Samantha Wright]

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

The most important step

[klingers48]

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.

Re:The most important step

[muon-catalyzed]

mostly any kind of "script", be it VB, PHP, Python or even Java that means close encounters of spaghetti code is very probable, I don't want to repeat "real men code in C" mantra, but often any kind of 'scripted' code base means problems ahead.

Re:The most important step

[benjfowler]

Amen, script code (especially in dynamically typed languages with weak or dynamic type systems), needs to be tested thoroughly to be declared "working". Why scripters write so few unit tests beggars belief here, because that code of test coverage in those kinds of languages is vital for building robust code.

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.

Re:Get an MBA

[complete loony]

Programmers should rub shoulders with the end users as they go about their jobs. If you don't hear their easily fixed grievances directly, they may never filter through the layers of bureaucracy that can build up.

"Oh, you need to get from that screen to this one, but we currently force you to search for the record again? Easily added."

"This report takes 30 minutes to run and you run it every day? I'll have a look at it."

"Wait, why are you copying all of that data into a spreadsheet? I can add that calculation to the screen for you."

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

[Anonymous Coward]

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

I write messy code...

[sitarlo]

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

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

Dont code ....

[geggam]

Seriously...

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

The ugliest module.

[MouseTheLuckyDog]

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?

[mveloso]

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?

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

.

Ensuring good legacy code quality

[Tijaska]

Here's a novel idea. Write good quality code yourself, and stop job-hopping.

What is it exactly that you do?

[shadowrat]

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

Critical question...

[Genda]

Does the Architect own a tanto? Has been required to use it?

Re:Interviews are a two-way process

[flimflammer]

The odds of that working are astronomically low. They probably don't want you personally that badly.

Anything written by others is "Awful Legacy Code"

[elabs]

That's just an axiom of engineering. You can craft the most beautiful, standards-compliant, pattern-invoking code ever and the next engineer to come onboard will see it as a legacy, stove-pipe, monstrosity that needs to be re-written from the ground up. Of course, his rewrite will just repeat the cycle.

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.

Best way to avoid legacy code...

[QuietLagoon]

... is to be an employee with a single-digit employee number in a start-up company. Beyond that, you will have to deal with the Big Ball of Mud. Deal with it.

Get a promotion

[Loosifur]

I haven't been in the industry for ten years, or even near it, and I know that unless I'm being hired specifically to create something new I'm going to be working with existing code. And I've worked for some very, very small companies where the code I'm working on has been written by people who've been short on time and resources. It's looked like total butt. It's been slapped together with bubble gum and bailing wire, and I've done my best to leave it better than I found it for the poor sap who comes behind me. Unless you're being hired to create something new, you'll be working on something old. You're probably being hired to fix what they've already got. Why would this surprise you?

Seriously, if you don't want to work on existing code, look for jobs where you're being asked to develop something from scratch. If the code worked great in the first place they wouldn't be looking for someone to fix it, would they?

Re:Suck it up, princess

[lightknight]

And programmers, in general, tend to earn more than the populace median. They also tend to put out more billionaires than almost any other sector that comes to mind.

You may as well have said, suck it up lawyers / doctors, remember, half of doctors / lawyers are below the mean.

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.

Re:I'm surprised at some of the responses

[sourcerror]

Would upvote if I had modpoints.

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

Re:I'm surprised at some of the responses

[istartedi]

Was it code for a gay porn site? It could be descriptive.

No, IIRC it was quick-n-dirty code (no pun intended) written by an admin.

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

[zippthorne]

How would you feel about it if you had to drive over terrible sections of road just to get to the places you needed to patch, and there weren't enough other road workers of sufficient skill to ever make enough progress to patch the less critical sections that you nevertheless have to drive over every day?

If you have a choice, you might look for other opportunities, non?

Might want to get out of the field

[russotto]

...because this is like asking how to be a plumber without dealing with sewage.

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

Answer:

[Jimbob The Mighty]

Get into management.

Deciding who to work for

[drew_eckhardt]

>Any other ways to find out code quality beforehand?

Absolutely.

That's what code and test/process reviews are for (there's a lot of latitude in how people have done or attempted to do what they talk about in general terms during your interview).

When I'm thinking about working for a company with existing code I ask for a code walk through, test over view, and demonstration of how the build + test process works.

You do not want to work for anyone who refuses because either they have something to hide or have an ego about how much of their product is "special sauce" that might get bruised if you need to change things once working there.

One of the companies I did this with didn't believe in unit tests and I figured that they'd crater because they couldn't make releases on a fast and predictable schedule with acceptable quality for their customer base. The VCs rescinded their funding for that reason plus the long and unpredictable sales cycle that goes with enterprise appliances which also had me running away.

This isn't fool proof - one company I worked for had good process but abandoned it in a panic when they realized they'd picked the wrong market and needed to pivot. Discussing the false dichotomy of quality and delivery speed (you can have both or neither) with anecdotal stories, delivering much more reliable features with out bugs leading to multiple release candidates built with good process, and having people read things like _The Clean Coder_ didn't help.

In many cases "buy" where buy can mean leveraging free software is the right answer not "build" for things that are not core to product value. You may still find yourself changing and cursing open source.

I also try to avoid that by joining new projects (not fool proof - projects get cancelled when companies pivot, companies often re-organize people to deal with tactical issues, some companies declare your product "finished" and ship it over seas for maintenance after which you join a new in-progress project, etc.) and/or new companies between series A and product design (surprisingly not fool proof - some smart people do bad things when direct to by bad managers. Two of my favorite CEO quotes are "Test code doesn't ship to customers" and "we'll add quality later." That had a lot to do with the resulting crater.)

In general...

[Polo]

Startups = work on the new, reinventing a wheel or ten. Established companies = work on the established, sometimes no creation, buying products instead of creating them.

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.

Kinda puzzled

[the_Bionic_lemming]

I have for well over a decade worked at maintaining legacy code, but I always relished finding the absolute crap applications and redoing them from scratch.

So I am kind of puzzled about the question. What kind of coder avoids jumping in and making something fresh and new and challenging his or her skills to not only replace something craptastic, but make something that his or her co-workers look at and go "Wow"?

My advice

[gman003]

Ask what language the project was written in.

If they say one specific language, you might be good. And don't count "helper" languages - a PHP app that uses SQL counts as just one language for these purposes.
If they mention a few, or one and a few dashes of something else (C with a bit of assembler, PHP with a Python script for one weird bit, C# with a few files of VB.NET), you're possibly good as well.
If they list a large number of languages for one project, run.

There's a project I'm thankfully not fully attached to at work. Long story short, we're a small-ish company that got contracted to rewrite and extend this old product, as the original developers were either fired, or sued, then fired. I only work on the "extend" part, turning what was once a module to integrate into other software into a full suite, but I've heard stories from the guys handling the rewrite. The original devs basically used it as a training ground - any time they wanted to learn a new language, they'd take some feature request and implement it in the new language. So the entire thing is basically written "by beginners", since they never really figured out any of the languages. And there's a lot - a mix of PHP4 and PHP5, some Python, some Perl, some C modules that no longer have source, and I think a few others.

And these are for large chunks. The rewrite actually doesn't stick to one language either, but 99.99% of it is PHP (there's one ten-line Python script to act as a proxy for one thing, and a Java tool that was *supposed* to be just for internal load testing, but the higher-ups adopted it for marketing demos since we apparently beat our nearest competitor by two orders of magnitude).

So yeah. If you see a single application where more than one language is used for more than, say, ten files, you should be wary.

Now, it's entirely possible to have a completely horrendous codebase using a single language, but that's been covered by others.

If it was easy to do, anybody could do it

[pem]

If it's not easy to do, then you should get the big bucks.

The trick is to stay around long enough to reap the benefits of all your good refactoring work. If the software gets better and better, that should show up in whatever metrics management uses (downtime, customer satisfaction, whatever), and then they should pay you even more.

So the trick isn't to look at the quality of the code at the potential job. The trick is to figure out if, at some point, that quality comes under your control, and if you will have a nice work environment and be rewarded commensurately.

I had to Y2K the MMDF source code...

[kfsone]

Uhm, some of the headers had opening comments with dates that would require a negative value unix time...

http://web.opennet.ru/docs/FAQ/network/Mail/mmdf-faq.html

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/

Change Career

[_Shad0w_]

Changing career is the only real suggestion I can make. You're always going to run in to terrible code unless you only work on greenfield projects; and the only difference then is how long it takes for that code to become a terrible nightmare with all traces of design lost to the ages.

Oh and run away from any company that uses the phrase "agile development" unless they can give you a satisfactory definition. In my experience a lot of people use the phrase when what they actually mean is "making shit up as you go along".

Simple. I don't work with any legacy code.

[GoodNewsJimDotCom]

I do this by not working at all.

People whine about this recent bad economy, but for some of us, we can't find a job after graduation since we graduated right after the dot com bust. Only thing I can do is continually try and start home businesses. Here is an example of a game I wrote. I think it showcases I have competency to code effectively. There are a great many people today who are talented, skilled and hard workers, but just due to the economy, there is no place for them to work.

Re:Simple. I don't work with any legacy code.

[DontScotty]

Have you worked at all in any capacity respecting intellectual property?

About the only thing missing from your 'game' is:

http://www.hark.com/clips/bftljkyxzz-needs-food-badly
 

Testing the result

[CBravo]

Ask them how they test the application. Because you cannot change it easily if you worry about breaking stuff.

Quit your job

[ksemlerK]

Work minimum wage for the rest of your life, and quit your bitching. After all, being completely willing to take minimum wage for the rest of your life will ensure that you will never be priced out of the market. Quit your bitching, and so long as you get paid, work for it. I am willing to do anything for minimum wage. I highly doubt I will ever even make $25,000 per year. Do I have goals beyond keeping myself and small family alive? Nope. I will likely die at work on the clock. Dreams are for people who have too much time on their hands. If you have time to "dream", you could be using that time to work and make money. Get a grip on reality, before reality gets a grip on you. "Dreaming" is for college students who have no realistic expectations out of life, and think everything will be handed to them just for breathing. Guess what? You don't get "extra credit" for breathing. Now keep up with the market, and realize what you are worth. Absolutely nothing. You are easily replaceable.

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.

Re:Relish it

[grodzix]

I'm doing that exactly at the moment - maintaining someone else's shit. But what you're preaching sounds a bit like sado macho to me...

The most effective way I've found

[mrjb]

You're not likely to ever avoid any and all legacy code. If you can have some of your own code, you should probably consider yourself blessed.

Distinguish between code that's still "good enough" to maintain and code that's such a horrible mess that you can't live with it. Invariably, legacy systems are poorly documented, but if you can more or less find your way around them, you'll be able to maintain them.

Otherwise, the most effective way I've found around legacy code is to replace it with my own. For small systems, this is fairly straightforward, as in principle you will often be able to re-build them from scratch in a short amount of time (be prepared to put in the work though!) For larger systems, you'll have tackle it a module at a time. Then of course there are systems where you cry out, "Module? What do you mean module?". If a system doesn't seem to have any structure, propose one! Describe the issues with the existing system. Explain to management why they're bad for the bottom line (maintenance costs are higher in a badly designed system). Chances are, you'll get the green light to replace it with something cheaper, if it's worth the investment. Be prepared however to do a fair bit of documenting. If you can't explain to yourself what the existing system does, chances are you'll overlook subtleties when implementing a new one. You may well find out that once you've documented the existing system far enough, it's at least maintainable (see above: "good enough").

For what it's worth, it helps to have some sort of toolbox that allows you to quickly whip up small systems. In my experience, companies are often willing to replace bad software if it takes up to a few weeks, but not if it takes months.

Can't even be a pretentious cock properly

[Hognoxious]

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

Proportional to the quality.

Except it's bollocks, because neither "variable" is quantifiable in any physical or mathematical sense, so applying such precision is so exponentially retarded it literally makes me laugh my tits off.

Get over IT.

[upuv]

We all want to play with the cool stuff. But to be honest you will absolutely have to work with legacy.

A really good designer/programmer/architect can not only work with the legacy but can actually design/implement a path where the legacy is deprecated out of existence. A bad programmer/designer/architect ignores it and lets it fester. The guys that get the big bucks consistently are the ones that move things forward. The ones that only will work with the cool tools/toys tend to bounce jobs and provide little over all value.

So in essence. SUCK IT UP.

Nope, work for a place with juniors

[SmallFurryCreature]

I am once again stuck working with crap legacy code that is even crappier because all the installed versions for different clients are custom tailored (read: totally different meaning you are support 12 application instead of one where they all share the same bugs but can't be fixed with the same patch).

And I have started to notice something, and shot down a recruiters suggestion just a few minutes ago because of it. If a place only has seniors, it means the code is a mess. Trivial changes should be done by juniors if trivial changes can't be done by juniors, it means the code is a mess. Usually a mess created by making fantastic code that really showed off a coders skills but in the end is just spaghetti code were to much happens in one place for anybody to easily read the code and find the place that a fix should go.

If you played Transport Tycoon, you can see if you can write non-nightmare code. Did you create a interconnected network of trains where you tried to get the max number of trains to run on the least amount of track and dreamed of a sequel that would give you better router options?

Or did you just create nice simple separate routes with just 2 stations and at most a dual track to create a circular loop so your trains never got lost or stuck?

One is the code genius solution, the other creates code that is easily maintained. Go and play the game, create both type of networks, then alter a route. In the first, you will have to deal with countless problems as all your train routes collapse and first directly affected trains get lost and then become stuck creating troubles for your entire network. Just like in complex rail networks in real life like in Holland.

But on the kind of network you computer opponent builds with just 2 stations and trains running between them, you can easily dig up a route and redesign it and the rest of your trains continue to run their separate routes.

Juniors often lack the ability to deal with code where a tiny change here might cause something to break there. That is what seniors are supposed to be good at.

Consequently, if a company only employees seniors, they got spaghetti code.

I have been working on a wiki page to get my brainfart that MS original trouble with getting MS Office out the door, called development hell, has bastard brother in maintenance hell, where you are stuck repainting the preverbial bridge but the previous painters left such a mess AND are still doing it you never even get to painting but once you cleared the bridge of the mess the previous painters left behind, they started leaving a mess at the other end again. And if the bridge never even gets started painting, you can forget about structural maintenance.

At one company, disastrous code had been upgraded to a condition described by the developers as "stable". Stable as in how doctors use it to describe a patient in emergency care which really means "patient can now be moved for serious surgery without it killing with absolute certainty". Management thought stable meant "perfect health". It wasn't. Management planned a host of new features, we were to busy trying to keep it from falling apart on the spot.

Maintenance hell is real and it happens when your code has become so bad, that SCRUM is impossible because SCRUM MANDATES that you have your bugs under control. How can you after all estimate a project when any chance you make is going to open most certainly a can of worms but you have no idea how big or just how lethal the worms are. Maintenance hell is when only the developers who made the dev in the first place can not quite maintain it and then they leave and any new developers you hire burn out in six months and you start to accept that people only will become productive after six months studying the code.

So, questions to ask: Spread of Junior/Medior/Senior developers and... why are their existing developers leaving. Usually you can already get pretty good idea of the company by going into the history on job boards. Every 6 months they are looking to hire a senior (In holland it is standard to start with a 6 month contract)... maintenance hell, they are replacing their burned out sucker eh, developer.

Ask to see the code.

[Lord Bitman]

Offer to sign an NDA, but don't ever take over someone else's codebase without making sure you see the code.

Employers: Don't hire anybody who offers to take over someone else's codebase without having seen the code.

This is a complete no-brainer.

Learn to love maintenance

[benjfowler]

Maintenance tasks are a bit harder to outsource than greenfield development.

Not to mention the fact that it takes a different set of very useful skills to maintain and debug code, especially poor quality code. There are serious benefits to seeing what's good and bad, what works and doesn't; how to comprehend other people's code (yes, it's a lot harder to read code than write it); how to debug intelligently, and how to profile code. These skills are hardly ever taught, and have to be learnt on the job.

Don't begrudge being 'stuck on maintenance': it takes a lot more skill to read and rework old, crappy code, than it is to write new greenfield code. Just make sure that you're given enough time, resources and "creative freedom" to introduce beneficial changes, like unit test coverage and continuous interegration (I won't work for anybody who "doesn't have time to write unit tests", because it betrays a dangerous level of cluelessness.)

Re:Learn to love maintenance

[dkleinsc]

That's a very very good point.

Here's how I deal with really badly written legacy code:
1. Pick out a particularly bad chunk of legacy.
2. Add a complete set of unit tests. "Complete" means that each potential execution path of whatever you're testing is covered.
3. Refactor it to your heart's content, until it doesn't suck quite so much anymore.
4. Your tests still pass, right?
5. Move on to the next-worst chunk of legacy.

If you are required to make a modification to horrific legacy code, try this:
1. Add the complete set of unit tests again.
2. Create a simple hook in the bad legacy code to call your awesome new code when appropriate. That way, you aren't adding much to the mess.
3. Add your new feature, with appropriate tests.
4. Refactor the horrific legacy code so it doesn't suck anymore, and incorporate your new feature.
5. You're tests still pass, right?

I quite like the challenge

[cliveholloway]

I might be in the minority, but I've learned to love the challenge of taming a beast of a code base.

Coming in and helping out people who don't have *anything* in place and slowly adding order has a satisfaction level all of its own.

Building out a test suite as we document business logic and then planning a refactoring can be rewarding too!

Re:any questions? Bad code is good!

[hughbar]

I agree that bad code is the norm. My recent experience was a large Perl codebase, belonging to the merger of about four different companies that did the same thing but [of course] had different business processes. The code was in the gigbyte range with tons of templates and about four foreign lanugage versions.

However the code base covered many corner cases in the business model, pricing and marketing and [in the main] worked.

Thirty odd years of experience has shown me that a re-write of something like this is usually a disaster, I agree with Joel: http://www.joelonsoftware.com/articles/fog0000000069.html

The least-worst way is rolling reviews through sections of the system and a very comprehensive set of regression tests. But the point is that, at some stage, one will have to engage with 'bad code that works', it's the way of the world.

Ask questions and expect answers

[Alkonaut]

The use of modern tech does not imply better code, but it certainly helps your work environment. A company that is quick to adopt new technology (e.g. Update to new language versions) has a better possibility than a company that doesn't. Make sure you talk to the guys involved with the technology. Interviews and screenings with recruiters are quick affairs, save your questions until you meet real developers. If the company doesn't have the actual developers and team leaders doing interviews, that is not a good sign. Third, make sure you find out how fast the crew is being replaced. A team of ten should have at least a few that have been there virtually forever, and you don't want to join that team if it has recruited 20 developers over the last 5 years. This is the most important thing: you want the same as every other developer out there. So a company where people work 1-2 years either has a technology problem or a serious pay/environment/cultural problem. Either way, you don't want it. Ask how many have left the last few years, and try to find out why. If you can't get this information, leave.

Software engineer?

[tehcyder]

If you're working with other people's crappy code you're just a programmer. Get over yourself.

Legacy code

[Murdoch5]

The first thing I do when ever I sit down to work on old code that I haven't developed is to comment every ( or almost every ) line of code. Once I fill in all the comments I can get a much better sense of what the developer was trying to do and in some cases fix those awful blocks that almost stun the mind. The second thing I do is upload the code to a SCM system like GIT and then fork it so I'm always working off a separate branch. Beyond that I just usually need a lot of coffee, a few good cigars and loud music because lets face it 70%+ of old code is beyond the state of crap.

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.

Change the languages you know

[Skapare]

Don't list any old legacy languages on your resume. Only list the latest ones that you actually know and want to work with. You'll get fewer offers, but what you do get should be higher quality.

Ask Slashdot: How To Avoid Working?

[SouthSideNick]

Fixed it for you. Seriously though, carry on being a prima donna. It makes finding work that much easier for me.

Code and Model Quality

[prefec2]

Legacy systems ran for a long time (normally). That's why you get the job. The shit has to be ported to a new platform, features have to be added etc. Legacy systems are long lived or long living systems, therefore a lot of people laid their hands on it, which results in crossover styles in programming which results in bad code. Therefore:
  * The older the code base, the worse the code
  * The higher number of transitions (migrations/feature changes) of a code base, the worse the code
  * The less real documentation exists, the worse the code
  * The worse the programming language, the worse the code
      C,C++,Perl,Fortran 77, Cobol, Fortran 4, PL/1, Assembler => bad, worse, unmaintainable, even more unmaintainable, are you kidding me, we hit mars period, it talks back and WTF.

So you can conclude a formula from that: (1/code_age)*(1/(transition_counts+1))*documentation_quality*programming_language where documentation quality is defined as 0 no or bad documentation and 1 perfect documentation and programming language is defined as WTF/assembler=0 and C=0.5 (Languages such as Erlang, Haskell, Scala, Java, C# get higher marks).

A value 0 zero indicates great mess, while 1 indicates nothing to worry about. While most legacy systems are implement in the range between bad and WTF, you will never get more than 0.5 out of it. As documentation is even in new projects not really existent. They produce a lot of paper, but there is nothing in it. So you can say you get not more than 0.5 for documentation quality. As most projects are more than 10 years old, you get 0.1 for age and at least 2 transitions so 0.25. So my best value would be 0.5*0.5*0.1*0.25 = 0.00625 or the quality is below 1%. You normally get an F (or 5/6) if you are below 50%. So it is easy to conclude:

All legacy systems suck. Ah and yes, and you should get used to it.

hmmm

[buddyglass]

Most recently I had the opportunity to serve as the sole Android developer in charge of some pretty terrible existing code. Since I was the only Android developer and, indeed, the only person at the (small) company with any knowledge of Android whatsoever (i.e. there was very little oversight of my activities and, since the existing app was so terrible, very low expectations), I just rewrote all the really abysmal parts from scratch. Taking a slow, buggy, visually inconsistent app and making it fast, robust and visually consistent was fairly gratifying.

Are you that freakin' lazy???

[johnlcallaway]

I make a damn good living from working on legacy code. Bad legacy code. Really awful legacy code that no one else will touch. I was hired at my current job 5 years ago specifically because I am very skilled at taking very bad code and either completely rewriting it, or picking at it to find the parts that need to be fixed and fix them. I've spent the last 5 years taking C++ code written by a librarian (yes .. you read that correctly) and rewriting it in Java (bosses requirement, not mine) to make it run faster, rarely abort, and actually produce meaningful messages if it does abort. Code that we don't even know if the current source code matches what is in production, so we can't really even make changes to it. We rewrite it, then parallel test to make sure. (There were many reasons to rewrite it, and it wasn't my decision. Although I agreed.)

It takes a lot of skill to be able to read code that is 10 years old or more, has no documentation, and is so full of unnecessary convolutions and nonsensical algorithms and make sense of it. There are a lot of companies out there that are tired of hiring programmers who later on won't work on something because it's too confusing or too hard. You know .. the lazy ones that are really just not skilled enough to be able to do it.

Sure, I love to work on new stuff. But instead of whining about how hard and difficult it is, accept the challenge and wear it proudly, knowing that a significant number of your peers couldn't do the task.

And the best part of working on old stuff?? It's really difficult, so it takes time. And since no one else is working on it, they have to take your word for how long it takes to get it done. Now, I don't sit around all day in slippers sipping coffee and writing a few lines here and there. But I also don't put in 60 hour work weeks. And I'm probably getting paid more than a lot of you. (Hint .. my yearly wage has 6 digits to the left of the decimal point, and the first two aren't zero.)

oh come off it..

[SuperDre]

TDD is great but it isn't the solution, new technologies aren't really new, a lot can also be done with older.. The biggest problem today IMHO is that the so called new technologies run like crap on modernday computers, you have to have a highend to get the same performance as with the old technologies, well that says to me that new technologies just plain suck and are especially for lazy developers.. Computers get faster but applications get slower, hmmm, that's wrong IMHO.. And remember, it's not like 'new' code is better than legacycode, I've seen 'new' code which is much MUCH worse as old legacycode.. especially since it seems a lot of people tend to forget to comment their code.. And please, don't give me that crap 'good code is easily read' as 'crap code is also easily read' because 'good code' is only 'good code' in the eye of the beholder..

HEY! don't be dissing my code...

[bodland]

I made millions off that...

Do "best" practices - better code?

[DavidHumus]

I'd be interested if the OP had a feel for whether adherence to certain practices does, in fact, result in a better codebase. Personally, I'm skeptical that they do, even though I think that some of them are probably Good Things to Do, simply because they might help.

Don't avoid crappy code: embrace it!

[mikein08]

Crappy code can keep you very profitably employed for a very long time. After all, the object of the game is to make as much money as possible in as short a time as possible, so that you can retire early. This strategy worked very nicely for me. You just have to learn to stop hating your job and employer.