The next time a recruiter tries to entice me to the next hot startup (granted, that doesn't happen very often these days), I think I'll point them to this article when I decline: The "Crisis" in Venture Capital.

I've started a new blog that focuses on my professional interests as a software quality assurance engineer. Check it out: Agile Testing.

I received the following business contact (nice way to say spam from a legit company) to my small business email address this week:

Dear Stan:

It’s a pleasure getting connected with you. I am Pulakesh and am writing from Adea. Adea (www.adea.com) is a Texas based global IT Solutions & Services Company that leverages technology to create sustainable business value for clients and help them in their quest for improving business performance through a Global Engagement Model (GEM). Adea relies on its proprietary Global Engagement Model™ (GEM) to deliver projects on time and within defined budgets. The GEM is a process driven framework that leverages the synergies of ProVeda™ - the Process Framework, OptiShore™ - our Delivery Model and the ProSource™ Business Model. All engagements at Adea, regardless of location or model, leverage GEM with more than 1,000 software professionals working in US, UK, India and China.

Man, I have no real idea what Adea does, and no real desire to find out.

This is a video that some coworkers and I created for a company short video contest (I'm 'Waterfall', if you don't know me)

This blog entry, How to Improve your Skills at Office Politics, contains some very good advice for being successful at work, though I take issues with the author's choice of the term 'office politics.' To me, that term has very negative connotations.

I've been thinking about these tips in regard to working in software quality assurance. One of the toughest office dynamics is between experienced, alpha geek developers and more junior and/or less technically skilled quality assurance engineers. As a QA lead, I spend a lot of my time helping both sides to bridge this gap.

One of the best skills a junior QA engineer can develop is knowing when and how to ask for help: before you ask a developer for help, make sure you've tried everything possible to figure it out or find out for yourself, and when you do ask for help, explain what steps you've taken. This explanation helps the developer to understand what you do and don't know, but more importantly, it shows him that you're taking initiative and not wasting his time by running to him first (I'm consciously using the male pronoun here, since such alpha developers are usually male).

I had one QA engineer who was having a particularly tough time gaining credibility with a senior developer on her team. Despite employing the tactics above, the developer was still giving the QA engineer the impression that she was annoying him. So I designated myself her safe go-to person. After trying everything she could think of, she would come to me without worrying about her credibility.

If I could help her, then she didn't have to go the developer. If I couldn't help her, then she didn't have to go to the developer. If I couldn't help, then I reinforced to the developer that she had taken a lot of initiative, and helped him to understand what she did and did know.

A couple of new blog posts (1, 2) by Anil Dash have sparked a lot of discussion (see here and here, for instance) about the value of diversity--specifically in this case, gender diversity--in high tech.

This is a timely topic for me. At work, I've recently joined a newly-formed development team. As we were sitting in team meetings this week, I realized that there is only one woman on this team (and she is the product owner, which, in our development methodology, makes her kind of an adjunct team member).

Our other two teams at work have at least two women members (all QA and technical writers; we don't have any female programmers), and I've been very pleased with the team dynamics of both those teams.

For several reasons, I'm currently slightly uncomfortable with the dynamics of the new team, and it struck me this week that one of those reasons is that it felt kind of 'good-ol-boy'ish. After reading Anil's posts and some discussion of them, I emailed the team lead to discuss the issue of gender diversity on the new team. We'll see what happens.

I've heard repeatedly that there is an order of magnitude difference between the most and least productive programmers. I have no doubt that's the case, but recently I've experienced that difference first hand, and I've also come to appreciate the effect of experience on that difference.

We hired a new QA engineer a couple of months ago, and I've been working with her closely the past few weeks. She's very smart and seems to have high technical aptitude, but she doesn't have much experience with the type of tasks we've been working on--dealing with various DBMSes. I've worked repeatedly with three of the four DBMSes and know quite a bit about the subtle differences between them. Furthermore, I've worked with DBMSes enough to know how to figure out how to do different tasks in each one. This experienced also helped me to get up and running with the one (DB2) that I'm not experienced with.

In this situation, I was an order of magnitude more productive due to my experience.

Guy Kawasaki offers twelve skills "students should learn in order to prepare for the real world after graduation." They are:

1. How to talk to your boss
2. How to survive a meeting that’s poorly run
3. How to run a meeting
4. How to figure out anything on your own
5. How to negotiate
6. How to have a conversation
7. How to explain something in thirty seconds
8. How to write a one-page report
9. How to write a five-sentence email
10. How to get along with co-workers
11. How to use PowerPoint
12. How to leave a voicemail

(Go read the entire blog post for Guy's comments on each item)

I don't think that these skills should be explicitly taught in college, but I agree that they are valuable career skills.

For the record, I hate it when people refer to 'the real world' vs. college. It tells a lot about the speaker though.

As the video below demonstrates, getting computers to work with human language is hard--even after decades of research and development.

The scene: Sitting with several coworkers in the conference room waiting for someone in another location to join a conference call. Everyone is awkwardly quiet.

Coworker 1: So, how about those Mavericks? Wasn't that an awesome game last night between them and [some other sports team]?

Other coworkers and me: <blink>

Silence.

For my new job, I've been re-reading Agile Project Management with Scrum by Ken Schwaber. In the Introduction, the author says that common sense is a critical element of the processes that he outlines.

I'm usually wary of appeals to common sense, as they are often used in conjunction with various logical fallacies. In this case, however, I really like Schwaber's definition of common sense. He says that it "is a combination of experience, training, humility, wit and intelligence." It really surprised me to see humility and wit in his definition, and it was a good sign that I would like the author's point of view more generally.

Three weeks ago, I started a new job: QA engineer with Borland Software. I couldn't be happier. The group that I'm working with is implementing a full-blown agile/scrum process. When I was interviewing with Borland, I told my interviewers that I'd used some agile methodologies in previous jobs. But now that I've been participating in a real agile methodology, I realize that there's a fundamental difference between adopting some of the methodologies and adopting the philosophy of agile/scrum: it's all about respect, truthfulness, collaboration, visibility, continual feedback, putting individual egos aside for the greater good, etc.

I filled out a form on a web site this morning, and I noticed the date below:

It's an awfully long time past the year 2000 for something like that to still be showing up.

You know, I fully embrace the principle of doing HTML layout via CSS vs. the old fashion table layouts, but the browser implementations of CSS still differ so much that it's been a huge pain every time I've tried to implement more than rudimentary CSS layouts. As you have surely noticed if you visit here regularly, I recently converted this blog to one the newer MovableType templates, and then have been tweaking it to my liking. But the stylesheet for this template is over 1000 lines long, and every time I've tweaked it, I've encountered different behavior in Mozilla and Internet Explorer. Frustrating.

So, my coworker from Professional Services walks over to my desk with his laptop and our company's application running (names changed to protect data integrity).

Coworker, pointing to laptop screen: "Where did all this [blah blah] data come from?"

I answer: I entered it into our application from that spreadsheet you sent me about [blah blah] data configuration.

Coworker: What spreadsheet?

Me, typing furiously, then pointing to my laptop screen: the spreadsheet attached to the intranet wiki page about [blah blah] data configuration.

Coworker: Where did that spreadsheet come from? I didn't send you that.

Me, typing spreadsheet filename into Google Desktop Search, results showing an email from Coworker with said spreadsheet attached: Ah, but indeed you did.

Coworker: I'll be darned.

Score one for Google Desktop Search.

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.

I already knew a bunch of people at my new job: the company was founded by some guys I worked with several years ago. Plus, they just hired as development manager the guy I worked for at two jobs since then. And, they also just hired someone I worked with at yet another job. Someone commented yesterday that I'm the Kevin Bacon of the Austin software development universe. I'm not sure what to make of that.

A New York Times article discusses some designers' call to simplify technology. These people claim:

There is too much needless complexity in the world, he argues. Technology, which was supposed to make our lives easier, has taken a wrong turn. In 20 years we've gone from the simplicity of MacPaint to Photoshop. While the first fostered a creative explosion, the second gave birth to an industry of how-to books and classes. And such complexity is commonplace, Dr. Maeda says. Despite the lip service paid to "ease of use," "plug and play," and "one-click shopping," simplicity is an endangered quality in the digital world, he adds, and it is time to break free from technology's intimidating complexity.

And of course they mention Microsoft Windows. I see their point, but they offer a tired argument. Can you do all the things with MacPaint that you can do with Photoshop? Of course not. PhotoShop (or Word, Windows, etc.) may have a zillion features, but these are programs with lots of users with very different needs. Sure, any individual user may only use a small subset of a program's features, but there's a group that needs every feature that's been included. Contrary to what these folks imply, we aren't just making things more complex for its own sake.