Mark Fletcher (the bloglines guru) explains the effect of speed on a web site / application:

The speed of your service directly affects its usage. We quickly discovered this with ONElist. When the web site was slow, people used it less, resulting in fewer page views. When it was fast, we saw an increase in usage ... we thought that web site usage was very task oriented. Once they finished their task, they'd leave. The speed of the service wouldn't affect the number of pages they viewed, just the time it took to complete their task. But we were wrong.

A slow site leads to an exponential increase in load on the service. ... This is because people are impatient. If Joe Surfer has to wait more than a few seconds for a web page to load, he generally hits the Stop button in his browser and tries to load the page again.

This definitely reflects our general experiences with Sytadel, but I have seen another more powerful way to create exponential load. During the boom I was the technical lead for a very high volume dot com. 4am one morning (Australian time) I get a dreaded “server down” call (9am their time). Restarting Apache and watching the httpd process list grow to >100 in the first few seconds is very disconcerting. The server had been performing well for weeks and investigations later that day revealed the problem. The home page was constructed by using a number of include() statements to pull in various PHP code pieces. A technician for the site had added some new PHP code pieces but was getting the content piece via an fopen() on the full URL rather than using an include(). So, every home page view spawned 4 extra page views on the same server to construct the home page HTML itself.

The fact that I now use Google for all mathematical operations is also testament to this. While drilling down for the Windows calculator a couple of months ago I saw that Google toolbar input field sitting there just waiting for an equation. I had the answer faster than it would normally take to find the calcuator from the Windows Start menu.

Note: Originally posted to my Synop blog on 24 March, 2004.

About 2am last night I was about to crash when I stumbled upon this video demo of the Office 12 UI. Wow! I'm really impressed with the guts to make changes on this scale and think the results look great. IMO, the screenshots don't do the changes justice at all.

Watching people struggle with various Office programs through an MBA, the more adept users normally just sigh and take control of document creation or clean up. So any changes that make the capabilities easier to access or explain is a good thing.

It was also great to hear how much useful information Microsoft gathers from their customer experience program. For example, around 70-90% of clicks in Word are on the standard toolbar.

It's interesting to see that Review has been raised in importance to having it's own top level Tab in the Ribbon UI. This gels with the apparent focus on team authoring in Office 12, building on the success of Sharepoint which was strongly integrated in Office 2003. For Office 11, the Sharepoint team was moved into the Office team. For Office 12, the Content Management Server team was moved into the Office team as well. On top of that, Groove has been added to Microsoft over the previous year.

With Office 2003, Sharepoint was added to the mix. Over the last 3 years it's grown massively in popularity for Intranet solutions. Office 12 will take a while to filter through, but I'm expecting dramatic changes to the enterprise content and workflow landscape.

Many years ago I was a keen user of the Arsdigita Community System. Coming out of MIT, it was licensed under the GPL. This worried me a little:

As I understand it, the GPL states that any work derived from the GPL'ed work also comes under the terms of the GPL. Doesn't that mean that any customized ACS web site must be available publically? I have also noticed with interest that comparable open source projects seem to be releasing under the LGPL (Library GPL).

The response was a very direct "don't worry about it", sensibly trying to shut down any concerns or worries of users and their customers. But, his answer also showed a misunderstanding of the GPL and the general loose care factor at the time about using it:

I'm not a lawyer. I just have an office down the hall from Richard Stallman's so I used his license.
....
I'm too busy programming the next release to worry too much about legal stuff...

But, under the changes proposed to the GPL3 to "close a loophole" I suspect we'll have no choice but to worry.

Developers and website administrators have to be very careful about the software licenses they don't read. The "I'm not a lawyer" argument just won't hold up in court.

In the old web days, a spike of new traffic to your website was normally just that, a spike. After the initial interest had died down the general traffic averages would return pretty much to normal.

An interesting characteristic of RSS is that the traffic is sticky. Once someone discovers your site is interesting and subscribes to your feed, they effectively never leave. This results in a constant upward trend for your traffic statistics.

I wonder what interesting statistics or views we could get of RSS data from the web server? For example, average number of requests / IP address / day; % of requests that returned 304 Not Modified; graph of the length of time it takes for a feed update to reach a majority or readers; subscribers gained in the last month; subscribers lost in the last month; etc.

Note: Originally posted to my Synop blog on July 22, 2004 and picked up by Scoble.

Working long hours, it was common for us to do washing of a weeknight and put on the dryer while going to sleep. But our downstairs neighbour seems to be an insomniac and likes to blame our dryer (among other things).

The most memorable disagreement was the first night that she buzzed us to complain about 10:50pm. I argued back and refused to turn it off until the clothes were dry.

This may seem unreasonable, but we've never heard any noise from any other apartment in 2 years. Also, we'd kindly let her in late one other night a few months earlier to search for a noise that was keeping her awake (not in our apartment).

