The problem is, of course, that there are tens of thousands, perhaps millions, of users who used Megaupload for perfectly legitimate, legal storage of files. As of yesterday, all their access to those files is gone. Work documents that groups were collaborating on, family photo albums, insurance records, and other valuable documents, now completely unavailable.

The action is similar to the government discovering that a criminal is using the local post-office box store for transferring stolen goods. The feds swoop down; instead of locking that P.O. Box, then instead shut down the entire chain. Now, there’s tends of thousands of people across the country who cannot access their (perfectly legitimate) mail.

Of course, in the real world, it probably wouldn’t happen that way. The feds would target the criminals, and non-criminal users wouldn’t be affected. But let’s take this analogy one step further: the people who own and operate the chain know that their post offices are being used by criminals to transfer stolen goods. Moreover, the government prosecutors have clear and indisputable evidence that this is the case. Would a judge in this situation issue an order to shut down the entire business, seizing not only the illegal good but actually taking people’s perfectly legal property along with it? It’s possible, I suppose, but there would almost certainly be a period where, after the government has gotten the evidence it needs, the shops would be re-opened and people would be permitted to retrieve their mail. Will that happen in this case? I think it unlikely, but we’ll see.

Is this a reason to avoid storing your valuable files “in the cloud?” I think it is; certainly, the cloud offers an inexpensive way to backup your data, but I’m not sure that I would rely upon it as the primary repository of data.

Dear Sir,

SOPA and PIPA are bad laws that fundamentally affect the freedoms enjoyed by Americans. I do not want to see the USA using the same techniques as China and Iran to control our citizens. Moreover, I have worked in the Internet industry—previously, as an engineering manager for Yahoo!, and currently as a software architect for Rackspace hosting—and I can tell you that these laws, if passed, would create huge burdens on providers while actually doing very little to stop piracy.

I encourage you to drop your support for these laws. No businesses have ever been successful in the long term by using the legal system to repress competition, and these acts will simply NOT stop the mechanisms used, nor the motivations for, sharing illegal content. The solution to intellectual property infringement is NOT to place a huge burden on businesses to enforce someone else’s rights, and I, for one, am appalled as the loss of freedoms that have occurred in the USA to such an extent that such laws could even be conceived.

Yours sincerely,
Glen Campbell

To say that 2011 was eventful is a bit of an understatement. I began the year in an apartment in San Antonio, Texas, a scant month or so after starting a new job with Rackspace Hosting. I traveled back and forth to Beaumont and Houston more times than I can count to be with my parents in the hospital and, ultimately, to attend their funerals. I lost my brother quite suddenly to an aortic aneurysm, and my sister-in-law to complications from surgery. And I lost two dear aunts on separate sides of the family.

Given all that, the fact that my alma mater won a bowl game and had its first Heisman trophy winner in the school’s history doesn’t seem like such a big deal. And, in the grand scheme of things, it certainly isn’t (but I will definitely lord it over everyone else for the next year).

I remain, as ever, full of hope, however. I suppose I have reason to complain, but life has its ups and downs and its our job to handle what we’re given.

All the best to you and yours in 2012, and may God give you the strength to handle whatever challenges come your way.

Very cool (at least if you use Instagram).

Let me know if you have any questions.

First, as many others have noted, this is not really intended to be a generic tablet device aimed at toppling the iPad’s dominance of the market. It really is an upgraded Kindle with enhanced abilities to consume Amazon’s content: books, music, and video. It performs those tasks extremely well. Moreover, you can install selected apps from the Amazon App Store, so I can also view my Netflix movies in addition to the Amazon ones. Should I need to, I can check my email, though it must be said that the setup and usage is a sad disappointment to those of us who are familiar with Apple’s flawless execution in that department.

Let me expand on that point a bit: Apple’s iOS does things so well, users come to expect it. My primary email is on Google Apps; when I set it up in iOS, I specify “Gmail” as the provider, give it my email address and password, and voila! everything is set up perfectly. On the Kindle, I have to fill out an entire page of information, supplying the IMAP and SMTP server names and choosing authentication methods (Plain? CRAM_MD5?). Once set up, however, it worked fine.

I hesitate to blame some of the disappointments on Android, because I honestly don’t know if the issue is with Android or with the Amazon implementation, but there are many instances where the behavior is just a teensy bit poorer than on iOS. For example, the autocorrect suggestions are often incorrect on the Fire, whereas, I’ve come to rely upon them on iOS. When you double-tap the screen in the iOS Safari browser, the current

Nothing will happen for 10-15 seconds, which makes me wonder if I actually missed it, and then, suddenly, the app will load.

Games are great on the Fire, however. Going back to the iPhone after using the 7″ screen on the Fire seems like a huge reduction in usable space. The screen on the Fire is really beautiful, and the textured surface on the back makes it easy to hold. It is a bit heavy, so I tend to rest it on something—this is unfortunate, because the power button is on the bottom, and if you rest it on something, you can accidentally turn it off. The lack of an external volume control doesn’t bother me, as it has some users, but the lack of volume does. The iPhone is much louder (when playing music through its external speakers) than then Fire is; I can’t hear a movie, for example, when the dishwasher is running.

I have no complaints about the battery life so far.

Is it worth the $199? If you understand that you’re getting a media-consumption device and not a general-purpose tablet, then, yes, I think it’s worth it. You can get three Kindle Fires for the price of a 32G iPad, but they’re not as flexible. But music, movies, games, and ebooks are excellent.

IBM may have made the “personal computer,” but it was Steve Jobs who made the computer personal. Personally, I cannot imagine how the world would be different without the effect his singular vision has had on how computers and machines interact with each other. He was perpetually pushing us to “think different” and to do things better than we ever imagined. The list of his successful products are being listed all over the web.

But I’m also interested in his failures; if ever there was a person who learned from his mistakes, it was Steve Jobs. Do you recall the “Cube,” the beautiful but feeble Macintosh? He learned that beauty was not enough to make a good product; it also had to have performance.

The original “iPod Phone,” made in conjunction with Motorola, was a joke. With a crappy user interface and limited to only holding 100 songs (can you imagine?), this worst seller forced Jobs to confront the real problems in the phone business, resulting, ultimately, in the iPhone, the “smart phone” that changed the entire industry.

The Apple TV was, and still is, one of those “little projects” that Apple still plays with. It has its enthusiasts, but it’s never really caught on in the wider populace. Yet Apple keeps tinkering with it, convinced that there’s “something there.” Will Apple ever get it right?

