Archive for May, 2006

Stevie Starr, Professional Regurgitator

May 23, 2006

The title pretty much says it all, though I will add that the video is highly amusing and not gross. The bit with the goldfish was a bit much, but it all ended well.

See it here on Google Video.

Stevie Starr’s act was written up on the Museum of Hoaxes weblog with an entry that includes numerous speculations from visitors on how Mr. Starr actually does what he does. Read it all here.


Favorite Quote: Roger Ebert

May 20, 2006

My favorite quote from Roger Ebert, film critic, from all my years watching his TV show. From earlier this month, while lamenting the fact that small, independent films get little play in many parts of the country:

“Thank goodness for DVDs, because the distribution system in this country is just absolutely designed to turn every multiplex into an idiot’s convention.”

Firefighting in Product Development: Past the Tipping Point

May 18, 2006

Give an engineer a problem involving interactions between lots of complicated bits of technology and she’ll go and solve it—happens all the time. So why is it that we don’t turn turn those powers of analysis loose on the complicated system that we call the software development process? Applying some rigor to understanding the dynamics of the development process makes huge sense. Turning the crank—producing high-quality products quickly and efficiently—is the essence of product engineering. Doing it well can get new products to market more quickly with higher quality and save your company millions of dollars in the process. Doing it well makes your customers happy and can create scads of new customers.

Well, good news. A group of MIT researchers have applied system dynamics to create mathematical models of the product development cycle and have published the results of their analyses in several papers. One of my favorites, and the topic of this blog entry, is Past the Tipping Point: The Persistence of Firefighting in Product Development by Repenning, Goncalves, and Black at the MIT Sloan School of Management.

Some of their findings are surprising and counterintuitive.

Consider, for example, firefighting—the unplanned allocation of resources to fix problems late in the development cycle. We all do it. We suffer the short-term scheduling hit on other projects to do the diving save. It hurts and we move on.

But it turns out it isn’t that simple. The research shows that these short-term reallocations of resources can, in fact, have serious long-term effects on an organization’s ability to turn the product development crank. Think death spiral.

The Model

For the purposes of explication, the authors created a simple model that illustrates their primary findings without getting into the messier details of their more complex, true-to-life models. The model is based on a several assumptions.

First, assume the organization releases a product every 12 months. The development cycle for a product consists of a 12-month concept development phase, followed by a 12-month product design and testing phase. At any given time, the organization is working on two products simultaneously–the design and testing phase for this year’s product and the concept phase for next year’s product.

Second, assume that the overall resource pool for the organization is fixed. If unanticipated problems arise during the design and test phase for this year’s product, resources will be borrowed from next year’s concept development work. This is the typical firefighting scenario in which longer term work is either skipped or delayed to deal with shorter term problems.

And, third, the model assumes that upstream concept development work that is skipped (for example, creating clear specifications of customer requirements), will create additional rework in the subsequent design and test phase for that product. There is ample industry evidence to support the reasonableness of this assumption.

The Dynamics

The resulting system dynamics model (see diagram from the paper, below) has two feedback loops. In the Rework loop, more design problems in this year’s product leads to more resources being tasked to fix those problems, which in turn reduces the number of design problems in the product. The other, Tipping Loop, is intimately tied to this first loop. In the Tipping Loop, as the number of resources assigned to do rework on this year’s product increases, the number of resources available to work on the concept phase for next year’s product decreases. This, in turn, results in less work being done on concept development activities for next year’s product, which then, after a delay, results in more design problems in the subsequent design and test cycle.

So, what happens when you run the model under various scenarios? The model has a tipping point as illustrated in the diagram below. The tipping point, which is marked with the blue circle, divides the phase space into two regions. The arrows indicate the direction of motion in phase space for each of the two regions. In the bad region, the amount of up-front work completed this year is low enough that it causes significant rework in the following design and test phase. Which pulls resources off of the up-front work being done in next year’s concept phase, which in turn creates even more defects in the subsequent design and test phase, etc. The 2nd diagram shows both the vicious and virtuous cycles illustrated graphically.

