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?"
Re:any questions? (Score:0, Interesting)
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.
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.
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...
.
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: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
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: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.