So much product development consists of tiny, incremental changes. Much of it is based upon user feedback; this is good, but users don’t think outside the box. They don’t imagine things in a vastly different way than they already exist. When all personal computers had a command line and a 24×80 character display, Jobs envisioned (with the help of Xerox PARC) a fully graphical user interface in the hands of every single computer user. While the iPod wasn’t the first music player with a hard disk, it was the first to offer an online store, with the full participation of record labels, where users could simply purchase and download music as opposed to ripping MP3′s from their CDs. When every computer “had” to have a floppy disk drive, Jobs sold the iMac without one. (Side note: when my wife and I got our MacBook Airs, she insisted on getting the plug-in CD drive. We’ve never used it.)

The world is a better place because of you, Steve, and we will miss you.

However, one feature, at least, stands head and shoulders above the rest of the competition: Google Plus permits lengthy posts. One of my continuing frustrations with social media sites are the arbitrary restrictions they place on content. Twitter limits you to 140 characters (ok, I can understand that somewhat: it’s based on the SMS text message size that Twitter was originally built to work with). Facebook restricts the size of a post, won’t let you edit them, and makes it very difficult to insert even a blank line in a post. Even FriendFeed (the current feature leader among social sites) limits the size of original posts and comments.

But Google Plus does away with that; while I’m sure there are some length restrictions on posts and comments, I haven’t seen or heard of them yet. And I’ve seen people take full advantage of that fact, treating Google Plus more like a “social blogging platform” than a mere status update.

One of the reasons that I typically try to avoid discussion religion or politics online is that the current social media formats do not lend themselves to lengthy discussions—it’s really difficult to sum up a complicated argument about, say, economics, in a simple soundbite. This leads to a dumbing down of conversations and a more inflammatory tone (“you’re stupid.” “No, you’re stupid.”) which doesn’t really help anyone.

If anything stick out at me about the conversations on Google Plus, it’s the fact that they are real conversations, not snippets of discourse. People can say what they need to say without being constrained by arbitrary limits.

Other social media sites would do well to learn from this.

Google Plus has launched, initiating a flurry of interest among the bleeding-edge technophiles of Silicon Valley (the metaphorical one that spans the globe, not just the literal one in California). It’s ignited a frenzy of commentary and participation not seen since, well, not really seen before—few services have started with such furor and immediate adoption.

Some of those A-list technophiles have given up their blogs, simply redirecting their personal domain to their Google+ profile page. Others have claimed that Google+ is the “Facebook killer,” and still others are ambivalent. In reality, of course, much of this is hype, and one of two things will happen: either Google will continue to build out G+ so that it truly is competitive with services like Facebook and FriendFeed, or else people will come to their senses, retract their statements, and write cautionary blog posts on the dangers of getting caught up in a feeding frenzy.

Some commentators add additional hype, claiming that Google+ is “not a social network” and that Google’s announcement emphasized “sharing” and not the “social network” nature of the site. This is, of course, baloney. Google Plus is nothing but a social network at the moment; it has no other features beyond those required to connect people together and group them. This is better known (in some circles [see what I did there?]) as a “social graph,” which is exactly what Facebook and LinkedIn maintain on their users.

What’s really important about Google+, however, is what it’s missing, rather than what it has, at least for the time being.

First, let’s start with Google+’s core feature: Circles. This is the differentiator of Google from other social networks. Circles are a much more flexible method of defining groups; in Google’s case, they are strictly one-way relationships between a user and other people. Those other people can be on Google+, too, or they can simply be an email address. Thus, Google has expanded the implementation of a social network beyond the mere website. If I have a relationship with someone on Facebook, it is owned and maintained by Facebook; if I have one on LinkedIn, it is owned and maintained by  LinkedIn. Facebook has no knowledge of a relationship that I may have with someone via LinkedIn, and vice versa. With Google+, however, I can include any user that has an email address in my social circle; that way, when I share something, that person receives an email about it.

It’s a powerful feature, and one that helps ensure trust and privacy. Google+ assumes (rightly or wrongly) that the people I want to share things with are the same people whose stuff I want to see. Once two people have each other in a circle, they have effectively created the same two-way relationship that exists on Facebook or LinkedIn.

What’s surprising (for a company whose main business is indexing content) is how terrifically difficult it is to actually get content to share with people. At the moment, all content sharing must be done manually. Want to show someone a picture? You have to upload it or paste in a link to Flickr (assuming that it’s stored there). If you upload it to Google+, it’s stored in Picasa; there’s no way to have it automatically sent over to Facebook to share with your friends there—you have to do it twice. Create a cool picture on Instagram? The only way to get it into Google+ is to manually cut and paste the link. There is no automatic import or export of any content.

In all honestly, I have to assume that this will change in the future. WIthout it, Google+ is a mere skeleton of a framework of a social network. We’ve all gotten so used to being able to take a photo on our smartphone and instantly share it with our friends no matter what social network they’re on, it’s a huge step backwards to start living on a single service. However, that’s exactly what some people think you should do. In essence: everyone, stop using all the other services and start doing everything on Google+, and it will be great. Nice idea, but the world doesn’t simply work that way. It took years to get all of my relatives onto Facebook, and it will take years more to move them off. What this means is that, if I actually want to be able to share with all of my friends, Google+ will have to support sharing of data across multiple services.

Likewise, I’m not simply going to stop posting here on my blog; people will not simply stop using Twitter, and next year’s new toy will not fail because everyone refuses to leave Google+. I therefore need to have some easy way of getting content created elsewhere into Google+, since I want to share it with my friends. And having to paste it in manually each time simply won’t work. Again, I have to assume that this feature is coming, but it’s not there yet and, until it is, Google+ seems like a deficient copy of FriendFeed, albeit with a bigger audience.

Google+ also needs to allow better content moderation/curation once automated import is coming. For example, my friend Beth might be a SEO marketer and a photographer. I want to see her photographs, but I don’t want to have to wade through her marketing pitch; Google+ needs to give me the ability to selectively “mute” by types of content or origin. FriendFeed’s “hide other posts like this one” shows how to do this.

Finally, Google+ has to work out the bugs. Most importantly, they have to learn how to deduplicate the user’s stream. It’s frustrating to sign onto Google+ and see fourteen (!) copies of a post by Robert Scoble, simple because others of my friends decided to reshare it. Google+ could take a cue here from FriendFeed and implement the “also shared by” links that exist there.

I’ve reference FriendFeed several times here; I still use it, not because of the feature set it provides, but because that’s where my friends are. If Google truly wants to make Plus “like sharing in real life,” then they have to face my reality that my friends live on other social networks and let me keep sharing with them. Google+ is great technology that’s still raw and will hopefully improve quickly.

