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?"
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.
It's you. Stop being such a prick. The next guy hired to clean up your mess probably says the same things about you.
no. you cant determine the code quality until you look at the source code, unless you are talking with another programme
Ask the questions you are talking about. Phrase them as ways of showing your background in those areas. Ask what kind of standards they follow, so as to see if you know them. Ask if they are maintaining legacy code, to show you have experience. If the answers are too much for you, move on.
You're interviewing them as much as they're interviewing you. Ask to sign an NDA so you can examine their code base to see if you actually want to work there.
"Do you have a code sample I can look at?"
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.
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.
Ask the dev interviewing you what they think about their code base? Maybe ask them outright if their code sucks? I do that.
That's what I would go after... if you only have the "old guys" then the environment is usually not something I would enjoy - too much inbreeding of ideas, no new technologies and such... Not necessarily bad code - just outdated. If there are only junior people there, then its a mess, nobody has the needed experience or a vision of a better future.
All decent code bases I ever touched in a commercial environment had a few older guys that stuck with the product cause its stable, easy work and a few newer guys because its a easy to learn, guided environment...
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.
Work for a startup that has no legacy code.
"To those who are overly cautious, everything is impossible. "
With the economy being the way it is, you're being picky about the quality of the code you work with? Either you are good enough that you can pick and choose your jobs or the world is going to give you a reality check right in the nutsack.
Remeber, half of coders are below the mean (and more than half are below the average).
Recent technologies doesn't mean that it is good code.
f2c is great code but it is not new technology.
Some of the best stuff is just plain ANSI or even K&R C
(Some of the functional languages are good if they are using them they probably know what they are doing)
If you are a professional programmer, you will deal with legacy code, that's part of the job. It takes getting used to. The difference between a hobbyist programmer and a professional is no longer technical skill, since even hobbyists can learn amazing and difficult things from places like Wikipedia. The difference is that the professional is comfortable and capable of working in group projects and dealing with mountains of shitty legacy code. It really comes down to that.
Seriously, your own code becomes "legacy code" at about the point it isn't fresh in your head any more. Maybe that's as recently as 1 month after you write it, maybe it's longer, but if you're going to be a professional programmer, you need to accept the fact that maintaining legacy code is part of the job.
there are some red flags, first one is you are the only one working at this particular Project and no one else around knows anything about the internals, another red flag is if it is written in a framework like struts, JavaBeans, or a very old websphere, another warning is if the Project is not under any source control system, or if it is driven by a cmmi process.
your questions are not very good since code review is not important, TDD often drives awful code, more important is that the codebase have a sane build process, good versioning and is simplistic in its design, too many layers and the thing spirals down quickly.
Fnially is very important you can test your code in your own machine, very often you see that the software can't be quickly tested and depends on systems/databases not available in your work environment.
Do you use CVS? Any kind of? No?.....
If they have a culture where the developers are allowed to focus on code quality, then if it's "bad code" (as subjective as that term is) you'll have a shot at fixing it. Code quality is a result of developer experience and the required development pace; the worst situation you can be in is where 100% of engineering time is spent on feature development and bug fixes, with no time allotted for maintenance work.
But like a poster above said, if you really are just sick of legacy code, work for a startup; that's what I did.
If you are getting consistent compiler warnings about deprecated calls then considering a rewrite is in order. That is provided you still have the original code and are not just reusing old binaries. Legacy binaries without access to the source is a part of the problem. Sometimes the old saw "if it ain't broke don't fix it" can come back to byte you.
Don't use Windows. Duh
Find a job where you get to write code from scratch. Amidst all the changing requirements, last-minute fixes, impossible deadlines, and lip-service paid to best practices, you'll quickly meet the enemy, and he is you.
You may come off as sounding like not a team player or whiny. Probably the old code was written or maintained by the interviewer, you do not want to offend anyone if you are serious about the job.
Sound intelligent and turn your questions about what you are working with and trying to turn it into a plan of how you can hit the ground running and keep doing the job in question for years. Usually if you are hiring you dont want someone who is going to sit there and whine about legacy code for years.
You can justify your questions about how old and how much time it takes to maintain by saying that you are thinking of how to make things better by seeing where things are at right now. Draw on past experiences and quantify what you have achieved, eg.. 20% less support tickets or x hours less a month doing ..
Just dont sound like a whining know it all... /shrugs.
I have been coding for almost 20 years. I've been hiring people for a good part of that time.
Most employers reward their tenured developers with the new projects. The reasons are not always perfect, but, the simple answer is that they cut there teeth on legacy code, they understand the requirements, and they should know the pitfalls to avoid. If you are moving around a lot, you will find it more difficult to work on new stuff.
That being said, most companies want to put their best person on the job. If you have tenure but never showed initiative, dedication and team work attitude, you will usually be looked upon as not interesting to the leaders who are trying to show management that they have e right people to carry out a new project. After all, a new project is a risk to management that you are mitigating with proven people.
There are times you bring exactly the right experience to a company and you get fast tracked. New teams sometimes need entry level type devs to fill in to write he muck code. Or you get into a startup. These tend to be why people get the fun stuff right off. But most likely, they want you to prove yourself and understand the problem before you get the reward of new development.
Duh.
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.
"Define Technical Debt."
"Define 'refactor'."
"How much time does your team spend on technical debt?"
"Tell me about a few times where the main focus for the product changed direction?"
"Tell me about a major refactoring your team recently did."
It doesn't matter where you go, start-up, long-time corp, self-employeed. If you wrote it and moved on to another project or maybe even a different part of the same project when you get back to it, it's legacy code. You think you wrote the perfect chunk of code but when you get back to in a month with a new perspective you'll be wondering "why'd I write it this way?"
The only code that is not legacy code is the code that has yet to be written.
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.
-Lod
No one likes dealing with legacy code. Any given developer has had to sit down and wade through code that's some combination of poorly designed, undocumented, non-functional, over-engineered, slow, tedious, failure prone and in all other ways apparently designed only to make your life some sort of hell of bleeding eyeballs and migraines - and that's just the code they wrote 3 months ago. Other people's code is worse.
Having written code for nearly 2 decades now, what I can tell you is this: It doesn't matter much. We all want to live in a land of beautiful code - if we didn't, we wouldn't get so upset when we see horrible code. However, the end game is: does it work? Yes, you want to wipe it out and start from scratch, and yes, it'll be a joy to work with after that (until the next guy shows up), and yes, it takes forever to make a change, and yes there's no unit tests, and yes it's loaded with bad hacks - but for a business the real questions are "does it work?".
If the answer is 'yes', you're fighting an uphill battle to correct it. If you are lucky enough to be able to put a cost on it - time or dollars - that could be saved by refactoring, then perhaps you have the ammo required, but if you can't give a realistic metrics-backed analysis of it, then there's no business need to fix it.
Think about that for a bit: The need to fix it is not based on how broken you perceive it to be, but on entirely separate measures of no worth to you that require discrete and specific values.
(Besides, if you spent that time analyzing, now you know the system pretty well, so you're the new expert!)
More realistically, there's always going to be a next, new thing that needs to be built. If you spend all your time fixing problems that aren't 'too' broken, you'll miss all the chances you'll have to work on the new stuff, where you don't have to work on legacy code at all!
So the advice to you is what all good programmers should hate to hear, but know in their hearts to be true: Spend as little effort on it as possible, and move on, until it becomes a large enough problem that it requires attention, not just deserves it.
Oh - and if you have a good dev manager, ignore all that. Tell him it needs to be refactored, let him work out the priorities and schedules, and you're set. Also, while you're visiting Fantasy Island, tell Ricardo Montalban that he was awesome in Star Trek II.
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.
Ask how much of the work is legacy vs new development.
Ask how long the product has been live.
Ask what the top 3 issues are with their existing code.
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.
This question is good because, code is only good if companies can see the financial benefits of investing in it.
If their answer to "Why do people use your software?" is something like:
"Well, customers use us because we have local support people! we are also cheaper than any other local competitors."
Then you just know you will encounter bad, legacy code. In an ideal world, they would answer...
" Well, we face a lot of competition and keeping ahead is expensive. But, our software is the best. because we understand where we add the most value and focus our efforts on those areas. We are defiantly not bloatware!".
"I am almost never hired to build new software from scratch, so my work satisfaction tends to be proportionate to quality of the legacy code I have to work with." This statement makes absolutely no sense. Your job satisfaction should not be solely dictated by the amount and perceived quality of legacy code you are so "forced" to deal with. Working with existing code is a fact of life in this industry, get used to it. Instead of figuring out how to get around it by asking sneaky interview questions, learn to live with it. Also, why beat around the bush? Why not just ask the interviewer "How clean is your current codebase and how steep is the learning curve"? If they give you a sketchy answer... well I'll let you figure that out. I read this post and I think: "Maybe this guy chose the wrong career".
Strangle your boss. Take over his company and write software from scratch. lol
Step 1: Avoid any and all circumstances where you have to modify shell scripts that dynamically build batch-processing scripts run through Peoplesoft SQR.
Step 2: There is no step 2.
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.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I'm road worker and I often repairing spotty patches. The thing is, I'll only work on pristine roads. Makes sense, yes?
...and I make loads of money with it because it all works. You should focus your interview questions on the company's design and quality culture. I do appreciate clean, elegant, standards conforming codebases, but that's all academic exercise for the programmer. Users could care less as long as their software works the way the need/expect it to. Maintainability is important, but not as important as user experience. If the software does what users need it to do it will require *less* maintenance. Also, forget newer technologies because that just isn't important at all. Good projects use the *right* tool for the job despite current trends. Yeah, the stuff we have now is boatloads better than last decade's stuff, but you can still create useful software in FORTRAN or C. I stopped caring about code style when Sun first opened sourced Java. That codebase was barely readable but millions of people were happily using it. The fact is sausage tastes great, but the consumer *never* needs or wants to know how it's made. Ok, one step further here and some advice from a 25 year software trenches veteran: learn to appreciate and admire bad code. Learn to view it as a challenge presented to you so you have something to do to earn a living. Adversity is the avenue to opportunity.
Look, if you just want to be able to only write fresh stuff, you're useless. Your new code will become "legacy" code next month. Requirements are likely to change, or at least be refined. This is because project managers are not prescient and nobody ever really understands the real requirements until an alpha gets put into the hands of the end user.
It won't be long before you're going to have to go back and deal with the turds you yourself are crapping out. You might not think they're turds, but they are. That's because you're not prescient either. And if you spend too much of your energy striving for the most elegant, perfect code, then you're also constipated.
You're a better engineer if you can effectively reverse engineer other people's turds and polish them up a bit. If you can somehow find within yourself the ability to feel a bit of pride in addition to the disgust of dealing with other people's crappy code, you'll be happier in your lot.
You haven't made your bones as a programmer until you've spent five minutes cursing the idiocy of a programmer that came before you, whose crappy code you are having to fix, and then you look up the revision history to see who the offender is and discover that it was YOU.
Fun with Anagarams! LADS HOST, SHALT DOS. HAS DOLTS. AD SLOTHS, HATS SOLD. ASS HO, LTD.
Seriously...
System Operations is the art of keeping code running that should not be.
Ask them what is the crudiest and crustiest "module"/"unit"/"library" that is a part of their code. Then ask them to describe it and how they deal with it. If they claim there isn't one, then you know they are lying and head for the hills. If they can't think of which one is the worst then that spells trouble. Otherwise the answers to the question tell you a lot about the company. Also ask how they deal with regressions.
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.
You COULD ask to see their "Life Cycle Management" documentation folder(s)
IMHO... If they don't understand the question you're probably going to want more money...
One of my former students called me years back with the announcement that the brief (two hours or less) "Life Cycle Management" addendum I'd made to the Systems Development/CASE class I was teaching got him a promotion to a senior analyst position... That was the one area that none of the other candidates could discuss...
Apparently it wasn't something that everyone was teaching as part of the process of developing maintainable code and data structures...
My NOT being a full time programmer OR teacher might affected how strongly I've felt it necessary to include that subject.. but whenever I've had to go back to a former project... having a fully documented system has kept me from the necessity of reinventing the wheel...
.
You need to see it beforehand.
Anything other than that is assuming the people that wrote shit code won't lie to you. They will.
At least ask them what architecture and patterns the code adheres to and ask to see the internal standards the code was written to.
WTF does TDD show? You can write a system that completely does what it should do with TDD and everything is fucking different which is the main part of shit code. I'm not saying TDD is bad, I'm saying that it doesn't show the quality of the code.
All too often, this is true:
"Awful Legacy Code" = Code One Didn't Write themselves and don't want to take the time to learn, to be shit-talked as much as possible so one gets to reinvent the wheel.
Here's a novel idea. Write good quality code yourself, and stop job-hopping.
Are you taking jobs where you have to channel the previous developers and write code indistinguishable from them? do your jobs involve just transcribing someone else's crappy code char for char like some 14th century monk? Or, do you get to write code? I've supported plenty of legacy code. In all occasions that involves me, writing code. Optimizing, bug fixing, refactoring, adding new features (i don't know what else you could possibly do to legacy code) all involve writing code. So man up and write good code.
Does the Architect own a tanto? Has been required to use it?
That's just an axiom of engineering. You can craft the most beautiful, standards-compliant, pattern-invoking code ever and the next engineer to come onboard will see it as a legacy, stove-pipe, monstrosity that needs to be re-written from the ground up. Of course, his rewrite will just repeat the cycle.
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.
Instead of asking what job will give me happiness, why not ask, "Who shall I be, that I will be happy in my work, regardless of circumstances?"
What if you created a relationship to your word such that you let no feeling, situation or circumstance abrogate it?
What if your word was that anywhere you chose to work would be exciting, challenging and overflowing with opportunity, because you will bring that to your job?
What if your whole life worked that way?
It can.
Shut the fuck up and stop being a fucking pussy. Jesus fuck, go kill yourself.
Unless you hop from startup to startup, you'll have to deal with legacy code at some point, either someone else's or your own. Here are some indicators I came up with (warning: a lot of broad generalizations follow; they don't always apply):
1) "was the code base developed in-house?" in-house developers generally have a deeper understanding of the requirements, resources, and the company. Some contractors do just enough to meet the requirements so that they can get paid and move on to the next project. Quality is generally higher when someone has to maintain the code and/or face their peers every day in the office.
2) "how many projects are developers involved in at once?" if a developer has to juggle more than a few projects at once, one or more might not get the attention that is needed to be of the highest quality. Conversely, if someone is just focused on one project, the quality might be better due to their deeper commitment to the project and understanding of the internals.
3) "what's the employee turn over rate?" your experience is likely to be less awful if the original author or authors are still around; they can at least explain some of the reasoning behind the design decision. Conversely, if the original designer is long gone and many people have dabbled in the code, the quality might suffer due to developers having different ideas about how to best maintain the code and different understandings of how everything fits together.
4) To follow on the "Are there code review processes?" question, you might want to ask "how is performance evaluated?" It's a good question to ask in anyway, and that might give you an insight into how much oversight there is of a developer's work quality.
Also keep in mind that you need to strike a balance between beautiful code, functionality, and time/cost. Sometimes less elegant code is more maintainable, takes less time to develop (i.e. costs less in labour), and does the job well enough.
... is to be an employee with a single-digit employee number in a start-up company. Beyond that, you will have to deal with the Big Ball of Mud. Deal with it.
I haven't been in the industry for ten years, or even near it, and I know that unless I'm being hired specifically to create something new I'm going to be working with existing code. And I've worked for some very, very small companies where the code I'm working on has been written by people who've been short on time and resources. It's looked like total butt. It's been slapped together with bubble gum and bailing wire, and I've done my best to leave it better than I found it for the poor sap who comes behind me. Unless you're being hired to create something new, you'll be working on something old. You're probably being hired to fix what they've already got. Why would this surprise you?
Seriously, if you don't want to work on existing code, look for jobs where you're being asked to develop something from scratch. If the code worked great in the first place they wouldn't be looking for someone to fix it, would they?
This unbiased moderation brought to you by the Porcine Aviation Group!
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.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
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?
Can you be Even More Awesome?!
The best indication I've found regarding code quality is how they feel about deadlines and overtime. If they believe in taking the extra time to do it right and not working weekends, you might get good code. If they say "Get it in for the deadline and fix it later", you know they never actually go back and fix it.
If their answer is, "Deadlines are deadlines. You gotta do what it takes to get it done", in my experience it means they use unrealistic deadlines to try to drive productivity and force people into working unpaid overtime and the code is nearly unmaintainable.
As long as the vast majority of code is written by those with the least experience and training (and lowest salaries), bad code will be abundant. As long as those with the most experience and training (and salary) work in supervisory roles, coercing the coders to get it done yesterday, bad code will be abundant. As long as technologically illiterate (and in some cases just plain illiterate) executives drive the whole process, bad code will be abundant.
The moral of the story is: Get used to it. If you can't navigate your way through the sloppiness, laziness, carelessness, and muddy thinking of your predecessors, you're in the wrong line of work.
...because this is like asking how to be a plumber without dealing with sewage.
Ask them how well they score on The Joel Test (see also this post with some suggested updates). This won't necessarily teach you about how much legacy code they have floating around, but it's a useful barometer. Part of what favorably impressed me about the place I am working now is that the VP I talked to (1) knew what it was, and (2) knew how they scored.
Ask how refactoring is viewed, if time is scheduled for specific cleanups of known "code rot"; if at least it is possible to include refactoring of relevant code as part of building new features. A too loose policy (which I've never seen but I suppose is possible) could be as bad as not budgeting for it at all; either can produce "legacy" quality code. Intelligent refactoring is part of the cost of maintenance (code "taxes", even).
It's probably better in some cases to just tell them it would be much simpler, faster, and less costly to rewrite the whole thing.
9/11 Eyewitnesses to Explosive WTC Demolition 1 of 2
Get into management.
>Any other ways to find out code quality beforehand?
Absolutely.
That's what code and test/process reviews are for (there's a lot of latitude in how people have done or attempted to do what they talk about in general terms during your interview).
When I'm thinking about working for a company with existing code I ask for a code walk through, test over view, and demonstration of how the build + test process works.
You do not want to work for anyone who refuses because either they have something to hide or have an ego about how much of their product is "special sauce" that might get bruised if you need to change things once working there.
One of the companies I did this with didn't believe in unit tests and I figured that they'd crater because they couldn't make releases on a fast and predictable schedule with acceptable quality for their customer base. The VCs rescinded their funding for that reason plus the long and unpredictable sales cycle that goes with enterprise appliances which also had me running away.
This isn't fool proof - one company I worked for had good process but abandoned it in a panic when they realized they'd picked the wrong market and needed to pivot. Discussing the false dichotomy of quality and delivery speed (you can have both or neither) with anecdotal stories, delivering much more reliable features with out bugs leading to multiple release candidates built with good process, and having people read things like _The Clean Coder_ didn't help.
In many cases "buy" where buy can mean leveraging free software is the right answer not "build" for things that are not core to product value. You may still find yourself changing and cursing open source.
I also try to avoid that by joining new projects (not fool proof - projects get cancelled when companies pivot, companies often re-organize people to deal with tactical issues, some companies declare your product "finished" and ship it over seas for maintenance after which you join a new in-progress project, etc.) and/or new companies between series A and product design (surprisingly not fool proof - some smart people do bad things when direct to by bad managers. Two of my favorite CEO quotes are "Test code doesn't ship to customers" and "we'll add quality later." That had a lot to do with the resulting crater.)
Startups = work on the new, reinventing a wheel or ten. Established companies = work on the established, sometimes no creation, buying products instead of creating them.
Certainly don't become trapped with a dying language, but do not arbitrarily rule out working with legacy code. Think of it as a challenge instead:
1) You always learn something even if it's negative (don't do that!!!)
2) You gain insight into another's thought process. Sometimes that's scary, but again, you learn something - a new perspective, perhaps.
3) Really bad code can let you pull off the impossible - improving performance, reducing resource utilization, etc. You can become the "go to" person, with the job security and good performance evals that come with it.
Give it a shot before turning up your nose.
The contest for ages has been to rescue liberty from the grasp of executive power. -- Daniel Webster
either it's the code, the development environment, out-of-date software stack -- i think depending on the areas you are targeting and where you live -- networking and getting involved with companies products that have a dual license, open source and commercial. this way you get to know the team and to a large degree the code and how folks go about developing software.
In biology nothing works like a clock, systems are way too complex and the best scientific software is actually the one than does not follow Occam razor rule.
For example, in protein structure prediction (CASP experiment) dumb servers repeatedly beat humans trying come up with elegant solutions. Watching day by day how software designers burn on a regular basis by peculiarities of biological systems and how old amateur programs written in PERL are still popular.
Software engineers in biology should embrace the fickle nature of biological systems and try to accommodate all the poorly written code made by bench biologists. They know their stuff, they know all the exceptions.
It absolutely does not make sense to construct monstrosities of highrise software platforms. Instead, software engineers in biology should concentrate on wrappers that will allow the working bastardian amateur code to work in larger systems.
Write as it goes, don't plan much, in two years overwrite it with inclusion of new ideas. In biology, everything is fluid, nothing is fixed.
Look at the most successful enterprise in the history of bioinformatics: BioPerl: ugly mash-up of algorithms yet very popular because of extreme ease of use and coding.
I watched many times (for 25 years) the process of downshifting: physicists into biology, programmers into biology, and how in the beginning of computerized biology it seemed like clarity of physical thinking is going to triumphantly win biological problems Nope. Didn't happen. This patronizing invasion of physicists and programmers in biology lead to nothing. Scientifically elegant constructs failed miserably and HMMs, neural network, support vector machines, context free grammar crap, machine learning, genetic algorithms - all those morlocks of bioinformatics devoured elegant eloys of early years. The new dumb stuff works, because it uses dumb empirical approach to the vast amount of unsimplifiable, unclassifiable data. The methods I just mentioned are a symbol of a massive human failure to comprehend complex systems.
Programmers and physicists should go down in humility and realize that they are nothing more than lab technicians and they should stay that way, they should behave that way, they should be servants of bench biologists, not the prophets. There is no theory in biology.
So returning to the subject: embrace the legacy code whatever it is. It's not worth rewriting it, use it as it is, go around it, make wrappers. Don't aspire to complex software architectures.
I do not believe in karma. "Funny"=-6. Do good and forbid evil. Yours, Oft-Offtopic Flamebaiting Troll.
I have for well over a decade worked at maintaining legacy code, but I always relished finding the absolute crap applications and redoing them from scratch.
So I am kind of puzzled about the question. What kind of coder avoids jumping in and making something fresh and new and challenging his or her skills to not only replace something craptastic, but make something that his or her co-workers look at and go "Wow"?
_ _ _ Go for the eyes Boo! GO FOR THE EYES!
Ask what language the project was written in.
If they say one specific language, you might be good. And don't count "helper" languages - a PHP app that uses SQL counts as just one language for these purposes.
If they mention a few, or one and a few dashes of something else (C with a bit of assembler, PHP with a Python script for one weird bit, C# with a few files of VB.NET), you're possibly good as well.
If they list a large number of languages for one project, run.
There's a project I'm thankfully not fully attached to at work. Long story short, we're a small-ish company that got contracted to rewrite and extend this old product, as the original developers were either fired, or sued, then fired. I only work on the "extend" part, turning what was once a module to integrate into other software into a full suite, but I've heard stories from the guys handling the rewrite. The original devs basically used it as a training ground - any time they wanted to learn a new language, they'd take some feature request and implement it in the new language. So the entire thing is basically written "by beginners", since they never really figured out any of the languages. And there's a lot - a mix of PHP4 and PHP5, some Python, some Perl, some C modules that no longer have source, and I think a few others.
And these are for large chunks. The rewrite actually doesn't stick to one language either, but 99.99% of it is PHP (there's one ten-line Python script to act as a proxy for one thing, and a Java tool that was *supposed* to be just for internal load testing, but the higher-ups adopted it for marketing demos since we apparently beat our nearest competitor by two orders of magnitude).
So yeah. If you see a single application where more than one language is used for more than, say, ten files, you should be wary.
Now, it's entirely possible to have a completely horrendous codebase using a single language, but that's been covered by others.
The trick is to stay around long enough to reap the benefits of all your good refactoring work. If the software gets better and better, that should show up in whatever metrics management uses (downtime, customer satisfaction, whatever), and then they should pay you even more.
So the trick isn't to look at the quality of the code at the potential job. The trick is to figure out if, at some point, that quality comes under your control, and if you will have a nice work environment and be rewarded commensurately.
Uhm, some of the headers had opening comments with dates that would require a negative value unix time...
http://web.opennet.ru/docs/FAQ/network/Mail/mmdf-faq.html
-- A change is as good as a reboot.
Don't whine.
Don't use TDD.
Don't assume use of modern language features yield better code.
http://xkcd.com/610/
Suck it up. Your code is just as bad, whatever you may think. (Yes, I *have* seen it.) Know what the next generation is going to be saying about you?
Since the horrific code I currently work on was actually done by someone who wasn't a developer who did it in their spare time.(And it's a mess since I don't think he's ever had a code review with his code ever. It certain looks like it.)
Changing career is the only real suggestion I can make. You're always going to run in to terrible code unless you only work on greenfield projects; and the only difference then is how long it takes for that code to become a terrible nightmare with all traces of design lost to the ages.
Oh and run away from any company that uses the phrase "agile development" unless they can give you a satisfactory definition. In my experience a lot of people use the phrase when what they actually mean is "making shit up as you go along".
Yeah, I had a sig once; I got bored of it.
I do this by not working at all.
People whine about this recent bad economy, but for some of us, we can't find a job after graduation since we graduated right after the dot com bust. Only thing I can do is continually try and start home businesses. Here is an example of a game I wrote. I think it showcases I have competency to code effectively. There are a great many people today who are talented, skilled and hard workers, but just due to the economy, there is no place for them to work.
God spoke to me
Pair Programming shows commitment on the part of management for best practices.
Unless you are a solid developer provided with either a stellar team or a project you will create entirely alone, you should expect a degree of less-than-polished quality in every project you inherit. Most projects facing tight deadlines, evolving requirements, and/or a lack of interest in routine cleanup succumb to quick fixes and ugly one-offs that later metastasize into antipatterns. Worse yet are cases where one or more developers are actively vomiting new lines of atrocious code into the project.
Cleaning up code is something I incorporate into every task I accept. There's usually some history behind why it ended up the way it did, and even developer-driven projects are challenged by disarray the moment a general pattern emerges (i.e. situation where you either copy and tweak, or refactor into a new layer of abstraction). Sometimes there is a valid reason for an oddity, such as libraries not playing well together. If not, then I attempt to (if said perpetrator is still on site) bring the low quality coder up to speed. If that fails, and if the organization protects the veteran code mutilator, then I move on to greener pastures.
Sometimes it's enough to ask the interviewer to to share their thoughts on refactoring. At least one organization I've worked at regarded it as a bad word. Glassdoor reviews are also very insightful as the interviewer (if they want you) will likely not mention the pending dirty work ahead.
The bottom line is that software development has much in common with home renovation and building sand castles.
Funny?
My ass if funny.
This is more of a fuck yes!
Have you worked at all in any capacity respecting intellectual property?
About the only thing missing from your 'game' is:
http://www.hark.com/clips/bftljkyxzz-needs-food-badly
Ask them how they test the application. Because you cannot change it easily if you worry about breaking stuff.
nosig today
Work minimum wage for the rest of your life, and quit your bitching. After all, being completely willing to take minimum wage for the rest of your life will ensure that you will never be priced out of the market. Quit your bitching, and so long as you get paid, work for it. I am willing to do anything for minimum wage. I highly doubt I will ever even make $25,000 per year. Do I have goals beyond keeping myself and small family alive? Nope. I will likely die at work on the clock. Dreams are for people who have too much time on their hands. If you have time to "dream", you could be using that time to work and make money. Get a grip on reality, before reality gets a grip on you. "Dreaming" is for college students who have no realistic expectations out of life, and think everything will be handed to them just for breathing. Guess what? You don't get "extra credit" for breathing. Now keep up with the market, and realize what you are worth. Absolutely nothing. You are easily replaceable.
Get your free Dropbox account with 2 GB Free storage!
Ask them, "did *** I *** write the code?"
When they reply, "no, someone else did," tell them that you'll want to look at it, and declare it all COMPLETELY WRONG, and tell them you'll have to rewrite it from scratch, and that that will save them money in the long run. Tell them if they insist you maintain someone else' code, that they can find someone else, then when they tell you "no," walk. If everyone in the industry does that, no one will have to play games with logical duck-tape and bailing wire to make programs run right ever again.
Try pointing out that it would be faster to rebuild from scratch than to try to walk through what someone else wrote, depending on that earlier program's non-existent or worse, existent documentation. Tell them studies have shown programs run better when the person maintaining or patching them knows how they work, and trying to figure out how someone else' code works is a maddening exercise in futility, ESPECIALLY when you consider that programers regard the creation of fucked up, poorly commented, improperly or simply NOT AT ALL documented code a form of FUCKING JOB SECURITY. The program is usually DESIGNED not to be able to be understood by anyone but its creator, so it's faster simply to reinvent the wheel, than to try to straighten one that was cast bent deliberately.
I have seen this shit happen in person, trust me, I know what I'm talking about.
Also, if no one else will do this, you'll have to bite that shit sandwich and enjoy, or face starvation, or having to go out and (ugh...) work for a living, God forbid.
all shit code, comes from shit languages. sure you can program well in any language, but 99% of the time that doesn't happen because the language lets you do stupid things. if you learn haskell you begin to learn how to program well, and then you can go back to your shit language if needed. I'm just making some edits to a friends code, and I realize just the little bit that I've dabbled in haskell is already paying serious dividends. i'm refactoring the code much better than I would have before. btw, the shit language i'm coding in is java. just creating functions/methods that dont have side-effects is so freaking liberating!!! i could go on and on of course... but i get a bit stumped by why everyone refuses to give haskell a try. i know it's because they think it is hard...but if you are spending your career in the IT industry, you really are a turd if you dont understand what haskell is trying to teach you, and are likely responsible for that 99% shit code base that is out there. do everyone else a favour and learn haskell...seems our industry has an army of retarded programmers, exacerbated by the turd masses of outsourced land. this really causes all the black-eyes our industry has, and pushes organization into the arms of turd vendors because they'll say: "hey use our off-the-shelf turd-software, cause it's gonna be better than your turd IT org can make" what people dont get is that those turd products are all written in turd languages: java, .net, c#, c, php, and all that other shit out there. the vendor i work for simply buys up it's competition and then says we have a 'complete' solution...well its a complete pile of crap!
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.
You're not likely to ever avoid any and all legacy code. If you can have some of your own code, you should probably consider yourself blessed.
Distinguish between code that's still "good enough" to maintain and code that's such a horrible mess that you can't live with it. Invariably, legacy systems are poorly documented, but if you can more or less find your way around them, you'll be able to maintain them.
Otherwise, the most effective way I've found around legacy code is to replace it with my own. For small systems, this is fairly straightforward, as in principle you will often be able to re-build them from scratch in a short amount of time (be prepared to put in the work though!) For larger systems, you'll have tackle it a module at a time. Then of course there are systems where you cry out, "Module? What do you mean module?". If a system doesn't seem to have any structure, propose one! Describe the issues with the existing system. Explain to management why they're bad for the bottom line (maintenance costs are higher in a badly designed system). Chances are, you'll get the green light to replace it with something cheaper, if it's worth the investment. Be prepared however to do a fair bit of documenting. If you can't explain to yourself what the existing system does, chances are you'll overlook subtleties when implementing a new one. You may well find out that once you've documented the existing system far enough, it's at least maintainable (see above: "good enough").
For what it's worth, it helps to have some sort of toolbox that allows you to quickly whip up small systems. In my experience, companies are often willing to replace bad software if it takes up to a few weeks, but not if it takes months.
Visit http://ringbreak.dnd.utwente.nl/~mrjb/growingbettersoftware to download your free copy of the book
Proportional to the quality.
Except it's bollocks, because neither "variable" is quantifiable in any physical or mathematical sense, so applying such precision is so exponentially retarded it literally makes me laugh my tits off.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
There's a lot of code effort tied up in the tests, too.
Some questions to ask:
When a test fails, what is the procedure for getting it to the attention of the developer?
Who updates the tests when the product changes?
What are the formal steps involved in ensuring that the test coverage is complete?
How fast can you turn around a fully-tested bug fix build for a customer?
If you can't get straightforward answers to these questions, you might want to think about finding work elsewhere, because the release process is not going to be a smooth one.
The crappier the code the more opportunity there is for getting more work rewriting it to a decent standard.
I love crappy old code, it keeps me in work :)
The Joel Test: 12 Steps to Better Code by Joel Spolsky
Perl Shop Maturity Checklist: Technical Concerns by chromatic
Perl Shop Maturity Checklist: Social Concerns by chromatic
Perl Shop Maturity Checklist
We all want to play with the cool stuff. But to be honest you will absolutely have to work with legacy.
A really good designer/programmer/architect can not only work with the legacy but can actually design/implement a path where the legacy is deprecated out of existence. A bad programmer/designer/architect ignores it and lets it fester. The guys that get the big bucks consistently are the ones that move things forward. The ones that only will work with the cool tools/toys tend to bounce jobs and provide little over all value.
So in essence. SUCK IT UP.
Where I work we are constantly developing new software, but we keep ending up in this vicious cycle where the project managers over-promise without talking to the engineers, then the engineers cut corners (proper error handling/etc) in order to meet the deadlines, even sending the work to QA intentionally broken (then saying "oops I'll check it out" when QA discovers the "bug").. needless to say you wouldn't want to work at my company and there's little chance you'd ever work at my company, we've been downsizing and losing considerable business.
Ask how long the last guy worked here and why he left.
If (s)he was there for ten+ years then you're likely to have a safe landing with good code. Anything less increases your chances of a "maze of twisty passages". One year or less and you are probably going to be in deep do do pretty damn quick.
If (s)he died ... erm ... you decide. :)
I am once again stuck working with crap legacy code that is even crappier because all the installed versions for different clients are custom tailored (read: totally different meaning you are support 12 application instead of one where they all share the same bugs but can't be fixed with the same patch).
And I have started to notice something, and shot down a recruiters suggestion just a few minutes ago because of it. If a place only has seniors, it means the code is a mess. Trivial changes should be done by juniors if trivial changes can't be done by juniors, it means the code is a mess. Usually a mess created by making fantastic code that really showed off a coders skills but in the end is just spaghetti code were to much happens in one place for anybody to easily read the code and find the place that a fix should go.
If you played Transport Tycoon, you can see if you can write non-nightmare code. Did you create a interconnected network of trains where you tried to get the max number of trains to run on the least amount of track and dreamed of a sequel that would give you better router options?
Or did you just create nice simple separate routes with just 2 stations and at most a dual track to create a circular loop so your trains never got lost or stuck?
One is the code genius solution, the other creates code that is easily maintained. Go and play the game, create both type of networks, then alter a route. In the first, you will have to deal with countless problems as all your train routes collapse and first directly affected trains get lost and then become stuck creating troubles for your entire network. Just like in complex rail networks in real life like in Holland.
But on the kind of network you computer opponent builds with just 2 stations and trains running between them, you can easily dig up a route and redesign it and the rest of your trains continue to run their separate routes.
Juniors often lack the ability to deal with code where a tiny change here might cause something to break there. That is what seniors are supposed to be good at.
Consequently, if a company only employees seniors, they got spaghetti code.
I have been working on a wiki page to get my brainfart that MS original trouble with getting MS Office out the door, called development hell, has bastard brother in maintenance hell, where you are stuck repainting the preverbial bridge but the previous painters left such a mess AND are still doing it you never even get to painting but once you cleared the bridge of the mess the previous painters left behind, they started leaving a mess at the other end again. And if the bridge never even gets started painting, you can forget about structural maintenance.
At one company, disastrous code had been upgraded to a condition described by the developers as "stable". Stable as in how doctors use it to describe a patient in emergency care which really means "patient can now be moved for serious surgery without it killing with absolute certainty". Management thought stable meant "perfect health". It wasn't. Management planned a host of new features, we were to busy trying to keep it from falling apart on the spot.
Maintenance hell is real and it happens when your code has become so bad, that SCRUM is impossible because SCRUM MANDATES that you have your bugs under control. How can you after all estimate a project when any chance you make is going to open most certainly a can of worms but you have no idea how big or just how lethal the worms are. Maintenance hell is when only the developers who made the dev in the first place can not quite maintain it and then they leave and any new developers you hire burn out in six months and you start to accept that people only will become productive after six months studying the code.
So, questions to ask: Spread of Junior/Medior/Senior developers and... why are their existing developers leaving. Usually you can already get pretty good idea of the company by going into the history on job boards. Every 6 months they are looking to hire a senior (In holland it is standard to start with a 6 month contract)... maintenance hell, they are replacing their burned out sucker eh, developer.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Offer to sign an NDA, but don't ever take over someone else's codebase without making sure you see the code.
Employers: Don't hire anybody who offers to take over someone else's codebase without having seen the code.
This is a complete no-brainer.
-- 'The' Lord and Master Bitman On High, Master Of All
Maintenance tasks are a bit harder to outsource than greenfield development.
Not to mention the fact that it takes a different set of very useful skills to maintain and debug code, especially poor quality code. There are serious benefits to seeing what's good and bad, what works and doesn't; how to comprehend other people's code (yes, it's a lot harder to read code than write it); how to debug intelligently, and how to profile code. These skills are hardly ever taught, and have to be learnt on the job.
Don't begrudge being 'stuck on maintenance': it takes a lot more skill to read and rework old, crappy code, than it is to write new greenfield code. Just make sure that you're given enough time, resources and "creative freedom" to introduce beneficial changes, like unit test coverage and continuous interegration (I won't work for anybody who "doesn't have time to write unit tests", because it betrays a dangerous level of cluelessness.)
I might be in the minority, but I've learned to love the challenge of taming a beast of a code base.
Coming in and helping out people who don't have *anything* in place and slowly adding order has a satisfaction level all of its own.
Building out a test suite as we document business logic and then planning a refactoring can be rewarding too!
-- Trinity in high heels carrying a whip: The donimatrix - there is no spoonerism
I agree that bad code is the norm. My recent experience was a large Perl codebase, belonging to the merger of about four different companies that did the same thing but [of course] had different business processes. The code was in the gigbyte range with tons of templates and about four foreign lanugage versions.
However the code base covered many corner cases in the business model, pricing and marketing and [in the main] worked.
Thirty odd years of experience has shown me that a re-write of something like this is usually a disaster, I agree with Joel: http://www.joelonsoftware.com/articles/fog0000000069.html
The least-worst way is rolling reviews through sections of the system and a very comprehensive set of regression tests. But the point is that, at some stage, one will have to engage with 'bad code that works', it's the way of the world.
On y va, qui mal y pense!
The use of modern tech does not imply better code, but it certainly helps your work environment. A company that is quick to adopt new technology (e.g. Update to new language versions) has a better possibility than a company that doesn't. Make sure you talk to the guys involved with the technology. Interviews and screenings with recruiters are quick affairs, save your questions until you meet real developers. If the company doesn't have the actual developers and team leaders doing interviews, that is not a good sign. Third, make sure you find out how fast the crew is being replaced. A team of ten should have at least a few that have been there virtually forever, and you don't want to join that team if it has recruited 20 developers over the last 5 years. This is the most important thing: you want the same as every other developer out there. So a company where people work 1-2 years either has a technology problem or a serious pay/environment/cultural problem. Either way, you don't want it. Ask how many have left the last few years, and try to find out why. If you can't get this information, leave.
If you're working with other people's crappy code you're just a programmer. Get over yourself.
To have a right to do a thing is not at all the same as to be right in doing it
I found this everywhere when I was working in Java, where the prevailing business model is to get as many cheap workers as you can get. I retrained to Ruby on Rails and *for the moment at least* the apps are smaller and newer. Eventually though Rails will go the way of Java.
I think Ruby programmers are more into BDD and TDD than the average programmer.
Other people don't have jobs. Be glad you have one.
If you don't like it find another or create your own.
The more legacy and the worst it is, the better! It will make it easier to build business cases for refactoring / redoing things. If you work anywhere long enough in Software Engineering, you will eventually face legacy code. Better to face one you can shoot down easily :)
Get a job flipping burgers.
Seriously. Every development shop that I've seen seems to believe that they are doing the latest most cutting edge programming style. And for the 1970s they aren't terribly wrong.
The real information that you want, the folks interviewing you are likely not to know, have their heads thoroughly in the sand, or simply won't tell you until after you start working there.
Even the places that claim to use modern advanced techniques tend to treat the methods as a buffet. Pick a little from here, pick a method from there, add a favorite sauce and then call it really advanced.
So really, if you refused to handle ancient code, get a job where you'll never have to maintain code. The pay is less, but you won't see code.
I built a very successful business based on taking care of awful legacy code.
It pays really well, the work is steady and when I feel like a break, I'll take off to the Caribbean for a few weeks. You could do worse.
Had an interesting experience in one company. They asked me to take over a project where a sub-contractor had wasted a man-year building a "program" that never worked. They wanted me to "fix" the problems. My response was to refuse to even look at the sub-contractor's busted junk and to contact our customer for a specification. In two man-weeks we produced a program that completely fulfilled the specification. The customer was delighted.
The first thing I do when ever I sit down to work on old code that I haven't developed is to comment every ( or almost every ) line of code. Once I fill in all the comments I can get a much better sense of what the developer was trying to do and in some cases fix those awful blocks that almost stun the mind. The second thing I do is upload the code to a SCM system like GIT and then fork it so I'm always working off a separate branch. Beyond that I just usually need a lot of coffee, a few good cigars and loud music because lets face it 70%+ of old code is beyond the state of crap.
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.
Don't list any old legacy languages on your resume. Only list the latest ones that you actually know and want to work with. You'll get fewer offers, but what you do get should be higher quality.
now we need to go OSS in diesel cars
Fixed it for you. Seriously though, carry on being a prima donna. It makes finding work that much easier for me.
Legacy systems ran for a long time (normally). That's why you get the job. The shit has to be ported to a new platform, features have to be added etc. Legacy systems are long lived or long living systems, therefore a lot of people laid their hands on it, which results in crossover styles in programming which results in bad code. Therefore:
* The older the code base, the worse the code
* The higher number of transitions (migrations/feature changes) of a code base, the worse the code
* The less real documentation exists, the worse the code
* The worse the programming language, the worse the code
C,C++,Perl,Fortran 77, Cobol, Fortran 4, PL/1, Assembler => bad, worse, unmaintainable, even more unmaintainable, are you kidding me, we hit mars period, it talks back and WTF.
So you can conclude a formula from that: (1/code_age)*(1/(transition_counts+1))*documentation_quality*programming_language where documentation quality is defined as 0 no or bad documentation and 1 perfect documentation and programming language is defined as WTF/assembler=0 and C=0.5 (Languages such as Erlang, Haskell, Scala, Java, C# get higher marks).
A value 0 zero indicates great mess, while 1 indicates nothing to worry about. While most legacy systems are implement in the range between bad and WTF, you will never get more than 0.5 out of it. As documentation is even in new projects not really existent. They produce a lot of paper, but there is nothing in it. So you can say you get not more than 0.5 for documentation quality. As most projects are more than 10 years old, you get 0.1 for age and at least 2 transitions so 0.25. So my best value would be 0.5*0.5*0.1*0.25 = 0.00625 or the quality is below 1%. You normally get an F (or 5/6) if you are below 50%. So it is easy to conclude:
All legacy systems suck. Ah and yes, and you should get used to it.
Most recently I had the opportunity to serve as the sole Android developer in charge of some pretty terrible existing code. Since I was the only Android developer and, indeed, the only person at the (small) company with any knowledge of Android whatsoever (i.e. there was very little oversight of my activities and, since the existing app was so terrible, very low expectations), I just rewrote all the really abysmal parts from scratch. Taking a slow, buggy, visually inconsistent app and making it fast, robust and visually consistent was fairly gratifying.
Awful legacy code is one thing that can be lived with. Awful legacy bosses are another. If you go into a position with awful legacy code and the management realizes this and gives you resources to fix it whats the issue?
I make a damn good living from working on legacy code. Bad legacy code. Really awful legacy code that no one else will touch. I was hired at my current job 5 years ago specifically because I am very skilled at taking very bad code and either completely rewriting it, or picking at it to find the parts that need to be fixed and fix them. I've spent the last 5 years taking C++ code written by a librarian (yes .. you read that correctly) and rewriting it in Java (bosses requirement, not mine) to make it run faster, rarely abort, and actually produce meaningful messages if it does abort. Code that we don't even know if the current source code matches what is in production, so we can't really even make changes to it. We rewrite it, then parallel test to make sure. (There were many reasons to rewrite it, and it wasn't my decision. Although I agreed.)
.. the lazy ones that are really just not skilled enough to be able to do it.
.. my yearly wage has 6 digits to the left of the decimal point, and the first two aren't zero.)
It takes a lot of skill to be able to read code that is 10 years old or more, has no documentation, and is so full of unnecessary convolutions and nonsensical algorithms and make sense of it. There are a lot of companies out there that are tired of hiring programmers who later on won't work on something because it's too confusing or too hard. You know
Sure, I love to work on new stuff. But instead of whining about how hard and difficult it is, accept the challenge and wear it proudly, knowing that a significant number of your peers couldn't do the task.
And the best part of working on old stuff?? It's really difficult, so it takes time. And since no one else is working on it, they have to take your word for how long it takes to get it done. Now, I don't sit around all day in slippers sipping coffee and writing a few lines here and there. But I also don't put in 60 hour work weeks. And I'm probably getting paid more than a lot of you. (Hint
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
One thing to do is to ask for a tour of the networking room/cable room, etc. If it is a total mess, expect the worst from the code. If it is neat, the code might still be a mess, but there is a chance that it might be tidy....
TDD is great but it isn't the solution, new technologies aren't really new, a lot can also be done with older.. The biggest problem today IMHO is that the so called new technologies run like crap on modernday computers, you have to have a highend to get the same performance as with the old technologies, well that says to me that new technologies just plain suck and are especially for lazy developers.. Computers get faster but applications get slower, hmmm, that's wrong IMHO.. And remember, it's not like 'new' code is better than legacycode, I've seen 'new' code which is much MUCH worse as old legacycode.. especially since it seems a lot of people tend to forget to comment their code.. And please, don't give me that crap 'good code is easily read' as 'crap code is also easily read' because 'good code' is only 'good code' in the eye of the beholder..
I made millions off that...
seriously, the reason you get paid is to do things you wouldn't do free; it's all the hassles, problems, and so on. handling old code is what good engineers know how to do.
I'd be interested if the OP had a feel for whether adherence to certain practices does, in fact, result in a better codebase. Personally, I'm skeptical that they do, even though I think that some of them are probably Good Things to Do, simply because they might help.
Crappy code can keep you very profitably employed for a very long time. After all, the object of the game is to make as much money as possible in as short a time as possible, so that you can retire early. This strategy worked very nicely for me. You just have to learn to stop hating your job and employer.
Rewrite it.
There you go. Fixed the problem for you.
Bad legacy code is not so bad when you are allowed to fix it (gradually, over time, not as one big chunk). Use unit tests and such to make sure that you aren't breaking things as you do so. (Buy and read Martin Fowler's book, "Refactoring").
Bad legacy code absolutely sucks when you are not allowed to change anything except for what's absolutely necessary and you therefore have no choice but to make the bad code even worse by constantly fixing small problems and ignoring the big ones.
I have been at jobs where managers took each of these approaches. The jobs where management took the first approach became better and better over time, because I was able to gradually improve the code into something that was maintainable and not horribly painful to work in. The jobs where management took the second approach were horrible, and I am glad to be out of there.