Recently in Worklife Category

I've been unemployed for most of July and will be for most of August.

During the last few weeks, job hunting has taken priority over blogging. The first opportunity I found out about, on July 11th, was the one that turned into an offer, on August 5th. I start at the new job on the 22nd.

At my previous job, I was a lone developer. Therefore, I took an approach to professional development that involved a lot of reading. Becoming self employed without an income, I took up reading as more or less a full time day job. I did update my resume and hit the job boards, but not as my primary activity. I wanted to pace myself and not set up too many contacts with possible employers at once.

I was surprised to find that a lot of the tech bubble infrastructure is still in place. There are headhunters who search for people they can pass on to employers for a fee. Some headhunters are conscientious, others spam with abandon. In one case, I got an urgent e-mail and voice mail from someone looking for a fluent Japanese speaker. The word "Japanese" did occur in my resume, but I never pretended to speak the language.

I was lucky. I didn't find the employer; a headhunter found me and figured out I was suitable for the position. I didn't answer every question perfectly in the interviews, but I got better as I progressed. This employer was more technically focussed than most; it paid off to read up on the details of Java, threads and RMI (among other things).

I have nearly two more weeks of leisure. I'll keep up with the reading, but I'll also have time to take care of chores and errands. If the earning member of the household could get time off, we'd probably go somewhere. But there's no need to go anywhere for warm, sunny weather. I'll try to enjoy the relaxed pace of summer while I still can.

In software, the type of risk that comes closest is the risk of using new, unproven technology. In an ideal world, that would be the only risk that mattered. In the real world, projects often fail for reasons that have nothing to do with technology per se. In the worst cases, an IT project seems to amplify whatever dysfunction exists in the host organization.

Portfolio management as a tool for risk mitigation should work for technology risk. However, it can't help with the risk that the normal risks that cause a project to fail:

• doesn't meet the deadline
• overruns its budget
• doesn't deliver what was expected
• delivers software to spec that turns out to be less useful than anticipated

Stephen Walli has put up the slides to a talk Once a talk given by Brian Behlendorf on OSS Development.

I would have liked to have been there. Behlendorf is deadly accurate about the problems of typical corporate development:

• Slow feedback loops from inception to use.
• High underlying technology churn.
• Poorly documented prior systems and requirements.
• The growing difficulty in estimating work.
• Demotivated developers.

(For that matter, more than a few unsuccessful open source projects have suffered from these problems too.)

Some of the lessons that Behlendorf takes from open source projects are bound to be more controversial. He recommends that a [p]roject should be digital from day one: start with specs, customer requests, any initial artifacts in a single, consistantly viewed space. What's more, discussions and decision-making should be moved online as much as possible.

I think this is all to increase transparency. However, I'm not sure if it's not making a virtue of necessity. Big open source projects have developers scattered across the globe — there is no feasible alternative to electronic communications. In an ideal world, they would be better off if they could talk face to face every day.

Nevertheless, I have to respect what Behlendorf has to say. After all, the everything-digital approach clearly works with Apache.

The implications of the article on cystic fibrosis (CF) treatment in November 23rd's New Yorker go well beyond medicine.

The progress in treating CF in the last forty years is surprising in itself. In the early 1960s, the average patient died by the age of three, but in 2003, life expectancy with CF had risen to thirty-three years nationally. Even more surprisingly, at the best center it was more than forty-seven..

In some sense it shouldn't be surprising that the results of treatment follow the famous bell curve. But 14 years between the best and the average!?! That's much greater than I expected.

What makes the situation especially puzzling is that our system for CF care is far more sophisticated than that for most diseases. The hundred and seventeen CF centers across the country are all ultra-specialized, undergo a rigorous certification process, and have lots of experience in caring for people with CF. They all follow the same detailed guidelines for CF treatment. They all participate in research trials to figure out new and better treatments.

The difference between the average and the best turns out to be relatively easy to understand. At the top institution (in Minneapolis), they go to extraordinary lengths to make the important measures. In CF, it turns out that lung capacity is one of those measures. At this institution, they aren't content if their patients' lung function is eighty per cent of normal, or even ninety per cent. They aim for a hundred per cent — or better

Why? Because, over the years, a small difference in lung capacity affects a patient's chances of surviving noticeably. Lung capacity is just one measure, but it's important.

In addition to a focus on the measures, there's a drive to the doctors that leads them to try out new approaches and think up new ideas. What the best may have, above all, is a capacity to learn and adapt — and to do so faster than everyone else.

What gives me pause for thought that if these things are true for a field as complicated as medicine, they're probably also true for software development.

One could expect to see large differences between software teams and that those differences can be seen in the results. (Anecdotally, we all know this is true.)

Part of excellence comes through specialization. There are more than a hundred centres for cystic fibrosis in the United States. They are all much, much better than any non-specialists could hope to be. (However, they are still within their own bell curve.)

One would expect the best teams to be know the important measures and be driven to improve them. (In the CMM model, this is something that is postponed to maturity level five. )