Use the comments to give your reasons!

While in California last week, I had lunch with a colleague from my days at Yahoo! In fact, I was the manager who hired this person, and I’ve watched him mature from a “wet behind the ears” (but very talented) n00b to a highly-skilled, valuable engineer.

One of the things that indicates maturity in a software developer is the ability to interact with others, to provide feedback when necessary, and to seek advice when it’s needed. This individual had been the technical lead on a project and was having his own problems working with some of the more junior members of the team. The junior members appears to be somewhat intimidated when asked about their work by the older team member—this is not uncommon, since a junior developer is often unsure of his or her work and feels self-conscious about showing it off.

In addition, if the team leader simply “drops in” and asks how things are going, it’s often likely that the junior programmer’s code is not in a set state for demonstrating. For example, the programmer may have been trying to isolate a bug, and has just put in a dozen or so lines of bugs, trying to determine which path the code is taking—not exactly the best time to show it off to your leader!

He asked my advice on the matter: how best to interact with his team members without intimidating them and yet still getting a feel for progress. I gave my advice, and here’s the note I received from him today:

Hey Glen,

I hope you are doing well. I just wanted to send you a quick thank you note for the advice you gave me over lunch the last time we met.

You may recall that one of my questions to you was how to ensure that a junior member of my team was pulling her weight without having her feel overwhelmed about her work or making her nervous with my presence. Your response was a two-fold solution: a) to remove the element of surprise by setting up regular meetings with her and b) to make these meetings as much about showing progress as talking about it.

I am happy to report that we have been having said meetings since the start of this week and already there is a noticeable improvement in her work — not only is she delivering more than before but she has also become more open to asking questions rather than making assumptions (probably because she realizes it is the safer route to solving problems).

So thank you for your advice. Not only is our project humming along nicely now but I feel a small sense of accomplishment on a personal level too.

I, too, feel a “small sense of accomplishment on a personal level.”

Sandy Walsh, a colleague of mine at Rackspace who also works on the OpenStack cloud development project, has written a blog post on how Iterations and Time-boxing are (Mostly) Useless. It’s a well-written, thoughtful post, and I appreciate his perceptions, but some of them are (to my point of view) strikingly incorrect and unsupportable.

His general thesis can be summed up by these sentences:

Personally, I think Distributed Revision Control Systems (DRCS) such as git, bazaar or mercurial are the most significant change in software engineering within that last 10 years. Not because having a non-central repository is so revolutionary, but because branching and merging has become such a low-cost operation that the speed of software development has increased dramatically. Development shops that utilize these tools can see some big improvements in how they deal with the “Rough Edge” at the end of the sprint.

A major point of contention with Sandy is that neither the Agile nor the Scrum methodologies specify a branching or merge process, and thus it’s not the revision control system that dictates whether or not the methodology works. In addition, some of Sandy’s perceptions of the Scrum process appear to be slanted by not having had the experience of working in a smoothly-running, experienced Scrum environment.

There is nothing in Scrum or agile development that requires the use of any specific revision control system, branching, or merge process. In fact, many development teams use Scrum in conjunction with continuous integration, in which there is no branching or merging. When I worked with the Yahoo! media group, all developers worked in the trunk, and branches were only created to save the state of specific releases. To do this requires a definite commitment from the developers; it requires having excellent unit test cases and software designs that permit features to exist in the code but to be “switched off” until they are complete. Continuous Integration is a methodology that has great rewards for the teams that make the commitment to it, but it has nothing to do with Scrum.

Agile (and it’s angry child, Scrum) do not lay claim to be the end point or most perfect method for developing software. (Of course, there may be proponents out there who say this, but I’m speaking for the community in general.) What the methodologies offer, however, is a better way of responding to changes in requirements than more fixed, longer-term methodologies such as waterfall.

Sandy’s post makes some very good points, such as the fact that there is often some “dead time” at the end of an iteration (a sprint cycle in Scrum). The fact remains, however, that such dead time is a very small prices to pay for the predictability of delivery. Moreover, nothing precludes a developer from getting a head start on the following iteration’s work, though doing so might conflict with changes that come up in the next iteration’s planning session, and thus that work might have to be discarded.

Most businesses value predictability over sheer speed of delivery; it’s very rare that “as fast as possible” is a true business requirement. If you’re developing a new product, for example, shaving a day or two off of each iteration might (and it’s a definite maybe) permit the code to be completed earlier, but there are external considerations (marketing collateral, sales and support training, and documentation, for example) that may not be able to adapt as rapidly, and thus the “wasted” days are simply piled together at the end of development rather than spread out in the middle.

Sandy has some rather specific complaints about Scrum:

If you know me, you know I’m not a big fan of Scrum. I don’t like the hand-waving concept of Velocity and I don’t like the fact that it places a priority on process over code.

There are two responses here: first, to the “hand-waving” concept of velocity, and second to the “priority on process over code.” The second one is easier to answer, and can be found on the Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, [and] responding to change over following a plan.

If Sandy has found Scrum adherents that are placing a priority on process over code, then I would submit that they are most decidedly not following the Scrum methodology.

About the the “hand-waving” concept of velocity, Sandy states that “story points” need to be equated to time. I believe that that’s a very dangerous path to take. One of the reasons for “story points” is that, as Sandy says, “estimation is hard.” Rather than take a “Wild Assed Guess (WAG)” at when something will be completed, story points provide a mechanism for, up front, before you get into the weeds of developing something, to rationally estimate the overall complexity of a feature/requirement/story (like Sandy, I sometimes hate the terminology nuances). The fact is, it’s not (or should not be) a “wild assed guess”; it should be a reasonably well-educated guess, based on the developer’s (and product manager’s) past experiences and expectations.

Velocity, in its best case, simply measures how big is the “stuff” that a team thinks it can complete in a specified period (timebox). Why a specified period? Because without it, there’s no way to relatively measure the “size” of a feature without getting down to the development tasks in hours or minutes, something we want to avoid. In addition, timeboxing forces the development team to reach a stable state regularly, allowing the customers an opportunity to adjust and modify the requirements, and the developers to assess and change their work methods (and hopefully improve them). Sandy’s strategy of “overlapping” development is time-efficient, but could easily result in either features that need to be discarded (wasted work) or features that should be discarded, but aren’t (because so much effort has been put into them already).

There’s no methodology that’s perfect; I have seen year-long software development project using Yourdon’s strict waterfall method delivered on time and under budget, and I’ve seen development teams double their efficiency by using Scrum. One of the keys is to have the developers themselves be thinking about the process and ways to improve it, and Sandy, via his post, is a great example of that.

