Tuesday, April 22, 2008

Fix: Windows Live Writer install: "Sorry, we couldn’t install this program"

I ran into an issue while trying to install Windows Live Writer, a blog-posting package, at work earlier this week.  The installer would work for a few minutes, and then fail with the rather uninformative error "Sorry, we couldn't install this program", and offer to put a shortcut to the installer on the desktop for me to "try again later."  I did "try again later" a couple of times, but the install kept failing in the same manner.

Tonight, I brought my laptop home, and tried the install again, and it worked just fine.  I suspect the difference is that here at home, I'm not behind a proxy server.  Why the Live Writer installer didn't pick up my proxy settings at work from IE and contact whomever it wanted to contact using those, I'm not sure.  For anyone getting this error who is behind a proxy server, though, I would suggest trying the install again from an alternative location that is not behind a proxy server, if you are able to.


This post is also doubling as a test post, written and published via Live Writer!  Thanks to Scott Hanselman for the recommendation (in this post).  This does seem like a very nice tool so far.  It appears to support uploading images to a customizable FTP destination separate from your blog host -- hence my image test above -- and if this works out, it will likely replace the custom FTP image resizer/uploader app that I wrote for my wife that she uses when she blogs!

Fix: "Bluetooth device not found" on Thinkpad T60

I recently picked up a Bluetooth-enabled camera phone, and so I became interested for the first time in getting the Bluetooth functionality on my work laptop (a Thinkpad T60 running Windows XP) working to allow me to easily download pictures from the phone.

However, when I launched the Bluetooth Configuration applet from the Control Panel, it would hang for 5 or 10 seconds, and then show an error: "Bluetooth device not found. Please verify that your Bluetooth device is properly connected and turned on." In the Device Manager, under "Bluetooth Devices", only "Bluetooth Bus Enumerator" was listed, but no other specific Bluetooth device.

At this point, I was wondering if I didn't actually have Bluetooth hardware installed (despite the presence of a Bluetooth usage indicator icon on the machine); when I first got this machine, the internal wireless card wasn't yet installed, and I needed to take the machine down to the IT department to have them pop it in. However, one of the IT folks I talked to confirmed that the Bluetooth capability should be present in the existing wireless card.

The solution turned out to be that Bluetooth was disabled in the BIOS. In the BIOS, in the Network section, there is a setting named Internal Bluetooth Device; the value was set to "Hidden." I changed this to "Enabled," saved, and rebooted, and now the Bluetooth card does show up properly in Device Manager and in the Bluetooth Configuration applet.

So, I can now successfully pull photos directly off my camera phone to my PC, without having to individually email them to myself from the phone as picture messages (and pay my wireless provider for the privilege)!

Friday, April 11, 2008

Software Developers' $300 Discretionary Productivity Budget

Currently, there is a state of affairs at many companies that employ or software programmers or developers is that if a developer wants or needs something to improve their personal productivity -– for example, a new piece of hardware such as a 2nd monitor, or a book on a new software development methodology –- that need is essentially treated as "non-standard" or "out of the ordinary", and requires special approval from a manager.

After reading Jeff Atwood's recent blog post We Don't Use Software That Costs Money Here, I got to thinking: Wouldn't it be nice if every developer had a small discretionary budget from their employer of, say, U.S. $300 to go out and buy themselves things they want or need to help do their job better? The developer could just order themselves what they need -- no special approval required -- and then expense it to the company, up to that annual $300 limit.

What would the discretionary budget cover?

Some things that a developer could use the budget to purchase:
  • Hardware:
    • An additional monitor - around US $150-350
    • A video card or laptop dock to run the additional monitor, if needed - $50-150
    • A custom mouse or keyboard - $30-80
  • Software development-related books/manuals - $30-60
  • Non-free software tools - $5+
  • Non-free development-related magazine subscriptions - $10-40
  • Possibly, even "non-technical" things like a desk lamp or a nicer chair
Things the budget would not be intended to cover:
  • The obligatory development machine upgrade every 3/4/5 years that developers generally need to be able to keep up with modern software.
  • Major software packages that developers require to do their jobs, such as a copy of Visual Studio for developers working in a C# shop.

Why $300?

I picked $300 because it's enough to buy a modest amount of items that can make a real productivity impact; say, a decent $200 monitor and a couple of $50 books on development methodology. If a developer needs to spend beyond the $300 limit – say, to buy one more book, or to do something more expensive like attend a conference – they could just get special permission from their manager (as would otherwise be the status quo for any request, without the discretionary budget).

A budget amount of much more than $300 – say, $3000 – could be problematic because developers at some point would likely feel like they would rather have some of those budgeted funds go directly to their salary. $300, spread over an entire year, is an amount that is probably low enough for most developers not to feel annoyed that they are losing potential compensation.


What are the reasons that an employer of software developers might want to set up a discretionary "productivity budget" for their developers?

  • Productivity. Developers can use the budget to increase their own productivity, which directly translates to a productivity gain for their development team, and in turn, for their employer.
  • Morale. Existing developers are happy because they can (within limits) just order themselves what they need, instead of needing to worry about getting approval from a manager, or that they might be "overstepping their bounds" by making a special request.
  • Recruiting. Recruiting is benefited, as the discretionary budget can be presented as a differentiator to prospective hires. Prospective new employees could see the budget as a sign that the company is in tune with developer's concerns, and that the company's developers are empowered to make their own development-related decisions (rather than having such decisions be made by potentially non-technical management staff).


