Archive for the 'Uncategorized' Category

Refactoring: You Keep Using that Word, I Do Not Think It Means What You Think It Means

“Refactoring,” as a term, is rapidly becoming meaningless. The final nail in the coffin, for me, was this morning when I heard a sales guy say:

I need to refactor the pipeline in Salesforce—it’s got a bit messy and needs tidying up.

When a term has become so generic that sales guys start (mis-)using it, it’s lost all value.

He’s not alone. I’ve lost count of how many times I’ve heard software engineers who should know better say “refactoring” when what they actually mean is “changing.”

Refactoring (actual refactoring, not redesigning, reimplementing, debugging, …) is one of the biggest advances in software development over the last couple of decades. It is the process of improving the design of existing code without changing its behavior. It relies on two key insights:

  • Modifying existing code can be carried out safely only with the safety net of a comprehensive suite of tests.
  • We should never attempt to refactor the code at the same time as modifying its behavior.

In other words, you can modify the behavior of the code, or you can refactor it. You should never attempt to do both at the same time.

Upon reflection, it’s easy to see why this is the case. Imagine that you attempt to modify both the structure of your code and its functionality at the same time, and after doing so one of your tests fails. This might indicate that you made a mistake when modifying its structure. Or it might be an expected result of the change in functionality. It’s difficult, however, to be sure which. The more complicated the change in functionality or structure, the harder it is to be certain.

By doing only one or the other, you avoid this issue entirely and can forge ahead with potentially far-reaching refactorings involving dramatic changes to the code with confidence.

I fear that it’s too late; “Refactoring” is used incorrectly so often that it’s probably beyond rescue. But I hope not.

An Open Letter to The Gregory James Group

Dear employees of The Gregory James Group,

Please forgive this indirect and public means of communicating with you, but it appears that all other means of doing so are ineffective.

I have repeatedly asked for you to remove me from your contact database and stop sending me unsolicited e-mails or making unsolicited telephone calls. I would prefer not to expose your flagrant contempt for others’ time publicly, but this is a final throw of the dice in an attempt to get you to stop spamming me.

Below is a representative sample of the e-mails I’ve sent you over the years (yes, years). Sadly, I don’t have transcripts of the telephone conversations, but they are similar in nature and number to the e-mails.

From: Paul Butcher
Subject: Re: Graduate Android Developer (MSc. Software Engineering) – Available Immediately
Date: 10 September 2013 12:23:13 BST
To: “Charley Lucas” <>

See below a selection of e-mails that I’ve sent to various members of your company over the last several years. What, exactly, does it take to get off your e-mail list?
From: Paul Butcher
Subject: Re: Senior C# ASP.NET MVC3 Programmer
Date: 13 August 2013 17:33:55 BST
To: “Roxanne Gordon” <>
Cc: Tom Townsend <>
I have no idea why you think I may be looking for a developer of this type. I most certainly am not, and it’s completely inappropriate for the kind of things that we do here.
I recently had a long exchange with your colleague Tom Townsend (copied) to try to stop him from spamming me with unwanted and inappropriate e-mails. I finally managed to persuade him to stop doing so and remove me from your company’s mailing list. I don’t know how I have ended back on it, but please remove me immediately and do whatever you need to do to ensure that I never find my way onto it again.
I don’t know what it is about Gregory James that makes you think that it’s OK to waste people’s time, but I really wish you would stop.
From: Paul Butcher
Subject: Re: Mobile Application Development
Date: 28 January 2013 10:02:23 GMT
To: “Tom Townsend” <>

I fail to understand how my earlier request that you please not mail me again was open to misinterpretation. I would be grateful if you could accede to my very clearly expressed wishes.
From: Paul Butcher
Subject: Re: iOS Development
Date: 15 January 2013 15:41:08 GMT
To: “Tom Townsend” <>
No. Please do not mail me again
From: Paul Butcher
Subject: Re: iOS Development
Date: 15 January 2013 15:37:03 GMT
To: “Tom Townsend” <>
Please remove me from your mailing list.
From: Paul Butcher
Subject: Re: Ruby on Rails Contract London £350 – £450 Per Day D.O.E
Date: 21 January 2011 11:47:06 GMT
To: “Christopher Barlow” <>

I have no idea how I got onto your mailing list. Please remove me from it immediately and confirm that you have done so by return.