I have been a huge fan of Continental Airlines since the early 1990s. I have flown hundreds of thousands of miles on them, and I’ve encouraged friends, coworkers, and family members to fly them, too. For years, they had a stellar on-time record and a great frequent-flyer program. But, more importantly, they always treated me well, personally. They at least acted like they cared about me and my problems.

The first time I ever flew First Class was when a Continental gate agent took pity on me arriving, wet, grouchy, and late, to a flight at Newark International. She gave me a complimentary upgrade and it helped me to relax and look forward to the weekend.

I lived in Europe for five years and all of my trans-Atlantic flights were on Continental. When my wife had to go to an unexpected funeral, Continental helped to arrange the last-minute travel.

Today, the airline managed to reverse twenty years’ of good will in a matter of minutes.

I’m booked on a return flight from San Jose to San Antonio, with a change of planes in Houston. My father (who lives in Beaumont, TX) went into the hospital yesterday morning with some broken ribs and a subdural hematoma after a fall. I talked with my brother (who lives in Houston) and he offered to put me up for the night so that I could visit my Dad in the morning. I have tickets for the Houston Astros game in Houston on Sunday afternoon, so it seemed logical that I could stay with him and drive back with my wife after the game.

I had already checked in to the flight, however, so I arrived at the airport about two and a half hours before the flight so that I could drop the Houston-to-San Antonio leg of the trip, and make sure that my luggage got off the plane in Houston.

The first surprise was learning that the Continental ticket counter wasn’t open. There was a large queue of people waiting, and the sign telling me that the ticket counter is open from 4-7AM and then from 10-noon. No one could check in early or drop off bags because the ticket counter was unstaffed.

Next, after waiting for the staff to arrive and process the people in front of me, the agent informed me that I could not simply drop the final leg of the flight. I would have to cancel the remainder of the ticket and pay for an upgrade to not fly with them. The thought of this is staggering; it took me a few minutes to get my head around it. Their silly rules mandate that, for them to avoid weight, labor, and excess trouble, I have to pay them extra. She told me that, if I wanted to get off in Houston, that was my business, but my luggage would have to be checked on through to San Antonio.

Luckily, I had packed all of my clean clothes in my carry-on backpack, so that’s not a problem, but the implications of this are, frankly, scary. Because of the risk of terrorism, it used to be illegal for airlines to carry luggage without the accompanying passenger. I’ve seen it happen before; someone fails to show up at the gate on time, and they had to hold the flight to remove that passenger’s baggage.

Needless to say, I’m booked through to San Antonio, as is my luggage. Who knows what will happen in Houston?

I work for Rackspace Hosting (see the Disclaimer on the home page of this blog), the home of “fanatical support.” Our objective is to be the best service company in the world, not just our industry. One of our business role models is Southwest Airlines, a company that, in spite of its quirks, still has a real person answer the phone or respond to your tweets. Continental, presumably as a result of its merger with United (“breaks guitars”), has opted to avoid providing good service and simply hope that people will have no other options when it comes time to travel. Unfortunately, that may be true at times.

But you can bet that, when I’m given a choice, I sure as hell ain’t choosing Continental again.

The normal modus operandi of the technology community is for companies (and their employees) to keep things close to their chests. Intellectual Property (“IP” in the vernacular) is the currency of choice in Silicon Valley and beyond. There is a real (monetary) value in having some unique technology because you can leverage that to sell products that everyone wants, but for which you are the sole provider.

On the other hand, if the technology is not unique, then it can be a very good thing to drive the value down (all the way to zero, if possible), because businesses can then compete on other measures. My employer, Rackspace (see my disclaimer in the sidebar), is a services company. We don’t sell technology per se, at least not in the same way that Apple sells it. Instead, we sell services, so it’s helpful to us for the technology cost to be as low as possible.

This week, I’m attending the OpenStack Conference and Design Summit in Santa Clara, California. From my personal experience, this is the most open and collaborative that I’ve ever seen a large (130 companies) gathering of businesses in the same industry. There are network companies, hardware companies, software companies, and non-profit organizations all represented. And everyone here is working together to define and improve the OpenStack software.

This morning, for example, I had chats with representatives of AT&T, Wikimedia, and Intel, among others. Everyone is working on the same project, and we’re sharing tips and tricks with people who, on another level, are our possible competitors. The best analogy I can envision is something like professional sports; while two teams might be competitors, it behooves everyone to ensure that they have consistent rules to play by and facilities to play on.

And, frankly, it’s refreshing to be able to talk about what I do at work without continually having to ask myself if I’m revealing confidential information.

OpenStack, the open-source cloud-computing framework that I’m working with here at Rackspace, has announced its latest release today. This is the “Cactus” release, alphabetically following Austin and Bexar, and to be followed by Diablo. Read the whole press release for details.

If you’re not familiar with it, OpenStack has a number of cloud computing projects, including Nova (the compute framework that I’m involved with), Swift (a file storage service similar to Amazon’s S3), and Glance (a service for persistently storing virtual machine images). Other services are planned for the future.

The next release of OpenStack will kick off at the OpenStack Conference and Design Summit in Santa Clara, CA, during the last week of April. I’ll be there, so contact me if you’d like to get in touch then.

Reports that say that something hasn’t happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns — the ones we don’t know we don’t know. And if one looks throughout the history of our country and other free countries, it is the latter category that tend to be the difficult ones.

The language may be convoluted, but it’s impeccably true. We can be aware of our own ignorance: the “known unknowns,” according to Rumsfeld. However, it’s the things that we are yet unaware that we are ignorant of that are likely to bite us in the ass.

Software development has two major components. First, and most simply, is the active design, development, and testing of the code. Secondly, however, is the planning and coordination of the delivery of that code. Generally speaking, the larger the first part is, the more difficult the second one. A single programmer working alone can often easily predict how long it will take him or her to complete a specified unit of work. The more people that get involved in a project however, the more uncertain things become.

The ability to predict software deliveries is important (well, it’s important to companies that sell software or services based on software). For example, it’s quite possible that a software product might take so long to develop that the company will never recoup its investment (hence the huge amount of interest in early or first providers of software services). And, like military operations, it’s the “unknown unknowns” that are impossible to plan for and difficult to handle when they occur.

Scrum and related “agile” development practices tend to focus on iterative development and planning in an attempt to mitigate these sorts of unexpected changes. They’re not, as some people might suspect, intended to let the product stakeholders change their mind on a whim. The central idea is that, by breaking development up into discrete chunks (where each chunk is fully functional and working), it gives the development team opportunities at regular intervals to change direction or adapt to new circumstances.

