In Wired Magazine, Simson Garfinkel lists History’s Worst Software Bugs. I’d already heard about many of these, but not all. This one is particularly intriguing:

1982 — Soviet gas pipeline. Operatives working for the Central Intelligence Agency allegedly plant a bug in a Canadian computer system purchased to control the trans-Siberian gas pipeline. The Soviets had obtained the system as part of a wide-ranging effort to covertly purchase or steal sensitive U.S. technology. The CIA reportedly found out about the program and decided to make it backfire with equipment that would pass Soviet inspection and then fail once in operation. The resulting event is reportedly the largest non-nuclear explosion in the planet’s history.

Colleagues have noted lately that the software job market seems to be picking up. I’ve certainly seen an increase in the number of cold calls from recruiters, which would tend to support this observation. The next question is: are we entering another software boom?
Over at VentureBlog, investor David Hornik addresses another aspect of this issue:

Over the last couple of months I’ve noticed an increasing sense of unease in the venture community about the trend in Web 2.0 company creation and financing events. While no one is officially willing to peg it Bubble 2.0 for fear of missing the next great opportunity, I’ve been having lots of conversations with venture investors about this nagging feeling that we’ve been here before. . . So why am I now getting this increasingly uneasy feeling? I was chatting with a veteran of Bubble 1.0 recently and I think he hit on the thing that makes those of us who’ve seen this movie before most nervous. He pointed out that there are a large number of “companies” being created again for the express purpose of being acquired. I certainly have seen it.
. . .
If companies are indeed again being built for acquisition rather than independence, venture investors are in for a rude re-awakening (that will be precipitated by a very loud popping sound). While a few companies being built for acquisition will be acquired, the vast majority will ultimately run out of money and be shut down (particularly as each new Web 2.0 idea doesn’t just spawn one company but three or four). So when I hear large numbers of companies pitching themselves as excellent acquisition candidates before they’ve even gotten out of the gate I can’t help but think to myself that we are in the heart of Bubble 2.0. Sadly, only one thing follows Bubble 2.0 and that is Bust 2.0.

A new software bubble might be good for my job and compensation prospects in the short term, but I’d take a steady, healthy industry any day over another crazy boom and bust cycle.

I receive a weekly email containing links to tech business news articles from Bizjournals.com. This morning’s email contained a link to a story that I find just shocking.
The article’s thesis: as software becomes more complex, it contains more defects and is more difficult to test:

Despite ever-more sophisticated tools and procedures for spotting software problems before they imperil systems, more bugs than ever are fouling up computers. The Standish Group, a Yarmouth research firm, estimated software deficiencies cost the U.S. economy $59 billion in 2003 and says the total has been rising since.
Systems fail more often today due to the demand for “intelligent” programs that execute complicated tasks instantaneously. But new theories on software development are becoming mainstream, ending what some believe is a vicious cycle of escalating system failures — and perhaps create a virtuous cycle for vendors who can anticipate bugs before they are ever born, rather than rooting them out after the fact.

And if that thesis alone isn’t enough to rock your world, the reporter dug deep to find new and relevant examples of such problems: the Y2K bug and the 2003 Northeast blackout.
Boy, this article took some first-class reporting.

I currently manage an outsourced team of three QA engineers in Costa Rica, and at a former job we had team members in Bangalore, India. Due to this experience, people often ask me my opinions about outsourcing. Here are some of my thoughts that I usually share:
First, I like to point out that American jobs have been moving overseas for a long time now, decades at least. For the longest time, though, those were all manufacturing jobs. In my opinion, the current concerns about outsourcing are simply due to the fact that it’s moved up the socio-economic ladder to white collar jobs (such as software engineering) and people in those industries are feeling threatened. It’s not a new phenomenon.
As a liberal and someone who has traveled and lived abroad, my opinion is that the moving of jobs, especially higher level ones, from the U.S. to lesser-developed nations is a good thing: it will serve to level out the standard of living world-wide to some degree.
However, as someone who has been personally affected by outsourcing, I see that not only will it raise the standard of living of other countries, it will also lower the standard of living of Americans somewhat. And I don’t like having my job threatened any more than anyone else.
So, how do I reconcile these two views? Well, first of all, I view outsourcing as inevitable; there’s nothing that we Americans can do to stop it, short of major social restructuring. Therefore, I’d be foolish not to try to accommodate myself to the situation. In my case, that has meant getting experience managing outsourced teams.
In addition, I stick by my liberal principles. Outsourcing will be tough on Americans–even, possibly, me and my family–but in general, lesser disparities in standard of living are a good thing for everyone.

