Whimsley

Don't be Pompous

Let's get this straight - I don't have anything  against Google any more than I do any other company. But there are times when it just goes out of its way to be a pretentious prat. Today is such a day.

Here is Google's unbelievable official response to the Microsoft attempt to buy Yahoo!  How about this for a paragraph:

Could Microsoft now attempt to exert the same sort of inappropriate and illegal influence over the Internet that it did with the PC? While the Internet rewards competitive innovation, Microsoft has frequently sought to establish proprietary monopolies -- and then leverage its dominance into new, adjacent markets.

David Drummond (Senior Vice President, Corporate Development and Chief Legal Officer) talks about two principles of the Internet: openness and innovation.

We take Internet openness, choice and innovation seriously. They are the core of our culture.

The beauty of this stance is that you can play the openness and innovation off against each other. Google's important software is just as proprietary, closed source, and hidden as that of Microsoft - in fact more so because M$ has shared source agreements with many companies while Google's core technologies are not shared with anyone. Google does not disclose information about things like water consumption at its server stations because it's a "competitive matter"; Google buys properties under other names because it can get a better deal. In cases like these where Google wants to be secretive they pull the innovation card and talk about innovation and the need to  prosper in a competitive market.

When Google wants to promote technologies that are complementary to its own, it makes them open source (for example, in its sponsorship of Firefox browser development) and talks in idealistic terms about "the community". The overlap of interests between Google and its "communities" is partial at best, however, and such talk is cheeky, to say the least, coming from some of the world's richest people. And if making its advertising-driven wealth isn't leveraging its dominance in search into new, adjacent markets then I don't know what is.

In the end, Google and Microsoft are both profit-maximizing companies. No matter how much they couch their goals in suitably vague idealistic terms ("don't be evil" and the "freedom to innovate" respectively) they respond to the incentives faced by all such institutions. I just wish they'd be up front about it and not put out the kind of drivel that Google did today.

The Netflix Prize: 300 Days Later

Today the Netflix Prize Competition has been running for 300 days.

Online DVD rental outfit Netflix caused a real buzz last October when it announced the competition. If anyone can come up with a recommender system for predicting customer DVD preferences that beats its own algorithm (Cinematch) by a certain amount, Netflix will hand over $1million. The prize got a lot of attention because it exemplifies the idea of crowdsourcing. Not only does Netflix rely on crowdsourcing of DVD ratings (user ratings of DVD titles) but the competition itself is an attempt to use crowdsourcing to develop the algorithms to make the most of those ratings. Instead of doing the work itself, or hiring specialists, Netflix lets whoever anyone enter their competition and pays the winner. The competition is still in progress: Netflix says it will run until at least 2011. So now the initial buzz has died down, what can we learn from the Netflix Prize?

First, the competition details (see here (PDF) for a short paper by two Netflix employees). Netflix made public a database of customer DVD ratings (tweaked to ensure privacy) that included over 100 million individual ratings of 17,770 titles by 480,189 people. If you sign up for the prize, you can download these ratings. Each rating involves one customer giving an integer number from one star (very bad) to five stars (very good) for a given title. For example, customer 296452 gave title 234 ("Animation Legend: Winsor McCay") a rating of 1 (very bad).

The idea is that competition entrants try to develop an algorithm by using the training set (which is the 100 million plus set of ratings), try it out on a set of probe set of test data that they also give you, and once they think they have a good algorithm, create a set of predictions for a qualifying set of users and titles, and upload it to Netflix. Netflix test these predictions against the actual rankings (which they keep private) for that qualifying set. They post the leading algorithms on a leaderboard.

The quality of any algorithm is determined by its root mean squared error (RMSE). To calculate the RMSE you take the difference between the rating the algorithm predicts and the actual rating, and square it so it's guaranteed to be a positive number. Then you take the average of all these over the set of data to get the mean squared error. Finally, taking the square root gives the RMSE, which is the roughly the size of a typical error.

A perfect algorithm would predict exactly what rating every user would give to every title and would have an RMSE of zero. A random set of predictions has an RMSE of 1.95. But the actual range of action is much narrower than this 1.95 range. A simple algorithm that uses the average rating for each title as the prediction - "let's see, the average rating for the 104,000 customers who rated Mean Girls was 3.514, so I predict you will give it a rating of 3.514" - gets an RMSE of 1.0540. Netflx's Cinematch algorithm has an RMSE of 0.9525. Netflix set the prize target at a 10% improvement over that, which is an RMSE 0.8563. So the range that recommendation systems can realistically cover - from naively simple to cutting-edge research - seems to be the narrow band between the middle three lines in the following diagram.

