Damian Brady's Blog

In my travels, I stumbled across a blog post from Brandon Savage titled, “Why Coding Tests Are A Bad Interview Technique”.  While there are some points I think are fair enough, for the most part I disagree.  I’ll break down the major points so it’s easier to read.

Sending out Resumes to all available companies

Brandon mentions quite early on that his major gripe with these programming tests is that he doesn’t have time to do one for every company out there.  Every company. He’s applying everywhere.  A good developer shouldn’t need to flood the market with resumes.  If you’re any good, you should be able to be a bit more selective about where you apply.  Is the market really that bad that you need to go door-to-door begging for a job?

Writing a complete application as a coding test

In the comments, Brandon elaborates on this a bit further, saying that he’s actually had a company ask him to develop a complete database-driven, input-validating, emailing application.  Yes, that’s ridiculous and if it’s occurring more than once in a blue moon, then there’s a problem.  If a company is asking you to write an app like that just to get an interview, I view that as over the top and unrealistic.  Asking you to code up Fizzbuzz or a function to recursively search a directed graph? Not so much.

Look, as long as the code I’m writing doesn’t take me more than a few hours, and I really want to work at the company, then I’m willing to put the effort in.  If I’m flooding the market with resumes hoping for any kind of bite, then I’m probably not going to want to spend much time demonstrating my abilities to… who was it…? One of those places…

Asking for a code test is disingeneous and disrespectful

You know what? I totally disagree.  Brandon suggests that a few phone calls might be enough to determine whether someone is qualified.  Qualified? Yes, probably.  Does that mean anything? Not necessarily.

Let me digress for a bit.  I’m not sure whether the same thing exists in the US, but in Australia, we have a small training organisation that advertises late at night and promise a career in IT within a few weeks of graduating their four month course.  Four months, and they’re considered an IT professional.  These offers boil my blood – particularly because for many, many people, their qualification means the same thing as mine and my bachelor’s degree is therefore diluted.  By the way, I’m not talking about IT recruiters here; one would presume they’d know the difference.  My point is that an IT qualification by itself means nothing, and I’m not just talking about a participation certificate from Bob’s Discount IT Training.  I graduated from my degree with a scarily large number of budding programmers who couldn’t write code to save their lives.

Even experience on paper means nothing.  I’ve worked with plenty of highly qualified and very experienced people whose code just makes you cringe.  Sure, they’ve been involved in several major projects and have been an integral part of so-and-so really-important-deployment, but when you get down to it, they wrote crap code and nobody really knew any better.  You can look great on paper and still not have a clue.  I’m sure we’ve all known people like that.

Brandon suggests that as an alternative, asking for an already-written sample of code would be acceptable.  If it’s available, then sure, but I don’t think requiring one is fair for two reasons:

Firstly, the code the person writes during the day at their current job is not likely to be public.  As an employer, how would you feel about an employee showing the inner workings of your proprietary software to a rival so they can up and leave?  There’s almost certainly something in the developer’s current contract that explicitly prevents them from doing that anyway.  So what about code they’ve written in their spare time I hear you ask?  Unfortunately, not everyone writes code in their spare time and I think it’s rude to assume they do.  I do, and I’m sure a lot of developers do, but they might not for whatever reason.  You shouldn’t hold this against them.  Even if the person does write code on their own time, why should it be any more public than their company’s code?

Secondly, I’m not sure I’d be happy showing much of my own (old) code.  I look at stuff I wrote a year ago and wonder what I was thinking.  Does this mean I’m a crap developer?  No, I think it’s healthy to be able to appreciate that you’re continuing to learn.  If you can’t compare your current work to your previous work and see some improvement, then are you still learning?  I’m not alone on this line of thought either.  From a hiring point of view, I want to know how good the person is now, not how good they were the last time they wrote code that they’re allowed to show you.

It’s not all bad – what I agree with

I agree that it is very important to be able to see whether a developer is capable of learning. However, I’m not looking for the coding test to evaluate someone’s learning ability. A piece of code is a snapshot, and you’re not going to get any idea of learning and adaptability from a test like that unless you ask them to do it every six months for several years. You can evaluate whether someone learns well by asking them questions in the interview, and looking at how they keep up to date in the industry. You could even ask the default predictable question about a particular challenge they faced and how they overcame it. But nobody’s going to look at a slab of code and marvel at how well this person adapts to change. That said, if someone proudly hands you a bit of code written in VB.Net for version 1.1 of the framework using untyped DataSets, it’s probably safe to assume they’re not the learning-and-adapting type.

