Anyone not living under a rock knows that Microsoft is trying to buy Yahoo!, but so what?  What difference could it possibly make to an end-user or a software developer whether Yahoo! remains independent or not?

Clearly, this is a buyout of historic proportions.  The size alone is impressive: at $45B, this is a serious chunk of change and a sizable improvement over the market valuation of Yahoo! prior to Microsoft's offer.  But this buyout isn't notable just for size.  This is a pivotal moment in the growth and maturation of the net: a marquis player is quite possibly going to cease to exist independently, and another is at a "make or break" moment.  As far as brands go, this is an impact on the order of seeing Netscape fade away or AOL get gobbled up by Time Warner. Like AOL, it's quite conceivable that the brand will live on for a long time, but it's clear that it'll never again live with the vigor that it's had in the past.

Alan Greenspan's in the news again after he was quoted as saying the current economic meltdown Is "the most wrenching since the end of the second world war."  Now, I know this isn't directly related to software design, but since I've got a degree in Finance, I can't help watching this train wreck, and let's face it - this "situation" has now reached the point where it's impacting the economy as a whole, including software.

I'll be honest - I don't think it's too beneficial for Greenspan to be skulking around the funeral parlor right now offering commentary on the medical care of the deceased.

This morning, I read a blog post describing how to add page numbers to a Google Docs document.  The crux of the technique was to embed some HTML into your doc such that page numbers are generated when the doc is printed via PDF.  "That's it!" I thought.  That's why Google Apps aren't ready to take down MS Office.

Then, this afternoon, I just happened (dumb luck, I swear) to use Google Docs to print a draft of an article I'm working on, and I saw this dialog with - you guessed it - an easy way to add page numbers.   And just like that, I saw the problem for Microsoft.  Google, it's true, isn't there yet, but they're closing the gap -- fast.

Microsoft is clearly working hard to neutralize the Google Docs threat with their Office Live Workspace, but I'll bet they're glancing nervously in their rear-view mirrors constantly.

It's that time again - time to go through the bug list and do some cleanup.  As I work through these bugs one by one, I've noticed that at least half of them end up being slightly more than just bug fixes.  As I crack the hood and peer in, sometimes I see that there's code inside that's not quite up to the standards of the rest of the application. 

When I see this, I generally try to fix the whole bug, and that means cleaning up (refactoring) the messy bits.  In some cases, you're working on an application that someone else wrote, and in these cases it's pretty easy to blame the mess on the moron who coded it in the first place.  But what if the moron was you?  How do you end up with code that needs this sort of attention if you wrote the stuff originally?  There are tons of great articles and books on refactoring, and they cover this area in much more detail, but here are some of the things you're going to run into when fixing bugs:

About four months ago, I helped a client put an application into production.  This client has a mix of internal and external customers, and those customers are essentially captive (they have little choice about using this application).  As with any new application, there are infrastructure headaches, customer questions, training issues, and the like.

I was talking with someone today about a support issue, and I asked how they client was tracking calls, issues, and so on.  "Oh, we're not tracking them."  Ah.