In the days and weeks after the prize was announced, progress was rapid. The Cinematch score was matched within a week. Within a month the leaders were half way to the winning prize with a 5% improvement. But getting further improvement progress has proved more and more difficult. It took another month to get to a 6% improvement, about 5 more months to get to 7%, and the current (July 29 2007) leader is at 7.8% improvement and has been unchanged for a month. Here is a graph of the progress, showing the three lines above and the prize leader progress:

At this stage it is not clear if the prize is winnable: the existing algorithms use a lot of linear algebra and some pretty fancy machine learning ideas (see a description by a leading participant here and some sample code for a similar approach here), the leading groups include university research labs from around the world, and many of the more obvious approaches have been explored. Certainly media and blog interest - huge in the early days - has dropped off in recent months. This New York Times article is one of the few from the last month or two.

Let's not get into the computer science of recommender systems - there's a good review from 2004 called Evaluating Collaborative Filtering Recommender Systems here if you want to know more. Instead, let's step back a bit and ask what this prize tells us so far, and look at a couple of things we can learn by poking around the massive data set that Netflix provided.

One question is: how good is an algorithm with an RMSE of 1, and is an algorithm with an RMSE of 0.8563 much better for the average customer? Actually, I guess that's two questions. Anyway, if the errors followed a normal distribution (which they don't, but we're talking back-of-envelope here) then if a customer actually rated a title as 2 (poor), an algorithm with an RMSE of 1.0 would predict somewhere between 1 and 3 about 70% of the time. Not bad, but not startling. If the algorithm gave ten recommended movies, then it would get on average seven out of ten within one unit of the customer's actual rating. Meanwhile, the RMSE=0.8563 algorithm would get 7.6 out of ten. While this is an improvement, and while it may be a remarkable technical accomplishment, it does not seem to be exactly a revolutionary leap compared to the really simple algorithms as far as customers go.

[Update, December 25, 2007: Yehuda Koren of leading team KorBell approaches the recommendation problem a different way, looking at ordering of recommendations rather than at matching them. His way is more appropriate, and gives much more encouraging results. See here.]

As soon as you start looking at the data set it becomes obvious why it is so difficult to get good results. Databases don't have the linear algebra and other mathematical tools for taking a run at the prize but they are convenient for exploring data sets, so I loaded the data into a SQL Anywhere  database (The developer edition is a free download, and I'll provide a perl script to load the data if you really want it) and started poking around. Here are a few of the more obvious oddities (all these observations have been posted elsewhere - see the Netflix prize forum for more):

• Customer 2170930 has rated 1963 titles and given each and every one a rating of one (very bad). You would think they would have cancelled their subscription by now.
• Five customers have rated over 10,000 of the 17,770 titles selected - and presumably they also have rated some of the others among the 60,000 or so titles Netflix had available when they released the ratings. Are these real people?
• Customer 305344 had rated 17654 titles. Even though Netflix make it easy to rate titles that you have not rented from them (so they can get a handle on your preferences) can this be real?
• Customer 1664010 rated 5446 titles in a single day (October 12, 2005).
• Customer 2270619 has rated 1975 titles. 1931 were given a 5, 31 were given a 4, 10 given a 3, 2 given a 2 (Grumpy Old Men and Sex In Chains) and a single title was given a 1. That title? Gandhi, which has an average rating of over 4 and which less than 2% of those who watch it give a 1.
• The most often rated movie? Miss Congeniality with ratings by over 232,000 of the 480,000 customers. And which title is most similar to it in terms of ratings (using a slightly weighted Pearson formula)? Bloodfist 5: Human Target.
• Most highly rated - Lord of the Rings: Return of the King (Extended Edition), with 4.7.

Some of the more bizarre facts above may be artifacts of whatever tweaking process Netflix put the data set through (although they claim not to have materially affected the statistics). While odd, bizarre users are not always difficult to deal with: if you have rated each of the last 1963 titles you've watched as 1 it is pretty easy to predict what you will rate the next title. But others are more tricky.