Teams that are new to scrum often have misperceptions of the practice, ranging from a misunderstanding of the various components (stories, tasks, standups) to a reluctance to move away from personal responsibility to team-based management. One of the scrum fundamentals, however, should remain at the core focus of the team: scrum is focused on delivering working software, and not on time tracking, management reporting, or a plethora of other benefits (perceived or real) that might come out of it.

When you’re faced with an uncertainty in the scrum practice, ask yourself: How can I best deliver working software in a predictable manner? If the process doesn’t support that, then get rid of it. Unexpected events happen: for example, you might start on a feature, only to discover that it’s much more difficult than you originally anticipated. While that points to a need to improve your planning (and that’s an ancillary fact that needs to come out at the retrospective), you need to ask yourself what you can do to deliver some working software. If you can reduce the scope and only deliver a small part of the larger feature, then do that. If you can bring in someone else to help, then do that. There’s no right answer.

By resynchronizing at the end of every spring cycle, scrum lets a team handle not only the “known unknowns,” but also the “unknown unknowns” that inevitably attack the software development process.

I was diagnosed with presbyopia—”old eyes”—in 1997. At the time, the optometrist said that it’s not unusual, it’s just that I was getting it about 10 years before most people.

In 2002, I took myself to the doctor because of “crunching” noises in my knees that I could hear when I went up and down stairs. He referred me to a specialist, who told me that I had arthritis. It’s something most people will get eventually, he told me, it’s just that you’re getting it about 10 years early.

In 2006, we replaced the mattress that we had purchased when we moved to England in 1996. Both my wife and I had been having problems with pain—shoulder, back, etc., and we thought a new mattress might help. It did, mostly, but I still had a fair amount of back/hip pain and I lost a lot of mobility.

When I moved to Texas last November, I was still having some problems. I just assumed that it was old age and arthritis, and continued to take my Naproxen Sodium (Aleve), which seems to make things bearable. In December and January, I was living in temporary housing, a furnished apartment. A week or so before Christmas, I managed to twist something in my back, which hurt so bad that I really had trouble moving.

The pain persisted, and towards the end of January I scheduled a doctor appointment to talk about my back. The doctor’s appointment was in the first week of February.

In the mean time, we bought a house, and, since all our furniture was back at our old place in California, I arranged to purchase a new bed (mattress and box springs) and have it delivered to the house on the day we signed all the papers, since the movers wouldn’t be coming for a few weeks.

We had wanted a king-sized bed, and we decided to put our old (queen) bed in my son’s room, since he had outgrown his twin. It also let us use his room as a guest room. The new bed, a Stearns & Foster, was delivered that evening, and we slept on it the first night in our new house.

At the end of that week, I had my doctor’s appointment. She did various tests and manipulations, and decided that there was no major damage, and that I had probably pulled a muscle sleeping on the bed in the furnished apartment.

The thing is, in the three days since sleeping on the new mattress, I was already much better. I continued to improve and, by the middle of the next week, I was nearly pain-free for the first time in a decade. (I say “nearly” because I can still cause some twinges if I twist wrong or overstress my back, but mostly I’m pain-free.) In the two months since then, I’ve stayed free of pain, able to walk reasonable distances and go up and down stairs without any back problems.

I still have the arthritis in my knees, and I need to take the Naproxen Sodium for that, but it’s amazing that my back has been well for so long.

I am assuming that it’s because of the new mattress.

This is not a hugely expensive, top-of-the-line model. In fact, it’s roughly equivalent to the one we had purchased back in California. It is somewhat less firm than that one, and I assume that the softness lets my back rest in a more comfortable state than the slightly more firm, older mattress did.

I’m not touting a particular brand or model of mattress; I don’t really think that what works for me will work for everyone else. However, I still feel astounded that a mattress could make that much difference. In my parents’ day, you got a bed for your wedding and, if you were lucky, you replaced it when you retired. Many of the beds in my home growing up were 40 or 50 years old.

Many of the newer technologies—memory foam, multi-point suspension systems—seem to be well-researched and actually provide benefits. I’m still convinced that the mattress industry is making huge amounts of money for what they sell (and I still believe they’re scamming us, otherwise, why would they sell us a mattress with a 20-year guarantee and then tell us you need to replace your mattress every eight years?). But in this case, I’m more than happy to pay for it.

Mark was 54 years old when he collapsed at work and died of an aortic aneurysm; something the coroner called “natural causes.” There were several trained EMTs in his classroom, and they were unable to help. I’m told that, even if he had suffered the ruptured aneurysm on an operating table under the care of a talented cardiac surgeon, his survival chances would have been minimal.

None of that makes much difference to me, honestly, nor to his five children or his five grandchildren, nor to his wife, his parents, or his other two brothers. He’s gone, and there’s a gaping void there that I expect not even time will fill very well.

What surprised me most, however, was the outpouring of grief and support from his coworkers, customers, and even competitors. I’ve grown up hearing that, “No one, on his deathbed, regrets that he didn’t spend more time at work.” But few people, it seems, have so successfully made work a part of his life as my brother Mark. In all honesty, do you think that your customers would mourn your passing? Mark worked for ITT Goulds Pumps, and a huge percentage of the dozens of flowers at his funeral were from his customers and distributors.

The last time I saw Mark was, in fact, at a work function; his regional sales team had a meeting in San Antonio, and Mark invited me to join them at a San Antonio Spurs game there.

We enjoyed the game, and, when it was over, I offered to shake his hand. He ignored that and hugged me instead, the last time I would see him alive.

There’s a phrase that’s popular with Human Resources departments: “work-life balance.” For me, that often meant a clear-cut separation between work and (so-called) life. For Mark, they blurred together, and coworkers and customers became friends and family, and friends and family members became people with whom he could do business. It hearkens back to a older era where a person was known by his profession. Tom, the miller, became known as Tom Miller. Bob, the carpenter, was Bob Carpenter.

It’s an entirely honorable thing to be passionate about your work, and to let your work cross over into your life. When friends at work become part of your family, you haven’t lost part of your family; you’ve grown it, in fact.

I made a comment on Twitter the other day that “I work with a team of rockstar developers @rackspace!” I’d like to make sure that this is understood.

Calling someone a “rockstar” could possibly mean that they are overpaid, under-talented, self-centered divas. That’s not the meaning that I was trying to convey. In this case, I’m using rockstar to mean someone who is superbly talented at his or her job.