Brandon also suggests that if someone has a body of code samples ready to give out, then they shouldn’t have to do the test.  If those samples are appropriate and relevant, then I agree to an extent.  Why ask someone to redo something they’ve already done?  Really, though, if you want to see how well someone can think through a problem and turn it into code, then the best way to test that is to actually ask them to do it.

Summary (and tl;dr version)

If someone is applying for a job as a developer, I don’t think it’s unreasonable to ask them to write some code.  If it’s a fully-fledged application, or something that takes more than a few hours, then we’re not talking about a code test, we’re talking about free software.  Sadly, qualifications and experience don’t necessarily equal capability so you can’t just rely on that.  It’s entirely possible to have an awesome resume and loads of experience, and just be crap at writing decent code.  Being asked to show off your skills shouldn’t be taken as an insult, but an opportunity.

So I’m starting a new project, and we’ve made the decision to use the ADO.NET Entity Framework for talking to the database.

I actually found it quite difficult to get started. Examples on the web seemed to assume that I already had everything installed and ready to go. Step one was invariably “Add a new ADO.NET Entity Data Model”. That wasn’t available in my “Add New Item” dialog, so I set out to discover how to add the bits I was clearly missing.

After hunting for a while for a download, I found a CTP Preview 1 built on .Net 4.0 (I’m running 3.5), and some Entity Framework tools released as a CTP in 2007.

Lesson 1: Everything you need comes with the Microsoft .NET Framework 3.5 Service Pack 1.

Of course, when I try to find the misleading links now, I find the real one straight away. Hopefully your google-fu won’t fail you as mine obviously did.

I had a quick play with it and found that creating classes and relationships between them was mindblowingly easy. Build up your pretty diagrams or get the designer to build them from a database and suddenly your code can create objects, run LINQ queries against them, bind them to UI controls and keep track of changes as you go. Brilliant!

So I got to work building up a sample object tree for our new application. When I was done, I looked for the option to persist the changes to the database.

Lesson 2: You can update your models based on database changes, but not the other way around (it’s coming in 4.0 though).

Damn, database first. Back to the start.

No problem, I abandoned my design and started with the database. Once the tables were built, generating EF data models was a piece of cake.

Next step – dependency injection for testing. I don’t want to be bound to the database, particularly for testing. I want to be able to inject fake objects for my tests.

Lesson 3: EF creates concrete model classes and database contexts. Dependency Injection is not easy.

Honestly, we were prepared for this one based on some presentations we saw at Tech.Ed. We have come up with a solution for this, too. It looks good on paper and everything seems to compile and run ok, but we’re yet to see whether this holds true as we dig deeper.

Basically, we’re leaving the concrete models as they are, but we’re extracting an interface for the ObjectContext class that’s generated. Our proxy will provide a fake ObjectContext which doesn’t talk to the database, but it will mock out real model instances. If you have any better ideas for this problem though, let me know.

Sometimes you find a tool that’s not just good for run-of-the-mill, intended-purpose work, but also for fixing up some bad situations.  jQuery is one such tool.

Some work I’m currently doing involves presenting nicely styled pages to the user of a web site.  The html I have to work with is not always ideal and needs to be massaged.  Because I’m dealing with templates, it’s often simply impossible for me to change the html – I can only try to modify the framework around the bits of html I’m given.

Enter jQuery.

Provided the html I get is more or less xhtml compliant, I’ve got a Document Object Model (DOM) I can work with.  Using jQuery, I’ve found that I can manipulate this to my heart’s desire.

Let’s say I end up with an table which has an extra row between the header row and the first actual row of data.  No problem!

$(document).ready(function() {
    $('#mytable tr:nth-child(2)').remove();
});

And that’s it! Of course you may get a flicker of the incorrect display because we’re making the change only when the DOM is completely built, but we’re not really choosy in this situation.

Let’s try something a bit harder.  How about reformatting a table which contains a single column for debits and credits; the debits formatted with a red <FONT> tag.  And before you ask, yes, I’m serious.

We want this table to have a separate column for debits and credits.  Again, enter jQuery.