One reason for these oddities is one of the things that Evaluating Collaborative Filtering Recommender Systems identifies. They note that (on other, smaller data sets) even the best algorithms don't seem to get beyond an RMSE of 0.73 on a five-point scale, and speculate that the cause may be "natural variability". We users provide inconsistent ratings - sometimes we'd rate a movie a 3 and sometimes a 4, with no consistency. It may depend on our mood when we watched the movie - we may give a romantic movie a higher rating if we watched it on a first date than if we watched it a week later after being left broken hearted, or a demanding movie a low rating because we were tired and out of sorts when we watched it - or it may depend on our mood when we actually provide the rating.

There are other, more obvious reasons which, for reasons I don't understand, don't seem to get discussed much. Netflix itself and most competitors talk about the data in terms of "movies" and "users". But the "movies" in the list are not all movies: a lot are TV series or music video collections. The variability among the episodes of a series (Do you think Lost Season 1 deserves a 3 or a 4?) must make single-number ranking even more variable and these composite DVDs figure prominently among those titles that have the biggest variance in ratings.

Then there's the fact that a customer might not really be a single person. It might be a household with several viewers in it. So perhaps one person likes Terminator, one likes Bridget Jones, and one likes Spongebob Squarepants. Once we realize that the "user" might be a collection of people there is no strangeness between giving high ratings to each of these, but you can see how, depending on which household member entered the rating, the values may be quite different (perhaps this is why titles like 'N Sync: Making of the Tour, Pokemon Vol 9, and Boston Red Sox 2004 World Series Collectors' Edition have high variance - the person rating may not always have been the person who wanted to watch it). If the data set contains these inevitable variations (in addition to the plain kookiness on show in the Netflix set) then it may be that even the clevverest algorithm can make little progress in untangling all the intrinsic vagueness of the data.

So what I get from the Netflix prize is that there are probably significant limits to recommender systems. Even the smartest don't do a whole lot better than the simple approaches, and a lot of work is required to eke out even a little more actual information from the morass of data. It seems surprisingly difficult to get reliable, factual information on this important question of how useful they can be. Part of the reason is that they are new - Amazon has only been in business for about ten years after all - and part of the reason is that the behaviour of these systems is often a closely guarded secret despite the aura of openness that web companies cultivate.

This matters because there is a surprising amount riding on the effectiveness of recommender systems. Silicon Valley's new-economy enthusiasts see them as the key to developing a new level of cultural democracy: they see recommender systems as a trebuchet hurling rocks at the castles of the old elite of mainstream media, big publishers with big marketing departments, big-chain book stores and Hollywood sequels. Recommender systems are claimed to embody the "wisdom of crowds". The idea is that everyone just publishes stuff (blogs, wikipedia entries and so on) and amateur readers or viewers decide what has merit by their actions (rating stories, buying and rating books and DVDs and so on). The work of critics is "crowdsourced" to customers, but it is the recommender system that distills these ratings to yield the aforementioned wisdom.

If faith in recommender systems is misplaced, then the new boss may look much like the old boss only with more computer hardware. There is a danger that recommender systems may simply magnify the popularity of whatever is currently hot - that they may just amplify the voice of marketing machines rather than reveal previously-hidden gems. Even worse, their presence may drive out other sources of cultural diversity (small bookstores, independent music labels, libraries) concentrating the rewards of cultural production in fewer hands than ever and leading us to a more homogeneous, winner-take-all culture.

I'm no futurist, but I see little evidence from the first 300 days of the Netflix Prize that recommender systems are the magic ingredient that will reveal the wisdom of crowds.

Reputations

Regarding reputation-building on the Internet, Clive Thompson writes approvingly that

network algorithms do not favor the cagey or secretive. They favor the prolific, the outgoing, the shameless.

Said another way, network algorithms do not favour the quiet or the reflective. They favour the loud-mouthed, the self-promoting, the flashy.

O brave new world that has such algorithms in it.

Believe the Opposite: Radical Opacity

I'm afraid Clive Thompson has jumped the shark. From being a witty journalist at the interesting This Magazine he now fits right in at the boring Wired Magazine. On the way he seems to have lost his sense of irony (maybe they don't let you bring irony into Silicon Valley?) and his cynicism. As a result, he has also lost the plot. Come back Mr. Thompson!

His March 2007 article in Wired Magazine called The See-Through CEO coined the phrase Radical Transparency. Like other Silicon Valley catch phrases, it has that air of youthful rebellion, it is self-consciously ignorant of history (who needs history when all the interesting things are happening right now), and - most important of all - it imparts a feel-good sense of anti-corporate attitude to your next venture funding proposal or business plan. Because like other Silicon Valley catch phrases, Radical Transparency has about as much to do with rebellion as riding a mountain bike.