In most development teams I’ve worked on in the past, there’s usually one or two senior developers, a few people with 5-10 years of experience, and a bunch of younger (“junior”) programmers. This is quite normal, and it ensures that the expertise of the senior folks gets distributed to the less-experienced members of the team. It also makes financial sense to the business, because junior programmers cost less than senior ones, and, even though they may be less productive, they can still leverage the expertise of the more senior developers.

What’s unusual about this team at Rackspace is that, in essence, they are all senior developers. They approach their jobs with a professionalism and maturity that is extraordinary to see in action. When there is a discussion, there is often passion around issues, but there’s always a mutual respect that shows itself in a willingness to always entertain the other team members’ ideas. Instead of divas fighting to get their own way, it’s more like explorers trying to find their way through a new land.

Often, with younger developers, there is sometimes a sense of panic when they’re faced with a challenge or a problem they haven’t seen before. Senior engineers realize that the new problems are not only part of the development process, but are often the coolest things to work on. They don’t generally get upset or frustrated, but are always trying to find the best path through the maze of issues that they confront on a daily basis.

It’s a challenge every day to keep up with strong developers like this, and it seems that the mutual interactions are what helps keep all of them pushing forward.

As I think I may have mentioned before, I’ve taken a new job as a software architect for Rackspace; specifically, I’m working in the Rackspace Cloud division. In the spirit of eating one’s own dogfood, then, I’ve created a Rackspace Cloud Servers account and have started to migrate my personal websites to it.

This blog, for example, is now hosted on the Rackspace Cloud. Hopefully, you shouldn’t notice anything different or unusual, though I’m now actually running on a different operating system (CentOS, a flavor of Linux) than on the old site (FreeBSD).

The cool thing, to me, about cloud hosting from Rackspace, is that the billing is done like a utility: in this case, I’m charged per hour for when the site is up and running. If you need a server, you can create a new one in a matter of a few minutes, then delete it when you’re done, and you’re only charged for the time that it’s in use.

1. California. I mean, seriously, you have to ask?
2. No state income tax.
3. Gasoline is $2.49/gallon.
4. My family is in Texas.
5. Watch me convert from a conservative demagogue to a liberal hippie in 24 hours, without changing any of my opinions.
6. I’ll be able to say, “I’ll Google that,” like all my friends.
7. Excellent BBQ available from places that also sell motor oil.
8. I can buy a $2 million Palo Alto house for $149,000 in San Antonio.
9. They know how to fix iced tea.
10. No longer have to deal with the internal consequences of garlic fries.

On November 29, I start a new job as a software architect for Rackspace, based in their San Antonio, Texas, office, and working for their Cloud Hosting division.

Changes like this are never easy, and I leave behind a wealth of experiences and friendships in California that I wouldn’t change for the world. While at Yahoo!, I had the privilege of:

• participating in the redesign of Yahoo! News and rebuilding a new, PHP-based frontend;
• owning the technical leadership of Yahoo! Tech, the first new property in the Yahoo! Media group in five years, and one of the first properties at Yahoo! to use an entirely webservice-based architecture;
• helped design and launched Yahoo! Shine, a successful venture into the lucrative women’s website market;
• driving Yahoo! News again towards the adoption of new technologies; and
• helping to make the Media Group leaner, faster, and more nimble with the introduction of key processes and technologies, some of which are launching this week.

I’m also leaving behind some of the most talented and passionate engineers that I’ve ever worked with.

Pundits, please don’t misinterpret this: I’m not leaving from Yahoo! or because of Yahoo!—I’m moving on to a new job in a location (Texas) that I’ve wanted to return to for many years now. We left Texas in 1996 to work in Europe for a startup; we moved to Silicon Valley in 2000 for the opportunity. Now, we’re heading home.

I think that George Strait sums things up quite eloquently.

For the last month, I’ve been using the Livescribe Echo “smart pen” and, honestly, it’s changed my life.

What, you may very well ask, is a “smart pen?” In this case, it’s a pen that records whatever you write with it, and it also records audio of what’s taking place around it. Unlike a pen that doubles as a voice recorder (of which there are many), the Livescribe pen actually synchronizes the audio it’s recording with what you’re writing, and it’s amazing. You can tap on any word you’ve written, and the Echo will replay the audio recorded at that time (you can also set a lag delay, so it will start, say, 10 seconds before you wrote the word).

I first heard about the Livescribe pen in a NY Times article that described the benefits for school students. When I read that article, it illuminated many of the problems I’ve had with taking notes in the past: first, I can’t take notes and simultaneously focus on what the speaker is saying. Second, I can’t take notes as fast as the speaker can talk. And, finally, my notes are often inadequate to bring to mind the details of the conversation at the time.

My job includes a lot of meetings. As a software architect, it’s my role to argue and collaborate: with engineers, with product managers, with other architects. But, since I have a mild attention deficit, I don’t always pay close enough attention. The Livescribe pen is always on, so I can always refer back to the meeting itself.

BUT WAIT, THERE’S MORE! I’ve saved the best for last: in addition to synchronizing the audio and your notes, you can actually download all your notes and audio to your Mac or PC. AND IT LETS YOU SEARCH YOUR HANDWRITTEN NOTES! I cannot emphasize how important this is—through some sort of OCR-like magic, you can search for (and find) any text in your notes, with a very high level of accuracy.

How it does it

The pen requires special paper that has a special dot pattern printed on it. Using the dot pattern coupled with an infrared (IR) viewer on the pen, the pen “knows” where it is on the paper at any moment. You can buy various types of paper (notebooks, journals, etc.) in various sizes, either direct from Livescribe or via Amazon.com or other retailers (such as Staples). With the Livescribe Desktop software, you can also print your own paper (though only to a Postscript-compatible printer).

Because the pen knows where it is on the paper, the controls (record/pause, bookmark, volume, playback speed, navigation) are actually printed on the paper. Tap the “up” button, and the volume gets louder. You get the idea.

What’s the catch?

The downside of this, of course, is that you have to buy or print special paper. A pair of bound, 200-page journals costs around $24.95, and a pack of four spiral notebooks (also 200 pages) costs $19.95.

The pen itself is not cheap: the largest, 8GB model costs around $170.00, though versions with less capacity are available.

Also, unlike other pens, this one can crash. I’ve only had it happen to me once: in that case, it retained all my notes, but lost all the audio.

The pen itself is a bit fat, and might not be comfortable for everyone. I haven’t had a problem with it, but I could easily see how someone else might not like it.

Finally, the cap to the pen sucks. Seriously. It’s so bad that they even provide extras in the packaging, because you’re almost certain to lose it. (It’s not attached to the pen in any way.)