$(document).ready(function() {
	// first, deal with the headers
	var cell = $('#mytable tr:eq(0) td:eq(2)');  // look at the second cell (contains debits/credits)
	var w = cell.attr('width').substr(0, cell.attr('width').length-1);  // I know width is a percentage
	cell.attr('width',''+(w/2)+'%');	// half the width
	cell.text('Credits').before('<td align="right" width="'+w/2+'%">Debits</td>'); // split Debits and Credits header
 
	// now deal with each non-header row
	$('#mytable tr:not(:first)').each(function()
	{
		$(this).children('td:eq(2)').before('<td align="right">&nbsp;</td>'); // insert the new column
		var redVal = $(this).children('td:eq(3)').html(); // get current column value
		if (redVal && (redVal.toUpperCase().indexOf('COLOR=RED') > -1 || redVal.toUpperCase().indexOf('COLOR="RED"') > -1)) // if it's red
		{
			redVal = $(this).children('td:eq(3)').children('font').text(); // get the actual value to write
			$(this).children('td:eq(2)').html('<span style="color: red;"> '+redVal+'</span>'); // write to the debit column
			$(this).children('td:eq(3)').html('nbsp;'); // erase the credit column
		}
	});
});

Now this doesn’t give me beautiful xhtml, and I’m never going to feel happy about how this works, but it does the job.

Fun stuff.

Thought I’d post this solution to what I would have thought was a fairly common problem with this product.

I’m using an ASP.Net CMS called Kentico CMS.  It is quite good – much more friendly than some others I’ve used recently.  I’ve been trying to get the CSS Menu control set up so that it will always show root pages, and also the pages beneath the current page.  It wasn’t as easy as I thought.

For example:

Home
About
 - Our Products
 - Our Services
    - Programming
    - Design
Links
 - Friends
Contact

In the example above, no matter where I was on the site, I wanted to see Home, About, Links, and Contact on the menu.  If I was on the About page, then the Our Products and Our Services links should be shown as well.  So I’m looking for the root pages and the children of the current page.  I thought this was pretty standard menu behaviour, but it took me a couple of hours to figure out.

Here’s the solution:

In the design view, edit the properties of the menu by clicking on its gears icon, go to the Content Filter section and put the following query in the WHERE condition field:

NodeAliasPath LIKE ‘{&/{0}/%&}’ OR NOT NodeAliasPath LIKE ‘/%/%’

This gets all items under the current one {0}, or anything that’s not a root element.  You’ll have to make sure the Maximum nesting level is set appropriately, but that’s it.

Hopefully someone else with the same problem will stumble across this and save themselves an hour or two.

I made a mistake the other day.  It seems that I used a random number when I really wanted a unique number.

Let me explain.

A service I wrote needed to send a message to an older process every 30 seconds or so.  To do this, it put a file in a particular folder and gave it an 18-digit filename.  Something like 541238740514861189.input.  The older process picked up this file, did what it needed to do, and put a corresponding response file back in the folder for my process.  Something like 541238740514861189.output.  My process picked up the response and continued doing its thing.  Fairly simple in theory.

I figured that seeing as this is a single-threaded process and it only runs every 30 seconds, seeding a random number with a time value would work.  I was even using the Ticks property of the DateTime which measures time in 10-millionths of a second.  It didn’t occur to me at the time that even though there was only one thread, there might be multiple copies of this service running.  Being a server with a multicore processor, that means that it’s possible for the same line of code to be executed at exactly the same time.

Still, it’d have to be phenomenal bad luck for the same line of code to execute in two processes within the same 10-millionth of a second, right? The odds would have to be miniscule!  Well, it turns out that while the Ticks property of the .Net DateTime might measure the number of 100 nanosecond blocks since the first of January 0001, that doesn’t say anthing about its resolution.  The resolution of DateTime is not 100 nanoseconds, it’s about 15ms.  Suddenly the chances aren’t so slim.  There are now only 2,000 blocks of time in that 30 seconds.

So yes, it was very, very unlucky for two of these service to generate the same “random” filename, but it was possible.  It was stupid of me to use a random number when I really needed a number that was unique.  They’re different things.  Solving the problem was as simple as making sure the first x characters of the filename represent the process Id.  That can’t be shared between processes so there’ll be no collisions.

Lesson learned.  Also, I should probably stop publishing my mistakes…

I don’t often write about anything non-tech related, but I thought this was worth the detour.

Triple J is taking votes for their Hottest 100 of all time. It’s incredibly hard to choose. If you’re anything like me, you’ll find yourself with a shortlist of about 30 before you realise you’ve forgotten one of your favourite bands.