Why might an employer of software developers not want to implement this policy?

  • Budget. If a development manager implements the $300 discretionary budget policy for his team, and there are 10 developers on the team, that's an annual cost of $3000 that needs to come from somewhere. Taken on its own, that figure might initially seem like a somewhat large amount for the manager to approach upper management and request. However, I would argue that the multiple real benefits provided by the discretionary budget (as outlined above) outweigh the relatively insignificant additional cost of the budget as compared to the (most typically) six figures already being spent on the developers' salary and benefit packages.
  • Perception of lost salary. As noted earlier, the potential exists for some developers to be annoyed that the $300 is money that could be going towards an increase in their base salary. However, I think the potential for negative impact stemming from this perception is limited – I suspect there aren't too many developers today who are annoyed that they have such a nice development machine to work with, because their employer could have bought them a weaker machine, and passed the $150 saved along to them!

Who owns property purchased with the budget?

If a developer buys a monitor or a book with the money from their discretionary budget, who does that item belong to? Who owns the item?

The Developer. The developer owning such purchased items, no strings attached, probably isn't a good policy. There would be nothing to stop a developer from buying a new video card and taking it home to exclusively use for playing computer games. The employer wouldn't see any real benefit in that case, and the development budget might as well just be rolled into the developer's salary.

The Company. A policy of the employer owning purchased items is a possibility. If the developer leaves the company, the company would retain possession of any items purchased. There could be situations where developers might purchase specialized items, though, which the company wouldn't have any real interest in retaining, such as a left-handed trackball (in the case that there are no other trackball-favoring lefties on the team).

The Developer – with a caveat. An employee-friendly approach that blends these ideas would be to allow the developer to have ownership of purchased items, but stipulate that the items are for use at the office only. This would give the company all of the benefits of the developer gaining productivity through use of their purchases; and in the event that the developer leaves, the company wouldn't be out a significant amount of money. This would also mitigate any perception by developers that the discretionary budget funds are coming out of their salary.

Whatever ownership policy is chosen, there are cases where exceptions to the general policy would be reasonable; for example, the company might allow developers to purchase a development-related magazine and have it delivered to the developer's home address (rather than to the office), to allow the developer to read the magazine at home in their spare time.

What happens to leftover funds at year's end?

My suggestion would be that funds left over at the end of the year would not be carried over to the next year; time-limiting the budgeted funds in this manner would encourage developers to use the funds to improve their productivity (per the budget's intention), rather than "hoarding" budget dollars, or alternatively, just ignoring the budget.

One potential issue with this approach is that some developers might, at the end of the year, spend their budget on frivolous purchases, just so their funds aren't "lost." One possible way to deal with this might be to give developers a cash award equal to something like 20% of their leftover budget funds. A developer with $100 left over at the end of the year might then be encouraged to not spend their money, to get the extra $20 in their paycheck; but the 20% is a low enough amount that developers probably wouldn't be very motivated to purposely refrain from spending any of their $300 budget throughout the year, with the intent of earning a mere extra $60 at year's end.

A realistic implementation of an existing concept

Certainly, the idea that developers should be given significant latitude to obtain whatever equipment they feel they need to do their jobs, and to have other exceptional on-the-job benefits isn't a new one; good articles on this topic include Joel Spolsky's A Field Guide to Developers and Jeff Atwood's Programmer's Bill of Rights. However, I have observed that companies which aren't among the group of a relatively few "elite" development-centric companies along the lines of Google, Microsoft, Joel's Fog Creek, or Jeff's (until just recently) Vertigo would (and actively do) simply balk at the prospect of the required expenditure and (perceived, at least) questionable ROI of implementing Joel's and Jeff's suggestions.

On the other hand, a basic $300-per-developer budget at outlined in this article might be more palatable, and thus realistically more likely to be implemented, at the mainstream of companies that employ developers -- both software-industry companies, and companies in other industries that have developers on staff to develop internal applications.

Action Items

Developers, feel free to present the developer's discretionary budget as described in this article to your manager, and see if you can't get a productivity-enhancing discretionary budget approved for the developers on your team.

If anyone does get such a budget implemented at their workplace after reading this article, please do let me know. I would be happy to hear about it!

Wednesday, April 09, 2008

How to rescue an off-screen window

On Windows, it is possible to get into a situation where one or more application windows are positioned entirely outside of the bounds of the viewable area of the monitor. This can sometimes happen with a machine in a multi-monitor setup where one of the monitors is disconnected; an application window that is in the minimized state at the time that a monitor is unplugged can, when the window is restored (un-minimized), be restored to a position somewhere off the screen, in what was the viewable area of the disconnected monitor.

Here's one way to "rescue" such an off-screen window and bring it back onto the active monitor:

  1. Make the off-screen window the active window by clicking on its icon in the Windows Taskbar.
  2. Press Alt+Space, and then press the M key. This will activate the window's system menu, and put the window into "move mode."
  3. Press any arrow key once. This will put Windows into a mode where moving your mouse will drag the active window around the desktop (even without holding in a mouse button).
  4. Move the mouse around until the window reappears on the active monitor.
  5. Left-click once with the mouse (anywhere) to exit "move mode."

That's it! This works on Windows XP, Windows Vista, and Windows 7. I hope this helps!