Just how do you go about accessing the Internet while you are away from home? Today I’m going to do my best to sum up the three main options. To slightly differing degrees, this information will pertain to any sort of typical Internet/email/web/Twitter/Facebook access.

If you’re bent on carrying technology with you to stay connected on the road, the main factor that will drive your decision will be the wireless access in the region you’ll be traveling, and the associated costs. You will obviously have more options in modern metropolitan areas than they would be in, say, rural India. When you need the ‘net away from home, there are three main options, and my favorite option—perhaps surprisingly—is to travel free of technology.

Option 1: Laptop or Netbook

In this scenario, you carry a laptop or netbook, and periodically “jack in” to Wi-Fi networks in hotels, airports, major train stations, free Wi-Fi hotspots, or paid network ports. You will not have persistent access to the Internet; you will only be able to connect and check email when you are plugged in to a network. When you are connected, a laptop or netbook will give you the best experience (bigger screen, full keyboard, fast access—much like working from home), but this comes at a price: You need to lug a big piece of fragile, shiny, criminally-tempting equipment around with you, and it will only be really useful in certain areas where you can find a connection. At all other times, you’re essentially carrying dead weight.

Option 2: Smart Phone

Smart phones (Blackberry, iPhone, or similar) carry the promise of a handheld, mobile computing platform. These devices rely on cell phone networks, so, in theory, will work anywhere you can get cell phone reception (while driving in the car, even). However, there are two very important considerations to keep in mind:

1. When you are away from your “home” network, you are considered to be roaming, and roaming charges can be ridiculously high. There have been a lot of stories recently about people getting $60,000 cell phone bills for, say, watching half of a college football game on their phone. Of course, you’re only in danger of being blessed with a bill like this if your phone will actually work at your destination.
2. Depending to some extent on what phone you go with, email/Internet services may not even be available in certain areas when you are roaming. If you end up backpacking in the Scottish highlands, you might be lucky to get analog cell phone coverage, which means your Internet/email capabilities are dead in the water. If you’re thinking of going this route, you’d be wise to check out the digital/3G network coverage in the locations you plan to visit.

Option 3: Travel Free

I’m not pulling any punches, here; my bias should be obvious by now. I stopped carrying a laptop (or any other sort of network device) well over a year ago. Now when I need my email fix (once a day or less), I borrow a computer (or head to an Internet café) and use webmail (or, free remote desktop applications such as LogMeIn). If you go this route, you can expect to pay a few bucks here and there if the hotels you’re staying in don’t have free computer terminals, but even so, there’s no up-front purchase, and the per-use access fees themselves could well be cheaper than the Wi-Fi and cell phone roaming charges I’ve described above. Nomadic computing is getting easier to do every day, with the plethora of free web-based applications available, and more and more locations offering cheap/free computer use. If you tried this a few years ago, and were discouraged by the lack of availability, try again; the situation has improved greatly.

Now, don’t get me wrong: I like shiny gadgets at least as much as the next technology professional. But after schlepping a (small!) laptop literally around the world on business trips a number of times (and going for months of massage treatments to straighten my neck and shoulders out again), traveling without it has been a true joy. I would absolutely not hesitate to bum my way through almost any country with not much more than a decent GPS, point and shoot camera, and an (old-fashioned) hard cover notebook. Self-imposed technical luddism can be most refreshing.

Obviously, this advice will not be a good fit for everyone in all situations. For instance, some (but certainly not all) types of business travel are still easier when you pack your own hardware. What I’m suggesting is that you take another look at your scenario on a per-trip basis, and seriously question your dependency on that laptop or cell phone.

Happy travels!

Happy New Year, everyone.

Michelle V. Rafter has written an interesting article about multiple monitors. She contacted me in December to obtain permission to publish some of my comments. Her article contains a healthy dose of anecdotal support for multiple displays, as well as some links to multiple display how-to information.

Rafter makes the claim that “Business people who’ve made the switch say using two monitors — or even more — make them more productive. And they swear they’d never go back.”

To me, Rafter’s article serves as a good reminder to really evaluate your computer display(s) in the new year, to determine whether you really have the optimal display configuration for the type of work you do. (Do you?)

CAPTCHA challenges are so ubiquitous these days that major web sites are frustrating users by the millions with distorted text, mathematical equations, puppies, and more. CAPTCHA stands for “Completely Automated Public Turing test to tell Computers and Humans Apart”. Typically, they are employed to allow web sites to reject, for example, blog spam entered by automatic spam programs.

Unfortunately, CAPTCHAs don’t work.

The problems with CAPTCHAs

It’s an arms race. As spammers and attackers get better at programmatically breaking CAPTCHAs, web sites use more ridiculous CAPTCHAs, and so on. We are already at the point where many CAPTCHAs are very difficult for most humans to read:

