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?

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

[hawguy]

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

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

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

Re:any questions?

[erp_consultant]

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

Re:any questions?

[Rockoon]

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

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

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

Re:any questions?

[lightknight]

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

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

Re:any questions?

[lightknight]

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

Re:any questions?

[lightknight]

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

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

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

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

Re:any questions?

[czth]

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

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

Re:any questions?

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

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

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

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

[Anonymous Coward]

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

Re:any questions?

[FictionPimp]

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

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

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

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

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

One warning sign:

[Sheetrock]

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

Re:One warning sign:

[Anonymous Coward]

Been there. Caused that. Was the lead programmer.

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

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

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

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

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

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

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

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

Of course I got his job.

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

main_system.php.2012_10_13_v5
main_system.php.2012_10_13_v4 ...

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

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

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

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

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

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

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

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

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

My favorite question

[stanlyb]

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

Legacy Code is not the issue here

[Grail]

How about you fix you?

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

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

It is a matter of perception & expectation management.

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.