Ask Slashdot: How To Avoid Working With Awful Legacy Code? 360
kramer2718 writes "I have worked for about a decade as a software engineer. I am almost never hired to build new software from scratch, so my work satisfaction tends to be proportionate to quality of the legacy code I have to work with. Some legacy code has been good. Most of it is bad. I know a few questions to ask during an interview to determine the code quality: Are recent technologies used? Are there code review processes? Is TDD practiced? Even so, I still encounter terrible quality code. Does Slashdot have any advice for other questions to ask? Any other ways to find out code quality beforehand?"
any questions? (Score:5, Insightful)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
.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: (Score:3)
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: (Score:3)
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 [oracle.com]
Before that, Microsoft had a "sample" that you could compile to access Oracle throu
Re: (Score:2)
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: (Score:2)
Re:any questions? (Score:5, Interesting)
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: (Score:3)
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: (Score:3)
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 con
Re:any questions? (Score:5, Insightful)
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: (Score:3)
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 ta
Re:any questions? (Score:5, Interesting)
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: (Score:3)
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
Re:any questions? (Score:5, Insightful)
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: (Score:2, Insightful)
>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: (Score:3)
Re:any questions? (Score:5, Insightful)
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: (Score:3)
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: (Score:3)
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
Re:any questions? (Score:5, Insightful)
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: (Score:3)
Re:any questions? (Score:5, Insightful)
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: (Score:3, Insightful)
Re:any questions? (Score:5, Insightful)
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? (Score:5, Insightful)
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? (Score:5, Informative)
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? (Score:5, Insightful)
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? (Score:4, Interesting)
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: (Score:3)
"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 tak
Re:any questions? (Score:5, Insightful)
Re:any questions? (Score:5, Insightful)
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? (Score:5, Informative)
"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? (Score:5, Insightful)
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? (Score:5, Interesting)
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? (Score:5, Interesting)
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? (Score:5, Insightful)
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? (Score:5, Insightful)
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: (Score:2)
The employer will look at the candidate's employment history, why shouldn't he look back?
Re:any questions? (Score:5, Insightful)
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: (Score:2)
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 happ
Re:any questions? (Score:5, Insightful)
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: (Score:3)
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.
It's not the code (Score:5, Insightful)
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: (Score:3)
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 no
Re: (Score:2)
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.
Simple, ask directly (Score:2)
one question (Score:5, Insightful)
Re:one question (Score:5, Funny)
10 print "Yes we do."
20 print "You're looking at it."
30 end
Re:one question (Score:5, Insightful)
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 (Score:5, Insightful)
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: (Score:2)
Re: (Score:2)
for (var never_use_this=0;never_use_this>100;never_use_this++) {
print "oh, no\n";
}
Re: (Score:3)
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 cod
You want to avoid legacy code? (Score:5, Insightful)
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: (Score:2)
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, bu
Re: (Score:2)
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 y
Re: (Score:2)
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 c
Re:You want to avoid legacy code? (Score:5, Insightful)
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: (Score:2)
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? (Score:4, Insightful)
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: (Score:2)
You seem to have missed the key adjective "awful" in the title/question.
Re: (Score:2)
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 abou
One warning sign: (Score:5, Insightful)
Re:One warning sign: (Score:4, Interesting)
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
Simple answer (Score:2)
Work for a startup that has no legacy code.
Re: (Score:2)
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 b
My favorite question (Score:5, Insightful)
Legacy Code is not the issue here (Score:5, Insightful)
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: (Score:2)
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.
doing it wrong buddy (Score:2)
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. (Score:2)
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 mat
Re: (Score:2)
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 (a
Charge by the Hour (Score:4, Insightful)
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: (Score:3)
Does it matter? (Score:4, Insightful)
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.
Get an MBA (Score:5, Insightful)
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: (Score:3)
Re: (Score:3)
So first thi
All Code Is Shit (Score:4, Interesting)
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.
Quit and find a new job? (Score:2)
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? (Score:3, Interesting)
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...
.
What is it exactly that you do? (Score:2)
Critical question... (Score:2)
Does the Architect own a tanto? Has been required to use it?
Like a plumber that doesn't work with S41t (Score:4, Insightful)
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... (Score:2)
Get a promotion (Score:2)
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 behin
I'm surprised at some of the responses (Score:3)
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: (Score:2)
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.
Don't avoid legacy code (Score:4, Insightful)
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.
Awful code (Score:4, Funny)
Don't whine.
Don't use TDD.
Don't assume use of modern language features yield better code.
http://xkcd.com/610/ [xkcd.com]
Relish it (Score:4, Insightful)
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 (Score:4, Insightful)
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.
Re:Careful with that axe, eugene. (Score:5, Insightful)
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.
Re:no (Score:4, Funny)
Re: (Score:2)
The odds of that working are astronomically low. They probably don't want you personally that badly.
Re: (Score:2)
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.
Re: (Score:2)
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?
Re: (Score:2)