Slashdot Mirror
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?"
It's you. Stop being such a prick. The next guy hired to clean up your mess probably says the same things about you.
If the company relied on one programmer to handle everything, beware.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
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.
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?
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.
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.
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.
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.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
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.
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.
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".
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.
"If you are going through hell, keep going." - Winston Churchill
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.
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.
I am John Hurt.
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.
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.
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.