[phase plot1]

[phase plot2]

The research shows that product development organizations have a Tipping Point and if you push them too far, you run the risk of pushing the organization into a death spiral of decreasing capability. Even worse, just as airline pilots cannot rely on their innate sense of physical orientation to pilot a plane, engineering management’s intuition just doesn’t work in dealing with these kinds of organizational problems. Our gut says temporary resource shifts should have only temporary ramifications. At some point, that just ain’t so.

Pilots can be trained to fly on instruments. It remains to be seen if the same can be said for engineering management. This research is an attempt to raise awareness of the issues and highlight some of the non-intuitive ramifications of persistent firefighting in development organizations. I recommend reading the paper for a much more complete explanation of the model and its consequences.

Parallels Ate My Ethernet

May 18, 2006

Last night Parallels virtualization software ate my Mac Book Pro’s ethernet. At the time, I was at the Hilton Garden Inn in Austin (recommended if you are visiting Sun’s Austin campus) and having trouble connecting to the Internet using their complimentary high speed access. The symptom was an immediate (as in “very fast with no timeout delay of any kind”) failure to reach any web address with a statement from Safari that I was not connected to the Internet.

Turns out that the virtual ethernet device installed by Parallels had somehow become active, even though I haven’t run Parallels beta6 since it corrupted my Windows XP virtual machine. Looking under Network Preferences –> Network Status I could see my Airport and the Parallels Host-Guest Adaptor, but no Built-in Ethernet. Odd. But I remembered reading something about this on an online forum.

I fixed the problem by deactivating the Parallels Host-Guest Adaptor under Network Port Configurations. The built-in ethernet came back and all was well.

Parallels Virtualization: Yes, but…

May 9, 2006

I’ve been kicking the tires a bit on Parallels Workstation 2.1, the virtualization software available from Parallels Software International as a beta version for Intel-based Macs. I’m running Beta6 on my 2GB 1.83GHz Mac Book Pro.

While I like the software well enough to have pre-ordered the final version, this is clearly still a beta quality release at best.

So far, I’ve created a single virtual machine and installed Windows XP. The installation went relatively smoothly, though for some reason the CD/DVD drive disconnected several times from the virtual machine during the installation process and I had to restart the VM to get it reconnected. A minor annoyance in what was otherwise pretty straightforward.

Having an XP instance available within my Mac OS environment is going to be very useful for running several Windows applications that I need occasionally. It will be much more convenient than rebooting to the XP partition I’ve also installed on my Mac Book Pro. I’m hoping eventually to reclaim that partition once Parallels is running solidly.

I’m not currently using Parallels due to the last failure I had. A few days ago I shut the lid on the laptop to put the machine to sleep with a VM running. As I closed it, the chipper and very familiar Windows shutdown tune sounded off just as the lid reached the keyboard. That didn’t sound good. And, in fact, it wasn’t. When I reopened the laptop, Mac OS had shut down. And when I restarted Parallels and tried to start XP, I found that the virtual disk was corrupted and the virtual machine was continually trying and failing to start XP.

I’m going to wait for another few releases before going to the trouble of reinstalling XP.

It’s a great idea, offered at a great price. But, please, make it a great product!

Tongzhi, ni jiao shenme mingzi?

May 7, 2006

The next time you’re annoyed at some seemingly inane mandate that has come down on high from your corporate IT department, consider the following.

The April 15th edition of the Economist reports that due to software deficiencies in mainland China, the police are banning the use of rare characters in people’s names because they cannot be correctly represented using their current software packages. People with such names have long had problems with everything from booking airline tickets to opening bank accounts, according to the article. This apparently became a particular problem with the introduction in 2004 of national ID cards with embedded microchips.

Bad news for the estimated tens of millions of Chinese citizens with rare characters in their names.