Here are some snatches from the article, and some recent events in the real world, mainly as reported by The Register - which has thankfully managed to keep its senses of both irony and cynicism - and mainly about Web 2.0 poster-offspring Google and its growing Google-hoard of companies.

"You can't hide anything anymore," Don Tapscott says. Coauthor of The Naked Corporation, a book about corporate transparency, and Wikinomics, Tapscott is explaining a core truth of the see-through age: If you engage in corporate flimflam, people will find out.

Meanwhile, Google plays cat and mouse with regulators. Leif Aanensen, deputy director general of the Norwegian Office of the Data Inspectorate, has been investigating Google's data retention policy:

   "We are not satisfied," he said. "We didn't get the proper answers."

   "Our main issue was their data retention policy and the use of the data they   stored. We asked them what they were doing with the personal data - are you   creating profiles - they didn't answer," he said.

Thompson writes: "You can't go halfway naked. It's all or nothing. Executives who promise they'll be open have to stay open."

Meanwhile, Google - who make repeated references to their own "radical transparency" - are closed-mouth about the introduction of new programs.
Paying select few video producers for example:

YouTube says anyone who wants to get paid can let it know by registering an interest, but provided no timescale for when it will cough up, or what the carve-up will be.

Or will there be   advertising   on the iGoogle front pages?

   The company has not made any noises about placing personalised ads on the new   iGoogle personalised homepage, but industry observers are fairly confident it   is only a matter of time.

When it comes to openness, Thompson writes "there's no use trying to resist. You're already naked." How Naked? Hard to tell, because it is not easy to find out what   information   Google keeps about you.

   "Upon arriving at the Google homepage, a Google user is not informed of   Google's data collection practices until he or she clicks through four links,"   says the section of the complaint which details Google's alleged deceptive   trade practices. "Most users will not reach this page. In truth and in fact,   Google collects user search terms in connection with his or her IP address   without adequate notice to the user. Therefore, Google's representations   concerning its data retention practices were, and are, deceptive practices.

   "As a result of Google's failure to detail its data retention policies until   four levels down within its website, its users are unaware that their   activities are being monitored," says the complaint in the section alleging   unfair trade practices.

Thompson writes:

Secrecy is dying. It's probably already dead.

Meanwhile, here's Google being radically opaque:

ord broke this month that Google has purchased 800 acres of land in Pryor, Oklahoma. The company has yet to confirm plans for the site, but I'm betting  on a new data center rather than an amusement park (in all fairness, you can   never tell with this bunch – Ed).

Oklahoma proves a handy spot to have a data center since the state's Governor signed a new law that affords the largest corporate energy users the right to keep their power consumption figures a secret.

Governor Brad Henry signed the energy law (House Bill 1038) just a couple of   days after news of Google's land purchase reached the local newspapers.  Coincidence? Sure.

The lawmakers behind the bill denied having chats with Google around any legislation. People familiar with the matter, however, did note that the law proves convenient for an entity such as Google that likes to keep as much information secret as possible.

If you're a demanding type who needs evidence of Google's secret ways, have a  listen to head of strategic development Rhett Weiss. He presided over a party celebrating yet another Google data center in South Carolina. When asked about  Google's water and power usage, Weiss confessed:   "We're in a highly competitive industry and, frankly, one or two little pieces   of information like that in the hands of our competitors can do us   considerable damage. So we can't discuss it."

What else does Google not tell us? Here's Nicholas Carr:

“We never,” says a Google representative, “comment on who we’re talking to, who we’ve considered, who we’ve rejected. We feel that when we come to an agreement, that’s the time to make an announcement.”

So please, Mr. Thompson - exercise some scepticism. Even a little would go a long way.

The liberation mythology of the internet

Nicholas Carr of Rough Type has been reading David Weinberger's Everything is Miscellaneous, and is disappointed. But in his disappointment he coins a phrase I really like: "the liberation mythology of the Internet".

I only reached the bottom of page nine, at which point I crashed into this passage about music:

For decades we've been buying albums. We thought it was for artistic reasons, but it was really because the economics of the physical world required it: Bundling songs into long-playing albums lowered the production, marketing, and distribution costs because there were fewer records to make, ship, shelve, categorize, alphabetize, and inventory. As soon as music went digital, we learned that the natural unit of music is the track. Thus was iTunes born, a miscellaneous pile of 3.5 million songs from a thousand record labels. Anyone can offer music there without first having to get the permission of a record executive.