Anyway, in no particular order, here’s the top 10 I ended up with before I stopped. No doubt it would have changed many more times if I’d kept at it. Even as I type this I’m questioning my decisions…

1. Foo Fighters – Everlong
2. Radiohead – Paranoid Andriod
3. The Beatles – A Day in the Life
4. The Dandy Warhols – Bohemian Like You
5. Jeff Buckley – Hallelujah
6. Crowded House – Four Seasons In One Day
7. Regurgitator – ! (the Song Formerly Known As)
8. The Rolling Stones – Sympathy For The Devil
9. Queen – Bohemian Rhapsody
10. Coldplay – A Rush Of Blood To The Head

Ten is totally not enough…

I solved a problem the other day.  It was a terrible solution. It works, but it’s difficult to be proud of how I solved it.

The problem was with MSMQ, but let me describe the problem with a needlessly overwrought metaphor.

Every week for the last 5 years, you’ve been sending a bill to one of your clients.  You have an infinite supply of envelopes and when Friday comes around, you print out an invoice, seal it in an envelope, send it by courier to your client, and a couple of days later, you get paid.  With me so far?

One day, you decide to start using a different invoice management software package – it’s much prettier and more stable than the old one.  You know, however, that the client doesn’t want anything in that invoice to change.  You’re not sure how they process it, but one time your printer smudged an invoice slightly and you didn’t get paid.  So everything in that invoice has to be exact.  Luckly, the new software is capable of printing a pixel-perfect version of the old invoice layout.  So far so good.

You also think you should start using a different courier.  Your existing courier company (COM+) is fine, but frankly they’re a bit behind the times.  The delivery drivers are about 80 and they’re driving some vans that are generations old.  So you set up a deal with a new company called C-Sharp 3.5 to do the delivery for you.

Still with me?  I told you it was overwrought.

So anyway, you give your new system a try.  You print out the invoice, compare it to the old one (spot-on, 100% the same), put it in an envelope, and send it off using the new courier company.

You don’t get paid.

You contact the customer but they don’t say much.  Just that they didn’t receive a valid invoice.  The new courier company swears they delivered it to the correct address and they provide proof.

You decide to try again next week and do some investigating.

The next week, you print out the invoice, compare it to the old ones (still the same), put it in an envelope, and organise for the new courier to pick it up.  This time though, you follow him.

He takes your letter, gets in his van, and drives to the client’s address.  He gets out, puts your letter in the mailbox and drives off.  Nothing wrong so far, as far as you can tell, so you wait to see what happens.

Soon, a guy comes out of the house (which by the way looks exactly like a big black box), opens the mailbox, picks the letter up, and takes it inside.

You go home, satisfied that the letter made its journey this time.  It must have been a once off.  But you still don’t get paid.

Again, you contact the client and all they’ll tell you is that they didn’t get a valid invoice.  You protest, telling them that you saw them pick it up but to no avail.

Over the next few weeks, you try everything you can think of to get this new system to work.  You try looking at the message again after it’s put in the letterbox and you try sending an invoice created by your old program.  Every time, the seemingly perfect letter gets picked up my the man in the black box, and nothing happens.

No matter how hard you try to work out what’s going on, nothing helps.  So, like any sensible person,  you give up and call the old courier company.  They turn up, pick up your invoice, and two days later, you get paid.  Despite the fact that they’re apparently doing exactly the same as the new guys, their deliveries get you paid, and the other deliveries don’t.  You resign yourself to using the old couriers until they or their vans all die.  It’s just a matter of time…

Fun story, huh?

So in case you’re a bit slow and didn’t work out what it was all about, I replaced an app that put a message in a Windows message queue for another (black box) program to pick up.  The old app was VB6 using a COM MSMQ library, and the new one was C# using the native .Net MSMQ library in the 3.5 version of the .Net Framework.

No matter how hard I looked, I couldn’t find ANYTHING different between the messages and where they got put.  I even dug up a copy of the black-box code and stepped it through a debugger.  When it got to the line saying Queue.Receive(), the message disappeared from the queue, and nothing came back.  There was no exception thrown!  I watched the message get picked up!  I did a binary comparison of the message contents from the old program and the new program!  No difference at all!  Inexplicable!

The fact that I was putting the message into the Windows Message Queue using a .Net library and picking it up using COM+ seemed to be all it took to break the thing.

This is the first time I can remember being absolutely, 100% stumped by what was going on.  I’d analysed what was going on as deeply as was practical and had come up with nothing.