Of course, on the other end of the spectrum, CAPTCHAs like the following are really just an inconvenience to both users and computers alike (this one is very easy for a computer to see, so it defeats the purpose of CAPTCHA altogether):

The majority of ordinary users are penalized for the actions of the minority of spammers. This is like forcing all drivers of a certain highway to take a breathalyzer test without probable cause in case they might be drunk.

Users with impaired vision (in some cases, colorblindness might be enough!) might find it impossible to read CAPTCHAs. On sites that do not have an audio CAPTCHA option, vision-impaired users are often out of luck. Heck, my vision is fine, and even I have to take several attempts at some CAPTCHAs.

Real humans are for hire. A truly determined spammer with a few dollars to spare can easily hire extremely cheap labor to sit at a computer and type in CAPTCHA responses all day long. Sadly, this is surprisingly cost effective for many spammers.

Humans will tend to give up after a few attempts, but computers are very patient by nature, and robots have numbers on their side. If a site doesn’t have any sort of rate limiting, a spam bot can and will easily hammer a form hundreds of times to slip one submission through.

For these reasons, current CAPTCHAs are far from a panacea.

In a nutshell

The pure idea is sound—to tell humans and computers apart—but, in my opinion, the execution is fatally flawed. All current CAPTCHAs, being “Completely Automated”, rely on computers to tell humans and computers apart. Essentially, this boils down to computers trying to fool other computers. See the problem, here?

Sure, if we had computers that could replicate human AI, they would probably do pretty well at telling humans and today’s computers apart. But, by then, the spammers’ bots will have full human AI, too. That’s an even bigger problem. See http://en.wikipedia.org/wiki/Turing_test

I am definitely not saying that web sites should immediately abandon all use of CAPTCHAs. I still use CAPTCHAs on this blog to slow down the spammers. I would get a few more comments from real users if not for that, but I understand the drawbacks, and I’m willing to take the hit.

It is beyond the scope of this article to go into a full discussion of all alternatives to CAPTCHA, so I will say only this:

Choose the right tool for the actual problem you need to solve.

CAPTCHA on, say, a sign-up page, can easily do more harm than good; you’ll be losing some percentage of legitimate users while you unwittingly support some 3rd-world economy. Basic rate limiting, exponential backoff, and reporting on new account creation, are probably enough for all but the most high-profile sites. But, again, this depends on a thorough understanding of your problem domain, coupled by a careful analysis of the available options.

One of the tenets of software process improvement (or, really, any process improvement) is conducting a thorough, honest “post-mortem” on a completed project. The concept is simple: you take a recently completed project (or well-defined milestone), and look at the good, the bad, and the ugly, and turn your observations into actionable steps you will take on the next project.

Actually executing a post-mortem can be a challenge to companies of any size. In my experience, there are a number of roadblocks to actually completing a post-mortem. This article discusses them, and is targeted towards the typical middle management software professional heading up a project. However, stakeholders of all levels will hopefully appreciate the points herein.

“We don’t have time to sacrifice billable/profitable hours to do a post-mortem.”

This is a difficult point to argue, especially when it comes as a directive from the executive. Even if you successfully browbeat the boss into letting your team do a post-mortem, you are then faced with the even more daunting task of later convincing him/her that the outcome is going to be a net benefit to the company’s bottom line, when you may not actually have the authority or the buy-in to implement all of the recommendations from the post-mortem.

All hope is not lost. For the purposes of a successful post-mortem, you really need buy-in from all parties, and I suggest you start from the bottom. I have consistently found that motivated developers (and even some unmotivated ones) are very, very eager to share their experiences and opinions, so get them on-board, along with vendors, customers, and anyone else with a stake in the project who is available for a few questions. Essentially, I am suggesting you go ahead and do the post mortem anyway—informally is just fine. Getting fired is unlikely. At the very least, you and your team will learn some valuable lessons, and it’s possible the chief may soften up, too.

“The project went well. We don’t need to do a post-mortem”.

This is a common pitfall. Whether the project really went well—or you think it went well—is debatable. Unless your company directly profits from the warm, fuzzy feelings of your project management team, you really need to analyze and measure your success criteria.

Let’s be generous, for a moment, and assume that the project was successful. The more successful the project, the more you have to gain by doing a post-mortem. Imagine the army of doctors that would line up to do an autopsy of a real-life Superman. The idea here is, find out what worked, why it worked, and then reproduce it.

“The project was on time, on spec, and on budget. We don’t need to improve.”

This seems to be a Holy Grail of sorts for some companies. It isn’t. Even though a project may indeed be on time, on spec, and on budget, who defined the timeline, specification, and budget? The problem is, some mature software and business teams get very good at working together and setting goals they know they can meet. To the extent attainable goals are a good thing, the danger lies in becoming complacent with sub-optimal developments.

The company that can develop a certain widget in 6 months for $500K is in for a shock (not to mention the possibility of significant lost revenue) when their competitor develops a better widget in 4 months. Wouldn’t it be nice to be ahead of the curve?