"... the natural unit of music is the track"? Well, roll over, Beethoven, and tell Tchaikovsky the news.

There's a lot going on in that brief passage, and almost all of it is wrong. Weinberger does do a good job, though, of condensing into a few sentences what might be called the liberation mythology of the internet. This mythology is founded on a sweeping historical revisionism that conjures up an imaginary predigital world - a world of profound physical and economic constraints - from which the web is now liberating us. We were enslaved, and now we are saved. In a bizarrely fanciful twist, made explicit in Weinberger's words, the digital world is presented as a "natural" counterpoint to the supposed artificiality of the physical world.

There's much more at Rough Type, as Carr demolishes Weinberger's claim.

Trackbacks Are Dead

I hand over a few dollars each month to Six Apart, who own Typepad, for this blog. There are free ones, of course (blogger for one) but when I started off I decided that Trackbacks were worth paying for. If you make a post about an entry on someone's blog, then you can add a trackback, which is a link from their blog post to yours. It looked to me like a valuable part of the conversational aspect of blogs.

But it seems that trackbacks are doomed. I don't think blogger ever supported them. And now many blogs have disabled them, because all you get is trackback spam which is a pain in the neck to deal with. I've noticed that they seem to be going the way of the dodo, and now I see that Trackbacks Are Dead. It's a shame - one more victim of the plague of spam.

But this little corner of the web is quiet enough I still have trackbacks enabled.

Bureaucracy: it ain't just the government

A glimpse inside the world of that old efficient, lean and mean, innovative private industry, Microsoft style, from someone who spent a year working on the shutdown menu.

The scary thing about the story is that you can imagine how it happens, one step at a time, with a good reason for each step. This is not a "what's wrong with Microsoft" story, this is a "what happens in big organizations" story. Read and weep.

Link: moblog: The Windows Shutdown crapfest.

So just on my team, these are the people who came to every single planning meeting about this feature [the shutdown menu]:

1 program manager

1 developer

1 developer lead

2 testers

1 test lead

1 UI designer

1 user experience expert

--

8 people total

These planning meetings happened every week, for the entire year I worked on Windows.
In addition to the above, we had dependencies on the shell team (the guys who wrote, designed and tested the rest of the Start menu), and on the kernel team (who promised to deliver functionality to make our shutdown UI as clean and simple as we wanted it). The relevant part of the shell team was about the same size as our team, as was the relevant part of kernel team.
So that nets us a conservative estimate of 24 people involved in this feature. Also each team of 8 was separated by 6 layers of management from the leads, so let's add them in too, giving us 24   (6 * 3) - 1 (the shared manager) 41 total people with a voice in this feature. Twenty-four of them were connected sorta closely to the code, and of those twenty four there were exactly zero with final say in how the feature worked. Somewhere in those other 17 was somebody who did have final say but who that was I have no idea since when I left the team -- after a year -- there was still no decision about exactly how this feature would work.

By the way "feature" is much too strong a word; a better description would be "menu". Really. By the time I left the team the total code that I'd written for this "feature" was a couple hundred lines, tops.

Update. The original post was down for a while, leading to a flurry of readers coming here instead, but is now back up. Any Joel readers who end up here anyway may want to read what I have to say about the question of choice in software. Or not, of course.

Software Featuritis, or Why Checklists are Bad

Here is a common-sense approach to software development, which I'll call the checklist approach:

1. Propose a new feature.
2. Ask if the feature is useful.
3. If the feature is useful, implement it.

This essay uses shows why the checklist approach fails: why adding useful new features to a software product can make the overall product less useful to end users. This is a phenomenon I like to call  featuritis.

At its simplest, a software product is a set of n independent features (i = 1,..., n). Each feature has a utility to the customer of u_i. The overall utility of the software product to the customer is therefore

U = Sum( u_i )

This tells you to keep adding features to the software to increase its utility, end of story. Not very interesting.

But software is not quite so simple as this. Each feature has not only a utility, but also a cost -- c_i. This is the cost to the end user---not the developer---of using or deciding not to use the feature. The cost may include the time taken to find out about a feature, deciding how to use it, whether it is the right feature to use (among the options available), difficulty exploring and evaluating the feature, and so on.

With this cost added in, the overall utility of the software product to the end user is

U = Sum( u_i - c_i )