From: Paul Butcher
Subject: Inconsiderate use of e-mail
Date: 1 October 2010 14:12:00 BST
Cc: David Christian <>

Please forgive the wide distribution of this e-mail, but unfortunately your colleague David Christian apparently does not believe in treating people with respect, so I am left with no option.

Somehow, I have ended up on David’s indiscriminate database of people who might be interested in web development contract work. I am not interested in this kind of work, have never asked to be on his database and have no clue who he, or you, are. I have asked him nicely to remove me from his database and he hasn’t had the courtesy to respond or to honour my polite request. I am sure that I don’t need to tell you how this kind of behaviour reflects on your organisation as a whole.

As it happens, I am a software development manager who regularly makes hires through recruitment consultants. This experience guarantees that I will be doing no business with The Gregory James Group.

I would be grateful if you could persuade David not to send me any further unsolicited messages.

From: Paul Butcher
Subject: Re: Contract RoR/PhP Work Remotely
Date: 30 September 2010 13:25:03 BST
To: David Christian <>
I am not looking for work, and have never asked to be on your database. Please remove me from your database, send me an e-mail confirming that have done so, and then send me no further communications.

An open letter to an IT recruitment consultant

Dear IT Recruitment Consultant,

For the purposes of this letter, I’m going to assume that you are one of the tiny minority of members of your profession who have some integrity and ability. Unfortunately for you, you have chosen a career with a deservedly dreadful reputation. Most IT recruitment consultants are no better than a combination of pimp and double glazing salesman.

But you’re not one of this majority. You can have a conversation with me where I don’t need to explain everything to you in words of one syllable. Repeatedly. And you have a unique source of amazing candidates unavailable to any other recruitment consultant and who would be just perfect for me.

So how do you get to talk to me?

Well this is where it gets difficult I’m afraid. You know that you’re one of this tiny minority, but I don’t. And unfortunately all of you claim that you’re different from all the rest. How do I tell the difference between someone who really does have a brain and the vast majority who just claim to?

Well, I’m sorry, but there is exactly one way to achieve this, and that’s to be good at your job. It’s a long, slow path, but eventually someone I trust will recommend that I talk to you. And if I need to, I will.

What you absolutely do not do is call me. Or e-mail me. Or try to link to me on LinkedIn (especially not by lying and claiming to be my friend or an ex-colleague in order to avoid paying LinkedIn). Or try to get in contact in any other way whatsoever.

My problem is not that I don’t know enough recruitment consultants. Nobody who has spent more than a few years in IT can possibly fail to know many (many!) recruitment consultants. I have found a small set that I trust, respect, and will work with again (you see – I do know that some of you are different).

I don’t want to be introduced to any more. There are too damn many of you, and most of you aren’t worth even the 60 seconds of my time it takes to tell you to go away. Not that it ever takes 60 seconds, because you always have to followup and tell me why I’m wrong about you and you’re different from all the rest. And ignoring you doesn’t work either, because you’ll just try again. And again. And again.

I will never do business with any recruitment consultant who cold calls. Ever.

So please stop? Please?

Dropbox: What MobileMe should have been

MobileMe has always been something of a disappointment to me. It’s so close to great, and yet falls short:

  • Push e-mail to my iPhone is great, but not without spam filtering or rule support.
  • iDisk should be a great way to keep the files that I’m working on in sync between my various Macs, but it’s just too clunky.

I’m working around the first issue by switching to Gmail, but haven’t found a satisfactory solution to the second. Until now.

This morning, I discovered Dropbox. It’s extremely easy to install, works seamlessly, gives me transparent duplication between my various computers (including Windows and Linux), provides me with access to my files when I’m offline and integrates with my iPhone. It’s very rare for me to get excited about a piece of software, but I’m genuinely impressed.

Oh – one final bit of trivia. If, like me, you’ve been relying on Mongrel to deploy your Ruby on Rails applications, you might be interested to know that Zed is a member of the Dropbox team.

Blink versus The Decisive Moment

If, like me, you found Malcolm Gladwell’s Blink unsatisfying, I suggest that you take a look at The Decisive Moment by Jonah Lehrer.

Like Gladwell’s book, Lehrer gives several examples of instances where trusting our subconscious provides better results than thinking things through methodically and logically. And examples of the opposite, where our subconscious can be fooled and we need to be on our guard. So far, they have a great deal in common.

Where the books differ is that Lehrer delivers on the promise to tell you when to use one mode and when to use the other.