“The project was a flop for obvious reasons. Let’s not waste more time by over-analyzing it!”

To some, doing a post-mortem on a failed project can feel something like eating a box of thumbtacks; more so, if the outcome seems inevitable. Suppose you chose a vendor to develop a seemingly innocent bit of middleware for your project, and they significantly overran their deadline, creating a cascade effect on your entire timeline. It is easy to blame the vendor for your failure, and vow never to use them again. It is harder, and so much more valuable, to step up a level, swallow your corporate pride, and ask the more difficult questions, like:

• Was outsourcing this component really the best strategic move?
• Did we make any serious attempt to mitigate this risk in our project plan?
• Did we fail to recognize a dependency upon this vendor’s deliverable that caused the critical path slip?
• Were there any early warning signs that we failed to act on?
• Could a different approach to managing this subcontractor have helped us identify the problem earlier, or keep the project on track?

Of course these are just a few of the questions you might want to ask in a case like this. Always remember to keep a mixture of “standard” post-mortem questions, and to really ask the hard questions that are specific to the project’s circumstances, as well. Resist the urge to take a “clean room” approach and let just one person come up with all of the questions. Encourage all stakeholders to participate; good answers are more likely to follow good questions.

“We don’t want to say anything negative, because it will make us look bad/get fired/lose our bonus/etc.”

For whatever reason, some companies manage to create an unfortunate culture where employee performance appraisals trump honesty, and developers become loathe to admitting mistakes—or even suggesting improvements. To be fair, I doubt that companies’ top execs intend for this to happen. However, some of these same companies are also pretty bad at recognizing and fixing a gun-shy culture. Doing a post-mortem in this sort of environment may not net the most useful results, and shifting a defensive culture in short order may be next to impossible, in your position.

The best advice I can give you in this case, is to create a small bubble of trust within your project. Go one-on-one if necessary. If you think your stakeholders won’t be honest with you, that’s another problem entirely. Clearly this is not the best time to flex authority and demand honest answers. I have seen entire teams literally go stiff when someone takes this tack, with some mixture of fear, hostility, and apathy, in proportion to the relative burn-out of the team. Instead, I suggest finding someone on the team (probably below you) that is well-connected to most people, and have them take a soft approach. Put them in charge of gathering the inputs (preferably around the lunch table, not the boardroom table), and back them up with tools, information and mentoring, not muscle. Putting the best people on a task is of course one of your best strengths, right? Don’t forget to look at the project’s culture as part of the post-mortem, as it almost certainly had an effect on the project itself.

“We have done post-mortems before. Nothing ever changes.”

You are more likely to hear this sort of comment from the trenches. The perception (probably based in reality) is that the company’s efforts to analyze projects have historically not brought any real change. Developers don’t see the value, and believe the post-mortems are little more than a chance to vent, or pat themselves on the back, or otherwise waste time they could be devoting to the next project you are keeping them from.

There is no easy response to this assertion. If your people feel nothing has changed, they are probably right. Surely, not every recommendation will be implemented, but, by choosing a set of suggestions from a key project, and then reviewing the effects of those suggestions, in a visible and inclusive way, is the key to demonstrating a company’s resolve to benefit from the collective genius of its employees (not to mention vendors and clients). This need not be an onerous undertaking. Having a quick meeting—or at least some sort of announcement—a month or so after the post-mortem to review the implementation status of the suggestions will go a long way, providing some actual progress has been made. Having measurable criteria for improvement is also important, but the time quantum there is typically longer. Keep the door open for additional suggestions at any time, and, if one of the recommendations isn’t working, get rid of it. Obviously, before making a serious investment into any recommendation (including job creation), the company should absolutely undertake due diligence—just don’t over-analyze.

- – -

These are just some of the more common sticking points I have encountered. I am sure that the seasoned readers of this article will have had varying experiences when attempting to run software project post-mortems. Please do share your comments here!

For years, I’ve been using tidy (and perltidy) to clean up and pretty-print source code. I’ve also used the HTML output switches to produce markup that I can cut/paste into this blog. For short snippets, it was often faster to just hack the markup myself. Believe me, that gets boring pretty fast. Plus, as an author, it’s pretty tough to be a proponent of code reuse when you’ve been reduced to manually adding a bunch of <span> tags to your own blog posts.

Five seconds of searching led me to WP-Syntax. Installing was literally as easy as unzipping it in the wp-content/plugins directory and Activating the plugin from the WP Admin interface. Now, syntax highlighting is as automatic as it should be.

WP-Syntax will turn this:

<pre lang="c">
#include <stdio.h>

int
main(void)
{

    printf("Hello world!"); /* A comment */

    exit 0;
}
</pre>

into this:

#include <stdio.h>
 
int
main(void)
{
 
    printf("Hello world!"); /* A comment */
 
    exit 0;
}

I really have no excuse for not doing this much sooner.