Let's keep things really simple, and assume that all features have the same utility (u). We can't do this for the cost though: the cost of using a feature inevitably depends on the total number of features in the product. This may be because it takes longer to find information about a particular feature in the documentation or user interface, or because it is more difficult to decide if this is the right feature to use among those that are present, or a host of other reasons (more on this below). So the cost of finding out about a feature is (c * n).

The overall utility of the software is then

U = Sum( u - c * n )

or, as all the terms are equal,

U = n ( u - c * n )

Which looks like this:

The utility function increases up to a maximum at n = ( u / 2 c ), and then decreases: that is, beyond a certain point, adding new features actually makes the software less useful. In other words, software is vulnerable to featuritis: it can become so complex that its complexity makes it useless. It may contain useful features, but finding these needles in the haystack of the product is frustratingly difficult. Experience tells us that this is a reasonable, if not surprising, result.

What is more, adding features that are useful in and of themselves can still introduce featuritis. For a feature to be useful, its utility (u) must be greater than the cost of finding out about it (c * n). So using this model, features will be added to the software until the following condition is met

n = u / c.

which is where the line crosses the x axis. The maximum utility of the software occurs at half this value (n = u / 2 c): if we continue to add features until the last feature is only just useful, the overall utility of the software will be U = 0. If features were stopped at (u / 2 c), the utility would be U = ( u2 / 4 c ). Even a useful feature degrades the usability of other product features, by making them harder to use (increasing the cost of using them).

It follows that checklist driven software development will lead to poor software. Checklists are simply lists of useful features, without any consideration of the costs they introduce to the customer. A longer checklist is often assumed to be intrinsically better than a short checklist, but we have just seen that this may not be so.

What it is about this very simple model that produces these results? The key assumption is that features have independent utilities, but that the costs of using features are not independent. In economists' jargon, features exert a negative externality on each other. Is there a reason to think this might be true?

The independence of feature utility is simply a matter of defining a feature
properly. For example, if a very common scenario requires two "features" (A and B) then the utility of feature A depends very much on whether feature B is present or not. By itself, the utility of feature A may be very low -- you can't do much with it by itself. Once feature B is present, though, feature A becomes very useful. They are not independent features. The problem here is that "features" A and B are incomplete, and so are really part of a single properly-defined "feature". The model requires that we define features in terms of tasks that customers can carry out. The model does not tell us to implement 5/6 of a feature and then not implement the last sixth because of complexity worries.

The second assumption is that the cost of using a feature is dependent on other product features. The idea of a cost of using a feature is a very general one, and is not only "how long does it take to locate this feature in the documentation?". It may also reflect the confusion and uncertainty introduced by a plethora of choices. For example, if there are multiple ways of carrying out a task, the customer must decide which way is the best. If there are other features that appear to be related, the customer must investigate those (and discard them) before deciding on a course of action. If there are prerequisite features that must be understood, the customer must learn these also. They must spend time evaluating the alternatives. It seems reasonable to assume that the cost of wisely using an appropriate feature does depend on the overall complexity (number of features) in the product. The job of user interface designers and documentation teams is, at least in part, to minimize this destructive interference between product features. Good UI and documentation can help postpone the point at which featuritis sets in, but can't hold it back for ever.

Of course, while simplified models like this might help us watch out for certain kinds of trap, they can't help us decide which specific features to include, and which to discard. Also, there is not much to be gained from trying to pinpoint the particular u and c associated with features or products. Despite the equations, it is a qualitative model and cannot be easily quantified in a useful manner. Finally, while it is certainly true that ui and ci are far from constant in any product, there is probably not a lot to be gained by trying to refine their representation. As soon as models like this are made more complex, the result is a very open-ended and conditional prediction. Building fine software products can't be reduced to equations.

But I do think the central ideas are broadly correct: complexity does influences cost and utility in different ways, software does tend to become overly complex. and---most importantly---asking "is this a useful feature?" is not the right way to develop good products.

Waterfall 2006

Jeremy Zawodny draws my attention to a technical conference called Waterfall 2006 coming up at the beginning of next month. It tackles the thorny question of software development methodolgies, and should be compulsory for all serious technical people. Sign up now.

Link: Attending Waterfall 2006 (by Jeremy Zawodny).

Google Earth is a timesink

I found out this evening that Google Earth has a data update that covers many cities in the UK. Well, that was my evening wasted. You can now see the whole area where I grew up in detail, right down to the car in my Mum's driveway (of a couple of years ago). Very addictive.