Anyway, about 20 minutes later I felt guilty and the clothes were pretty much dry so I turned off the dryer.

Then at about 12:30am our apartment buzzer rang again, waking me up. Still annoyed, I answered the apartment buzzer with "What?!?". "Ah, sir, it's the police. Would you mind coming down?". So, I was woken up by a noise complaint follow up from the police. To be honest, I'm not sure either the cops or I knew how to handle it.

I'd love to do a full noise level analysis to check that we're definitely within the NSW noise guidelines, especially since dryers aren't even listed as a potential problem source. But unfortunately, I don't have access to a noise level meter.

Video: Dryer drama.wmv (2.1MB) | Dryer drama (small).wmv (0.6MB)

Borrowing from the infinitely more eloquent writing and ideas of Eric and Joel, music provides a richer basis for the multicore CPU metaphor I tried to build yesterday.

Programming for single core CPUs is like composing a powerful solo piece.

Programming for multicore CPUs is like composing for a band, choir or symphony.

Over the last few days I've been reading up on hardware architecture for the PS3 and XBox 360. With multi-core processors seemingly the way of the future for all the major manufacturers, game developers will continue to be software pioneers over the next few years facing incredibly complex multi-threading and software design problems. From Arstechnica:

But like I said above, that free ride is over, and now it's time to face the multithreaded, multicore music. In the new world, a world of which both the Xenon and the Cell are a part, programmers have a whole lot more work to do, in terms of both splitting their applications up into threads and of optimizing those individual threads. The fact that they haven't yet been able to figure out how to make applications that they learned how to write on the old hardware work on the new hardware is completely unsurprising. The old hardware had a theoretical performance peak and lots of hardware aimed at helping applications reach that peak; the new hardware has a higher theoretical performance peak, and little to no hardware aimed at helping applications reach that peak. So developers have a longer distance to go, and they have less help in getting there. It certainly makes for a vexing combination, but it's way too early to say that it's the end of the world.

Anandtech has a number of great articles for getting up to speed on this hardware architecture and the implications for software:

• Understanding the Cell Microprocessor
• The Quest for More Processing Power, Part One: "Is the single core CPU doomed?"
• The Quest for More Processing Power, Part Two: "Multi-core and multi-threaded gaming"

While there will be many challenges in rearchitecting existing software for optimal execution under this new architecture, I'll be more interested to see what new applications and solutions become possible as a result of the new architectures. Software that has many things going on simultaneously, software that seems to be moving around you rather than just waiting for your next piece of input.

Software developers are used to coaching a single player (think tennis), who got faster and stronger each year. Now, we're being asked to coach a team (think football) where each player gets only slightly better but the number of players available increases each year.

It's time to start rewriting the playbook...

I've been thinking for a while that I don't do enough to encourage exploration of my weblog content, making it hard to discover older content. Of course, most people probably only see it in an RSS reader and thus couldn't care less about my design or branding decisions anyway.

In Embrace your bottom! Derek Powazek might have the idea to kick start some improvements:

Your engaged users - the ones who really like you, yaknow, more than a friend - are sticking with that main content. Everything in the sidebar just makes it harder to focus on your content. Then, when they get to the end, when they're ready for something else to do, when they're ready for that end of the date smooch ... that's the moment it's all been leading up to. That's when users are most open to suggestions of where else to go, maybe do a search, maybe even click on an ad.

In thinking about starting a new business, a big part of the question is what type of business to aim for. I see a few basic types: build yourself a job, build yourself a cushy job, build something bigger than yourself.

When building Google, did they foresee a company that will touch the life of every Internet user? Were the dreams that bold? Or, did they just see a company that could be big? Is the creation of a multi-billion dollar benometh intentional and planned?

I suspect not.

What these founders see, I suspect, is a new simple model. They see potential. They see a new way of doing business that they feel a large number of people will like. Whether that builds into $10M's, $100M's or $1B's can only be discovered with time and is usually irrelevant to the model they've adopted (profits are sound at any of those levels).

Great businesses aren't complex, they're usually incredibly simple. That's why they make sense to customers and can grow so fast. The problem with simple is that it appears easy, but making something simple is the hardest thing to do.

While stuck in bed over the last couple of weeks, I've re-read all the Harry Potter books. They really are engaging and a delight to read. I'm amazed at the depth and consistency of the earlier books, it's clear that the entire series was envisaged from the start.

Harry Potter and the Goblet of Fire (#4) remains my favourite as it has the joy and innocence of the earlier books along with some of the darkness prevalent in the later books.

The last two weeks haven't been the best of conditions for some relaxing time off: 5 days sick with a terrible case of food poisoning, 2 MBA exams and then my wisdom teeth out the very next day.

Video: 16 curly roots.wmv (7.5MB) | 16 curly roots (small).wmv (2.1MB)

A story of unjustified, but appreciated, faith in my building capabilities.

Video: Built to last.wmv (2.3MB) | Built to last (small).wmv (0.9MB)