When you move on to your next challenge how will those that inherit your code think of you? Noble or notorious, innovator or insane? This is a question that all developers should ask themselves frequently; though too few ever do. You should always write with the assumption that someday a new developer will take over your code, and they will question every decision and assumption you’ve made. When this happens, what will they think of you?

Perhaps I’m more aware of this because I maintain an internally developed shared library that my company uses in every application; but regardless of the scope of the project you should always assume that someday you will hand the project off. Many developers think little about what happens to their code after it passes on to another; what other developers will have to deal with, or how their efforts will be perceived.

When I’m training a new developer there are a few points I try to reinforce as much as possible:

1. Code is only good if other developers can work on it without extensive training. If it takes days or weeks of introduction to get a new developer up to speed, then you’ve done something wrong¹.
2. Clever solutions are no better than an ugly hack if it’s not clear what you are doing. If the code isn’t clear then it’s not maintainable, if it’s not maintainable then it’s junk.
3. Assume you’ll be hit by a bus. Always write code with the assumption that you won’t have the opportunity to cleanly pass the code off to a new maintainer. Never assume that you’ll have time to come back and clean things up later.
4. Always perform design reviews, no matter the size of the project². Once you have a design in mind, talk it through with a at least two other developers. Just because you think it’s clean and clear doesn’t mean that others will see it that way as well.
5. Be consistent, always. I’ve seen more projects ruined by people doing things “their way” than anything else. Match style and design when working on an existing project. Be careful when adding new techniques, technologies, or methodologies to an existing project; unless you are willing to update the entire code-base, you can easily create a minefield without realizing it.

If you want your work to be seen positively after you move on, start thinking about your heirs today. The opinion they have of you will be almost entirely based on what they see in your code – not the stories or memories left behind.

¹ – There are always exceptions; these are generalized guidelines, not hard and fast rules.
² – This includes “throw away” projects, many projects that are intended to have a short life end up living far longer than intended. This is the most likely place that your heirs will find code that makes them question the quality of your work.

In December 2002 I made my first purchase from GoDaddy, since then I’ve spent $1,200 with them. Over the years I’ve seen them grow up to be a major force both in the registration and web hosting markets; I’ve also seen them go from lean and efficient to annoying and unfriendly.

Once upon a time GoDaddy had the best prices and the best search of any registrar; unfortunately things often change, and not always for the best. As time went on they added more products and adopted a very “in your face” style of marketing. For years I’ve dismissed the aggressive marketing as the cost of the low prices, but times have changed.

The aggressive marketing style, incredibly difficult to cancel subscriptions, feature lock in, and many other annoyances and issues. And why do I put up with this? It’s not the low prices, as for many things my current hosting company is far cheaper. I’m no longer locked, it’s not that. Loyalty? That it, well, that was it.

After 7 years, and $1,200 – I’ve started moving my domains over to my hosting company; and so far I couldn’t be happier. No aggressive marketing, good service, and they don’t nickel and dime me to death.

Loyalty can be a good thing, but how much is loyalty costing you? Is it worth it?

While trying to renew a few domain names recently, I found that cancelling the Privacy service that GoDaddy offers (via Domains By Proxy) is much more difficult than I had expected. The $8.99/year service conceals your name, address, and phone number from the public WHOIS listing.

Being concerned about privacy as most people are (or at least should be) it seemed a reasonable option but when multiplied by quite a few domains, it gets rather expensive. So during this last round of renewals I decided to cancel the service; figuring it would be no harder than removing the item from the shopping cart. To my surprise, it wasn’t nearly so easy.

Turns out that you have to sign into the DomainsByProxy web site with a Customer ID and password to cancel the service; so I tried the obvious and used my GoDaddy ID and password, though no such luck. I searched my email archives and didn’t find a single email from DomainsByProxy, at this point I was pretty sure whatever email address they had on file wasn’t valid, which is bad news for me. While there is an option to recover your customer ID, if their records aren’t accurate then it’s of no real use.

But there is hope.

It took a fair bit of reading and testing, but I finally found a method to get to your account IDs, and it’s fairly simple:

1. Go to the Private Registration Page on GoDaddy’s site (make sure you’re logged in to your GoDaddy account)
2. Type in some random characters into the search box
3. On the results page, click “Continue to Registration”
4. Click “No Thanks” on the ad page
5. Scroll down to the section labeled “3. Select Your Domains By Proxy® Account“

You should now see your customer IDs for the DomainsByProxy web site. The web site only shows the first four account IDs, if you have more than that you can contact DomainsByProxy and have them merge the account IDs you know. Just continue the process until you have all of your accounts merged into one.

Unless you’ve changed your password on the DomainsByProxy web site, your GoDaddy password should work. From there, you can update your information – or like me, cancel the service completely. Now you are free to renew the domain without paying the extra annual fee or transfer to another registrar.

I’ve been working on a project recently that uses avatars, while planning out this specific feature it occurred to me – why should we re-invent the wheel? There’s already at least one service that specializes in doing it right: Gravatar.

While building something as simple as avatar support takes a relatively small amount of time, when working against a tight deadline or a tight budget every minute counts. In the world of an ISV (especially a young one) the balance of user satisfaction and development time is critical. Using a service such as Gravatar is a great way to give the users what they want with minimal impact to the timeline.

With a super-simple implementation we were able to get it running within a few minutes – compare that to at least a few hours to build a custom system. Plus, reduced server load as we aren’t hosting the images and a cleaner, simpler interface as it’s one less option the user has to look through.

For those that have been looking forward to seeing the final result of Microsoft’s attempt at AJAX, your wait is over. ASP.NET AJAX 1.0 has been released.

I’ve not had time to test this yet, but it sure looks like it has promise. I’ll be playing with this one soon, I’ve got a couple new projects this might be perfect for.

A new version of the popular debugging proxy Fiddler has been announced. The new version, dubbed Fiddler2, adds support debugging HTTPS traffic just as you would unsecured HTTP traffic. Per the FAQs, this new version effectively runs a MITM attack to do its job, while this is the most effective way of doing this, there is the downside of the browser showing an error, though you should be able to continue by ignoring these warnings.

If you develop or maintain secure web sites, this enhanced version of Fiddler will be a great help. Though this is still an alpha version, it’s based on a fairly stable code base and seems to work well. This is one to keep an eye on.