What else?

Livescribe is very good about keeping their software (both the desktop and in the pen itself) updated. In the time I’ve had it, there has been two pen updates and one update to the desktop software. They use these updates to not only fix bugs, but also to add new features. For example, the latest Desktop update lets you export your notes to Evernote or PDF.

You can also install “apps” on the pen. One pre-installed app is a Piano: you draw out a piano keyboard on the paper, and then you can play it, even recording the tunes you play.

You can also record “pencasts” — viewable by anyone — where you can show someone your drawings and your notes at the same time. I haven’t used this much myself, but it might be really useful for some people. Here is a sample pencast I recorded for this blog post.

I will occasionally write reviews here of products that I’m particularly enthusiastic about, or which I find myself using frequently. The Apogee ONE is just such a product: it’s a very high quality digital audio interface (I just made my high-school English teacher cringe by stringing five adjectives before a noun).

But first: what the heck is a digital audio interface anyway?

Simply put, it’s a device that translates an audio signal (for example, the sound of my voice captured by a microphone) and converts it into a digital signal that can be processed by a computer. Specifically, this little device has an input (actually multiple inputs, though you can only use one at a time) and a USB output that plugs into your computer (specifically, your Macintosh—I don’t believe that Apogee supports Windows PCs). Let’s say you want to record a podcast; you’d plug in the digital audio interface into your computer via its USB port, then plug a microphone into the audio interface, then start your recording program (Garageband or Logic Pro for me) and record something.

Sure, you could use your computer’s built-in microphone, but an external mic is almost always a higher quality. For example, you can use a directional mic that will only pick up your voice, and not all the rest of the noise in the room. The reason you use a digital audio interface, and the reason that some people will pay large amounts of money for one, is because you want to have a very high quality recording. Specifically, you want to have fidelity, a fancy word derived from the Latin word for “faithful.” You want the recording to sound as much like the original as possible.

That’s what the Apogee ONE does; it maintains a very high quality digital signal that’s faithful to whatever you plug into it. More importantly, it does so in a very simple manner.

Let’s talk about inputs: first, you don’t really need one. The Apogee ONE has a built-in microphone, which is a rarity in the world of digital audio interfaces. Specifically, it has an “internal reference condenser microphone that has been fine-tuned by professional recording engineers.” Whatever. The fact is, it’s a very good microphone by itself. Most of the voiceovers you hear on my podcast are captured using only the Apogee ONE.

Second, it has a “break-out cable” into which you can plug either a standard 1/4″ plug (such as a guitar cable) or any XLR device (most professional microphones use an XLR input). If you’re using a condenser microphone, it can optionally supply the standard +48V phantom power required to drive them.

There are two other plugs on the device: one is for the USB cable that connects to your Mac, and the other is for a headphone or speakers. The latter is important; many applications (for example, Logic Pro) assume that any audio interface you’re using will be handling the output as well as the inputs (Garageband is a bit smarter, in that it lets you set them independently).

Finally, on the front of the device, there’s a single large knob. Depending on the context, it either lets you select the input device (internal mic, external mic, external instrument, or external mic with phantom power) or set the gain level for the selected microphone. There are also a pair of LEDs (invisible during normal operation) that show amber when you’ve reached peak level, and red when you’ve exceeded it.

When you’re not using it, the device and all the associated cables pack up into a little stretchy carrying case. It’s given me trouble-free operation (with very high quality) for almost a year now, and at least 15 episodes of my podcast. It’s available at Amazon (and other retailers) for about $249.00.

How do you let your manager (or perhaps the Senior Vice President of your division) know?

In most cases, if you’ve given frequent, regular status reports, there should be no surprise. But we all know that we can’t expect every contingency, and something totally unexpected pops up from time to time. The first rule of status reporting is “no surprises,” but—whoops!—here comes a big one.

Frankly, there’s no easy or perfect way to deal with a situation like this. Often, in business, a lot of time and money will be lost. The band that is supposed to play at the announcement, for example, will still have to get paid for their time. But here are some suggestions for retaining your professionalism and your dignity during the process.

DO let them know as soon as possible. “Boss, we’ve found an issue that may affect the launch,” is much easier to hear a week before the launch than a day before the launch.

DON’T try to assign blame, or let your boss do that—at least, not yet. Inevitably, the first questions your manager will ask are, “How did this happen?” and “What are you going to do to fix it?” Your response should usually be, “We’re trying to make sure we fully understand the extent of the problem. Unfortunately, it’s going to take some time to resolve.” You will only compound the error if you tell him or her your first theory and it turns out to be wrong. You need to communicate that there is a problem and that you’re working on it.

DO let them know that you appreciate the urgency, but don’t sugar coat it. “We think that the code for the phlebargle is iterating too much, and it should be a simple fix,” sets the expectations too high. Be realistic: “The code is inefficient, and we need to test our fix before we can commit to it,” lets your manager know that you are working the problem and that it’s still urgent.

DO give your manager the bad news in person if possible. A face-to-face meeting or a phone call will not only give him or her the opportunity to ask questions and get answers, but also to make eye contact and let him or her hear the tone of your voice. A terse email sent at 3:00AM is liable to have your manager stewing in impotent rage and worry for hours.

DON’T kill your team. It’s tempting to say, “We’ve been working on this for 48 hours, and we’re not gonna stop until it’s fixed!” But the only thing your macho act will get you is disgruntled, inefficient engineers. No one can work so many hours and still maintain a high level of output. Professionally and firmly, tell your boss, “We’ve spent 36 hours straight working on this, and people are a bit dazed. I sent them home to get some sleep and, as soon as they come in tomorrow, we’ll put together a plan on how we’re going to solve this.” Your team will respect you for it, and your boss will hopefully understand.

DO accept responsibility and the consequences. If it’s a bad enough screw-up, you might lose your job. I’m sorry to have to say that, but the reality is that there are certain expectations put on people in leadership positions and, if they can’t meet them, those leaders may need to be replaced. However, in my experience, tough times like this are excellent for helping to reveal the true leadership qualities of an individual. By acting professionally throughout the crisis, you can often increase your stature within the organization, especially if the problem was truly novel. On the other hand, if the problem was foreseeable, then you or your team should have foreseen it and had a plan to mitigate the potential problem.

Which problems can be foreseen and anticipated and which cannot? Unfortunately, that’s pretty industry-specific; since I’m a software engineer, I’ll probably write another essay on that topic in the future.