This has been making the blog rounds the last few days. Joe Kraus has three interview questions can be used to tell whether an engineer might be a good fit for a start-up software company:

1. Do you have a blog?
2. What’s your home page?
3. Do you contribute to an open source project?

When I read his post, I immediately thought of a coworker with whom I’ve worked at two start-up software companies. This guy is brilliant, articulate, hard-working and one of the most productive programmers I’ve ever seen. He’s been a huge asset to both start-up companies. But when this guy leaves the office, that’s the end of his technical life for the day. As far as I know, he doesn’t look at a computer outside of work.
So, this co-worker passes the spirit of Joe’s questions with flying colors, but would fail the actual questions miserably. I see what Joe is getting at with these questions, but the questions themselves are an absurd reduction.

I was searching the Texas sex offender database (out of morbid curiosity) when I ran across this ‘offender’:

(Click on image for larger version)

Joey deVilla has a good blog post about crunch mode, which he defines as “working extra hours each day for extended periods in order to meet a (usually arbitrary and unrealistic) deadline.”
I agree completely with Joey that extended crunch mode is counter-productive. As work hours increase, productivity decreases, and at some point, you’re making so many errors that it becomes counter-productive.
The issue of work hours almost always comes up in some form when I interview for jobs. My stock answer is: software development is a cyclical enterprise. I understand that there are periods when much greater effort is necessary, and I’m willing to put in that periodic work.
And as a manager myself, I tell my team members that if they have to be in crunch mode more than periodically, then it’s a management failure.
I usually welcome this topic in a job interview, because the interviewer’s attitude toward crunch mode tells me a lot about the culture of the company and whether I want to work there. Thankfully, I’ve had the opportunity to work in several companies where management essentially agrees with me about the dubious value of perpetual crunch mode.

In the same vein as yesterday’s post about test data in production applications, today I present production web sites that have the text ‘This is placeholder text‘.
(Via Jim Heid)

If you go to the Nike Women Store Locator and select Afghanistan from the list, you’ll see that there’s a store named ‘blabla’ in a city called ‘test’ (found on This is Broken).
Oops. Somehow, the developer of this little application managed to get test data into the production application.

Well, it could have been worse: at least the city wasn’t named ‘f*ck’ and the store, ‘sh*t’ (asterisks for the sake of web filters, not because I’m a prude). As a software QA engineer, I used to use profanities in my test data. My vulgar data never made it into production, but my test system got used often enough for demos to management or, heaven forbid, customers that I finally learned my lesson.

Paul Graham, whose “Great Hackers” essay was making the rounds recently, has written another great essay, this one about the positive lessons we should take from the great internet bubble of the late 90s. I particularly liked his sixth section, titled “Nerds” (I prefer the term “geek”):

Clothing is only the most visible battleground in the war against formality. Nerds tend to eschew formality of any sort. They’re not impressed by one’s job title, for example, or any of the other appurtenances of authority.

Indeed, that’s practically the definition of a nerd. I found myself talking recently to someone from Hollywood who was planning a show about nerds. I thought it would be useful if I explained what a nerd was. What I came up with was: someone who doesn’t expend any effort on marketing himself.

A nerd, in other words, is someone who concentrates on substance.