So I did the logical thing and referenced the COM+ dll from my new app.  When I used this library to send the message, it all worked perfectly.

I really don’t like this fix. Despite the fact that everything works perfectly now, it’s still a failure in my eyes.  It’s like a brand new Merc with duct tape holding the wheels on.

However, given that I’d spent way too long already on something that really shouldn’t have been a problem, it was probably the right thing to do.  Cut my losses and take the easy way out.  I’m not proud.

So I finally joined the dark side and I got myself an iPhone.

Now, if you’ve been following this blog for a while, you’ll know that often it’s the little things that interest me.  Small bits of functionality and the tiniest ideas sometimes make the biggest impression.

With that in mind, here are the top things that have impressed me about the iPhone.

1. UI during phone calls

When I’m on a call and I’m holding the phone up to my ear, there’s no need for the screen to be on… so it’s not.  If I take the phone away from my ear, the accelerometers in the phone notice this and I get a useable display again.

A tiny thing, but it shows that Apple is thinking.

2. Music in my car

I connect the iPhone to my car stereo using a standard 3.5mm headphone plug.  Great sound. It works perfectly. Not that impressive.

However when I get out of my car, I pull the cable out.  The music stops.  It could quite easily continue – there are speakers on the phone after all, but it’s smart enough to assume that having unplugged th speakers/headphones/whatever, I probably don’t want to listen to the music any more.

Again, it’s simple but intelligent.

3. Silent switch

My old phone was a Nokia E71 and I loved it.  It did everything I wanted it to, but I’m a sucker for stuff that’s nice to use (usually) so of course I wanted an iPhone.

One very slight annoyance I’ve had with every phone thus far (including the E71) is that to turn the phone to silent, it takes a few steps.  On the E71, you have to unlock it, press the power button at the top, scroll down to Silent, press the OK button, and lock the phone again.

On the iPhone, you flip the switch on the side.

4. Network connection switching

I’ve set up my iPhone with the details of my home wireless network and the network at my parents’ house.  I did each setup a grand total of once.

Now, whenever I’m at home or at Mum and Dad’s, any browsing I do uses those networks.  The phone never asks me, never checks to see whether I might actually want to pay for access, no.  It assumes I’ll want the fastest (and cheapest) connection available.

5. Application Installation

Hands down the cleanest installation for any software I’ve experienced.

Go to the app store and find something you want, touch the price button and then install, and you’re done.  There could be a couple of extra touches here and there and you might have to put a password in so your account gets charged too, but it’s incredibly easy.

It downloads in the background, there are no restarts, and you can immediately see it in your list of apps (“springboard” apparently).  Brilliant.

So that’s it – probably not the same list as anyone else, but like I said, it’s the small attention to detail that impresses me.

So my keyboard at work just broke.  Doesn’t happen often, but one of the keys just stopped y’know… putting it’s letter on the screen.

So I got given a replacement from somewhere.

Here’s the thing – the layout is different.  Any programmer or techie or otherwise-nerd will know what I mean when I say that it’s FREAKING ANNOYING!!

Now, there aren’t any big changes really.  I mean, all the letters are in the same place, and the F-keys are still above the keyboard and the number pad is the same, but there are enough differences to frustrate someone like me.

The Home-End-PgUp-PgDown-etc. chunk of keys is different.

This is what I used to have:

Here’s what I have now:

What that means is that I keep hitting Delete instead of End.  Because it’s right below Home now.

I only have one Windows key

And it’s on the left – the one I don’t go for when I’m locking my computer with Win-L as I stand up to go somewhere.

The F-keys are grouped in threes

Seriously, in threes?  F5 is by far the most common F-key I hit, and now it’s in the middle of a cluster instead of on the left.  I have to look at my keyboard now to hit it.

My right Ctrl key is slightly to the left of where it was

Not a big deal you’d think?  Well truthfully it doesn’t affect me much – I still usually hit it first go, but it’s been moved left to make way for the arrow keys.  So when I don’t hit Ctrl, I hit the left arrow key.  That’s confusing.

So you’re probably thinking, “Oh, you poor little baby! Would you like some cries with your waa-burger?”  And yes, yes I would.

Seriously, it’s frustrating.  I know it’s only temporary – I’ll get a new one soon with a normal key layout.  But my keyboard is by far the most frequently-used tool in my arsenal.  Small things like this slow me down.