That old version of Mozilla you’re being forced to use doesn’t look quite so bad now, eh?

The Radiant Vista

May 5, 2006

Photography as a contemplative event. A composition, a statement, a point of view.

This is not an approach encouraged by today’s digital camera technology which allows one to take literally hundreds of shots and then sort out the good from the bad later. There’s something not very satisfying about chewing up gigabytes of space with photos that I never quite get around to reviewing, editing, culling.

I took a landscape photography class last year at the Rhode Island School of Design. Our instructor insisted that we take every photograph for the class on a tripod as a way of forcing us to compose our shots. It wasn’t until well after the class was over that I really understood what he was doing—and how badly I had failed. Sure, I used a tripod at every location we visited. And I blasted through my 1 GB memory cards like there was no tomorrow. Hundreds of photos, some very nice. And many not worth the write-cycle used to save them to disk. Exposure bracketing is one thing, but massive compositional bracketing is another. Where’s the art or craft in that?

One approach to taking better photos is to study the works of others. I have several books that I’ve found inspirational. For example, Sam Abell: The Photographer’s Life is a wonderful collection to ponder. Another fantastic (and free) resource is the Daily Critique section of The Radiant Vista website. While my focus is the Daily Critique, do check out the other features on the site–a Photoshop Workbench, Video Tutorials and PDF Tutorials, etc. Wonderful stuff.

Each day a 3-5 minute video segment is posted on the site (RSS feed available). The format is simple and very effective. A landscape photograph–submitted by a beginning, intermediate, or advanced photographer–is displayed and critiqued. The reviewer, Craig Tanner, first discusses what he likes about the photo and then turns to considering in a perfect world might be changed to create a stronger composition. He will often recrop the image or make some other adjustment to illustrate his points, an approach I find very useful.

I’ve watched perhaps a dozen critiques so far and all have been informative. I also find I’m starting to look at both photos and landscapes in a different way. It has been a literally eye-opening experience.

I highly recommend the Daily Critique for all you camera-toting world travellers. Tune up your eye a bit and see what happens.

Apple Spaces Out

May 4, 2006

Email sent from Mac OS Mail and read by other mail clients appears to have extra spaces inserted throughout the message, including spaces that break some URLs into two pieces, rendering them invalid and unclickable.

Apple’s crime as it were is that they’ve apparently adopted a relatively new email standard which has not yet been implemented in many (any?) other common mail clients like Mozilla Mail, Thunderbird, or Outlook. That would be okay if they’d made the feature optional, but there doesn’t seem to be a way to turn it off. And, worse, their implementation of the new feature is wrong…or at least poorly done. They shouldn’t be segmenting URLs.

The new feature is the DelSp parameter that is described in RFC-3676. It is used to implement a new way of inserting soft breaks into Text/Plain email that is meant to be flowed (Format=Flowed), the default for Mac OS plain text email when any lines in the message exceed 72 characters. Soft breaks are marked by ending a line with a space, followed by a line break. The message header specifies “DelSp=yes”, which instructs the receiving mailer to logically delete the ending space and the line break. If a URL was broken apart in this way by the sending mailer, the receiving mailer will reconstruct it by removing the intervening space and the line break. Unless, of course, the receiving mailer doesn’t recognize the DelSp parameter, in which case URLs will be split by intervening space and won’t be valid, clickable links.

I said that Apple’s implementation is wrong or at least poorly done because the RFC states the following:

Regardless of which technique is used, a generating agent SHOULD NOT insert a space in an unnatural location, such as into a word (a sequence of printable characters, not containing spaces, in a language/coded character set in which spaces are common). If faced with such a word which exceeds 78 characters (but less than 998 characters, the [SMTP] limit on line length), the agent SHOULD send the word as is and exceed the 78-character limit on line length.

While it’s true that the language says SHOULD and not MUST, breaking URLs is really poor form. Apple should fix this problem.