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

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

Comments

any questions?

[yagu]

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

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

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

Re:any questions?

[Stiletto]

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

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

Re:any questions?

[Anonymous Coward]

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

Re:any questions?

[Anonymous Coward]

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

Re:any questions?

[erp_consultant]

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

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

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

Re:any questions?

[SolarStorm]

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

Re:any questions?

[19thNervousBreakdown]

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

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

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

Re:any questions?

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

[Rockoon]

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

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

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

Re:any questions?

[lightknight]

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

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

Re:any questions?

[Anonymous Coward]

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

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

Re:any questions?

[lightknight]

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

Re:any questions?

[lightknight]

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

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

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

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

Re:any questions?

[czth]

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

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

Re:any questions?

[Anonymous Coward]

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

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

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

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

Re:any questions?

[SplashMyBandit]

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

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

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

Re:any questions?

[purpledinoz]

Bad code is bad code whether it is old or new

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

Re:any questions?

[Ash Vince]

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?

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

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.

one question

[j00r0m4nc3r]

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

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.

You want to avoid legacy code?

[dougmc]

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

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

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

Re:You want to avoid legacy code?

[hawguy]

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

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

Re:You want to avoid legacy code?

[phantomfive]

I think his complaint wasn't that it doesn't work, it's that it's hard to work with and a pain to understand.

And this is unfortunately true of almost all code, no matter how well written. Coding is hard, and if you have 100,000 lines of code, it's going to take a while to figure it out.

One warning sign:

[Sheetrock]

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

My favorite question

[stanlyb]

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

Legacy Code is not the issue here

[Grail]

How about you fix you?

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

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

It is a matter of perception & expectation management.

Charge by the Hour

[dmomo]

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

Does it matter?

[kiwimate]

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

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

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

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

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

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

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

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

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

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

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

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

Does Slashdot have any advice for other questions to ask?

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

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

Good luck with that.

Re:Careful with that axe, eugene.

[hawguy]

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

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

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

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.

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.

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.

Relish it

[countach]

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

design document and automated QA system

[John_Sauter]

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

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

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

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