I’ve used Logic Studio, GarageBand, and a host of other multi-track recording systems before and, in all honesty, Logic and Garageband are probably much more suited for professional use. But the simplicity of the Pocketstudio makes it wonderful for experimentation and composing, and basically just “messing around” with music. It’s not going to replace the high-end, computer-controlled systems, but its ease of use gives it a special niche.

For example, if I want to record a guitar track, all I really need to do is to turn it on. It has two built-in microphones on the front of the unit, and they do a perfectly adequate job. For better quality, however, I can plug the guitar into the 1/4″ input socket in the back, and this eliminates extraneous noise.

With Logic, for example, there’s a ton of overhead for even a simple recording. From ensuring that the audio interface is connected to setting up tracks in the software, there’s a ton of complexity. With the Pocketstudio, it’s just plug-in and go. Frankly, a (small) number of knobs and buttons is a much simpler interface than trying to use a mouse to navigate through multiple levels of menus on the computer screen.

The DP-008 lets you record two tracks at once (i.e., you can’t record a full band all at the same time). It records to a standard SDHC card (I’m using a 16GB model, which lets me record hours upon hours of music). The back has 2x XLR mic inputs (phantom-powered if desired), 2x 1/4″ guitar/bass/mic inputs, a 1/4″ plug for a foot switch, a 1/8″ headphone jack and volume control. Side ports include the SDHC card slot, USB port, and a socket for an optional power adapter.

Tascam also has a four-track model that’s significantly cheaper (and is actually almost pocket-sized), but is missing the XLR inputs and balanced outputs of the 8-track version.

Here’s a sample track that I put together in under 30 minutes yesterday (this would have taken hours in Logic). It includes 2x ukulele tracks, 2x vocals, plus a rhythm track.

The prom queen

This individual (and it’s just as likely to be a “prom king” as the queen) is a true social butterfly. Online media—Facebook, FriendFeed, Twitter, MySpace—is just another one of many tools she uses to keep her social circle intact. While she may not have been her high school’s actual prom queen, she almost certainly still keeps in touch with her.

She’s a planner—she organizes gatherings, soccer games, poker games for her spouse, and feels involved whenever she has direct control over an activity. Whether it’s running the annual candy sale for her children’s junior high school orchestra, or putting together the annual reunion for her college graduating class, she’s an integral part.

She drives a minivan.

She is frustrated by limits imposed on her: why, for example, does Facebook limit her to 5,000 friends? She went to high school with 3,000 people, and to college with 12,000 more, and she knows at least half of them by name.

She has a blog and writes regularly on women’s issues.

She dropped out of the work force when she had her first child, but has since returned, now that her kids are in elementary school. Her job title will be “Event Planner” or maybe”Marketing Manager.”

She ran her first marathon the year after her youngest child turned 7.

If you’re building a social media experience for her, then get out of her way. She needs tools and she knows how to use them. Your job as a developer is to make sure that those tools always work, even in ways that you didn’t foresee. Give her ways to bring people together (“groups,” “events,” or “interests”) and ways to communicate with large numbers of people, and she’ll be happy. Whatever you do, don’t force her to work in a way that fits your expectations: that’s a sure way to drive her away. Expect creativity—if she finds a way to embed a Google Map into her comment, then embrace that and leverage it, don’t quash it. She is quite possibly the best way to see your social media site expand because of all the new members she keeps bringing in.

The marketer

He is only interested in social media as a way to expand his market. He talks about “reach” and “distribution” as if people were meat channels for the delivery of advertising. He dreams of viral videos about his product. Often, he’s a consultant and uses words like “leverage” and “synergy.”

On Facebook, he has 4,992 “friends” that he met at conferences. He considers them his “vital business connections.” He values his Porsche more highly than either his wife or his girlfriend. Both his wife and his girlfriend, in fact, are less “relationships” and more “strategic alliances” that he will discard once they’ve outlived their usefulness.

His Twitter page uses a full-screen image of himself, wearing sunglasses and standing next to his car, and a trite slogan like “improve your throughput.”

He sometimes thinks about his upbringing in the Roman Catholic church and thinks that they have a really well-connected graph.

He is great to go out with, since he will always pick up the tab, trying to impress you. On the other hand, you then have to listen to him.

Given a free reign on your socially-enabled website, he will kill whatever community that you have painstakingly built over the years, often with a few well-directed comments.

He sells Amway to his relatives on the weekends.

To be continued…

Approximately five years ago, one of the most devastating natural(?) disasters in US history occurred. Early on the morning of August 28, 2005, Hurricane Katrina plowed into the Mississippi river delta and up towards New Orleans.

The first reports seemed to indicate that the city had survived relatively unscathed. But an hour or so later, the world began to receive reports that the levees, long viewed as the weakest part of New Orlean’s hurricane defensive shield, had begun to fail, and the city was filling with water.

The story is fairly well known, but I had a small part in the midst of it. At the time, I was an engineer for Yahoo! News, and Katrina rapidly became the top story. We watched as our traffic doubled, then tripled, then quintupled our normal daily rate. And it stayed at that level, with little variance, for the next week or more.

My nephew was a flight mechanic and rescue winch operator for the US Coast Guard at the time; he took the top photo you see here on one of his (many) flights over New Orleans and the Mississippi coast. He had, in fact, transferred out of the New Orleans Coast Guard station several months before Katrina but was recalled (along with hundreds of fellow Coast Guard men and women) in the aftermath of the storm.

They flew inland, landed in the parking lot of a Home Depot store, and purchased every chainsaw available. They flew back to New Orleans, distributed the chainsaws among the Coast Guard rescue crews, who used them to speed their entry into the attics where residents had retreated from the encroaching floods.

One of the problems in the immediate aftermath was how to reunite the evacuees from New Orleans with their friends and relatives who were looking for them. Yahoo! put together a team of volunteers, including me, who flew to Houston to set up a computer center to help the evacuees search for and contact their relatives.

Yahoo! employees worked with a local computer networking charity and Verizon to set up a telecommunications center and a computer facility.

At the end of the first day, we reviewed the situation. One of the problems was that there were too many people trying to help. There were at least sixteen websites, many of them small, local sites, that carried lists of people trying to make contacts with their friends and relatives.

David Filo, one of the founders of Yahoo!, was on the call and realized that this was an area where Yahoo! could help. He had Yahoo! build a special search index that integrated data from all of the sites, and thus gave us a single site (by the next morning!) that linked out to all the necessary information.

The tragedy was great and is still ongoing, but it was an awe-inspiring site to watch a company like Yahoo! use its huge resources in such an open and rapid manner; this is one of the reasons why many of us are still here.