Ok, I’m finished complaining now.  You can proceed with your day.

I’m positive I’ve ranted about maintaining legacy code before, but I going to do it again.  At least this time I’m just reading the code so I can understand it and rewrite it rather than having to apply more bandaids.

Oh yes, and I’ve jumped on the “Top X List!” bandwagon.  It’s cosy up here.  So in no particular order, here are my top 6 things I hate seeing in legacy code:

1. Comments and variable names that didn’t update with the code

Yes, the code changes as you write, I understand that.  But seriously, can you please update the comments to reflect what you’ve done?

It’s very confusing seeing TODO comments for things that have been done, or comments about things that should be considered before the code goes into production.  Or maybe there’s a variable called currentIndex which is now actually a string containing a key because the original programmer changed from an array to a dictionary.

These things sometimes take ages to work out.  For example, I recently spent several hours trying to figure out what was happening in a chunk of code.  Looking at the following line:

It turns out:

1. It was in fact implemented (and was very, very necessary)
2. The failedMessageList variable contained all messages, not just failed ones

So seriously, if you change your code – take a glance at the comments to see if they need changing too.

2. Poorly named files

I had to add this one in. Not because it’s a big problem very often, but because when it occurs, it can be really painful. It’s obviously frustrating when classes and variables are named badly, but if files are named badly it can be even worse.

Let’s say you’re reading through the code and find a line that instantiates a Person class. Unfortunately, there’s no Person.cs (or whatever language) file. After some searching, you find that the Person class definition is in Teacher.cs – a file that wasn’t renamed when the code changed.

Or perhaps you’re looking for the UI for the window titled, “Database Maintenance” and have to work out that it’s actually a class called Restoring which is found in a file called FrmBackRest.vb. Sadly, a true story.

3. Inconsistent ways of doing things

I don’t have a problem if you do something a different way than I do; that’s fine – we all have our preferences. I might prefer to write to the database with parameterized stored procedures that I’ve written myself, while you use an ORM and just call a Save() method on an object you’ve just updated. That’s fine – both work.

What I really don’t like, though, is when someone does both. Like, in one place they’re calling stored procedures, in another they’re building SQL queries on the fly, and in another they’re retrieving DataSets via queries, updating the values, and calling a Save() method.

Nothing screams I-just-hacked-this-together-without-a-plan as much as large inconsistencies like this.

4. Even legacy-er code in legacy code

Sometimes I’ll come across legacy code that makes it clear that the original developer came from an even older background and didn’t quite understand this new technology. As a .Net developer, the most common stuff I see is good old VB6 code in a .Net app.

I came across a Goto statement in a bit of .Net code the other day. Another true story. It was a few lines after “On Error Resume Next”.

5. Error handling that hides errors

This is pretty common, and unfortunately it’s really only something that gets noticed when you have a problem. While things are working perfectly (and you don’t care how it works), there’s no problem. As soon as there’s an error though, you can’t find any details about it because the error handling is crap.

For example:

The end result of this? Here are some examples:

1. The transmitter.SubmitMessage method throws an exception. It gets caught, written to an error log, and thrown again. Ok, that’s not too bad…
2. The result from the SubmitMessage method comes back invalid. We increment our error count, get the details of the problem, and throw an exception. Then, oh no! That exception gets caught immediately, and another incredibly generic “CONNECTION_ERROR” exception gets thrown – completely abandoning the information gathered. But wait, there’s more! That exception then gets caught and logged and the error count gets incremented again! Yay! A “CONNECTION_ERROR” occurred… no more information… and an incorrect error count…

See? Don’t do it. If you can’t test for proper failures (sometimes it’s very hard), at least think about what’s going to happen.

6. Unused tracts of code

This one comes back to updating everything relevant when you have to revisit your code. A lot of the legacy code I’ve seen has codepaths that can’t possibly be used, methods that are never called, and in some cases classes, modules, and even entire libraries that aren’t referenced.

A recent project even had two code files, Connection.cs and Connection2.cs – they had different class names (Connection and Connection2 predictably), but they had the same methods with different implementations. Connection.cs was never used.

If you have to traverse your way through hundreds of lines of poorly-written code, it can get very frustrating when you find that half of it isn’t even used. It’s even more frustrating when you’re trying to match the behaviour you’re seeing with the code you’re reading, only to find out that it’s actually a completely different near-duplicate that’s running instead.

And that’s it – my top 6 annoying legacy code things. Feel free to comment.