The best would frequently experiment and try new approaches, even crazy ideas, all in the interests of doing better.

Now, IT isn't medicine, so few people are going to live longer lives as a result of any software. However, most IT shops I know of emphatically are not like the top CF clinics. In a highly competitive world, I wonder if one would ever want to work in a centre that does not strive to be the best.

I generally agree with what this review of the NFJS conference based on my experience in 2003. The speakers are good and the material is solid.

In 2004, I didn't see enough new material to make it seem worthwhile to go again. For example, I attended talks on Naked Objects and Mock Objects last year.

There are some other considerations.

• My backlog of books I have bought but not yet read is getting too big.
• This time I would have to travel further, from the city and not a nearby suburb. Invidious choice between staying at a hotel or dealing with rush-hour traffic.
• Need to save money for the honeymoon in November :-)

We'll see, maybe I'll make it next year. Of course, NFJS is much cheaper than going to one of the mega-conferences on the coasts and probably better value because of the smaller number of attendees.

Canada's National Post has an article that won't surprise anyone who has worked on large projects. "people " challenges are often more difficult than technical ones.

It's just surprising that such basic mistakes are still being made.

• inadequate support from executives
• poor understanding of how the project fits in the business
• large requirements document up front that the developers are expected to interpret without further communication
• inadequate training
• no attempt to sell (never mind tailor) the system to the people who will use it

Those are basic, basic mistakes. I don't think you even need experience to understand why they are mistakes. The conclusion of the article is on target: avoiding people problems is a core job of management.

It becomes a major role of (management) to kind of herd the cats in and make them all line up in a reasonable way, said Barry Wilderman, an analyst at the Meta Group. That's why this stuff is so hard.

Uhm, yeah. Understanding people and organizations can be hard and getting them to work together smoothly is even harder.

However, I don't believe developers can afford to isolate themselves in a technical cocoon so one claim doesn't cut it with me. Developers are least qualified to validate a business requirement. They're either nerds and don't get it, or they're people in another culture altogether. Listen, no outsider gets it. I'm not saying that every developer needs to be schmoozing with users but every developer needs be aware. The relationship between the developers and the people who will use the software matters. If there are problems in that relationship, that's a huge risk that developers need to address.

Brian Marick writes about how projects need to adapt to their environment:

I wasn't at all clear in my description of teams succeeding in their own terms. By that, I meant to suggest that the team is delivering what some representative of the business said was business value, but that either the representative was wrong or someone with more power wasn't interested in that business value. So the project gets canned because it wasn't adapted to its real environment, only to an economic fairy tale: the corporation run by profit-maximizing economic actors.

In the XP the whole problem of navigating corporate and ensuring the project is delegated to the onsite customer. Books on project management do usually tend to go by the fairy tale.

It's good to have a reminder: people's motivations are rarely simple. Organizations are often not rational in the economic sense. Having access to a customer is no substitute for understanding the overall background to the project and the organizational politics involved. The project can fail despite meeting its technical goals. That's a given. It's less obvious that the project can fail even if it is meeting its nominal business goals as defined by the official customer.

That last failure mode indicates far deeper problems than could be covered in any book on technical projects. Every unhappy organization is unhappy in its own way. It's easy for a software development team to put its head down and concentrate on narrow project goals. It's also dangerous.

Bill de hÓra has written a remarkable essay on why the industry tends to rely so much on mediocre programming languages and why he sees a change coming.

The essay makes me think of a slogan I've been thinking of lately. It's the productivity, stupid! Corny as that may sound, it's important for two reasons.

1. It's possible to be more productive the mainstream because the mainstream is slow to acquire knowledge that is readily available, both technical and organizational.
2. I think both companies and individuals who fail to grasp the opportunities will be in jeopardy.

Found via Mark Pilgrim's b-links, How to be a Programmer. Like Mark, I am struck at how good this is, but I can think of a different way to use it.

It's been a while since I've interviewed people looking for jobs. I may be in the happy position to do so again soon. Most of it is down to intangibles: do they know what they're talking about or are they bluffing. I always want to draw them out, which means I need to ask lots of open questions. (A "closed" question can be answered very quickly, in the worst case with a simple "yes" or " no".)

This document is a trove of open questions. Where it has a section headed How to ..., it's easy to substitute, ,"can you tell me about a time when you did ....&quot or "what is your approach to..."

The way the document is organized, it's also easy to choose. The sections are helpfully categorized into Introduction, Intermediate and Advanced, with sub-sections on things like Team Skills and Judgment.

The actual answers don't matter so much. The ones in this document are good, but I would expect any candidate to speak from their own personal experience and with their own personality.

Of course, I don't always expect to be sitting on the same side of the table. One day, I'll be the one looking to be employed. Many of the same questions are good for applicants as well. (What is your team's approach to version control? How would your company/organization/department generally make a build or buy decision?)

I'm writing about this at least partly so that I can find it again when I want it. A weblog is more permanent than a bookmark.