We recently shipped a significant release (way to go guys!) of our application. At the end of a release cycle I typically demo the app to the other depts to bring everybody up to speed on the new features. Since this release is chocked full of brilliant new features, not to mention a completely updated UI, I had what I thought was a genius idea: create a screen capture demo video.

It seemed simple enough: just go through my normal demo, but record it. To my surprise, this has turned into a humbling experience. I don't think I've ever overestimated my abilities this much in my life! Doing voice overs of a screen capture demo is surprisingly hard, and editing your own voice: painful. Every stutter, verbal tick (I say 'actually' a lot), and oddly timed pause has me second guessing my fundamental ability to communicate.

I'm using a lo-fi headphone/microphone combination from Microsoft, which isn't improving the situation. Listening to your digitized voice over and over is damaging to the psyche. It is schizophrenic, and by the end of a long editing session in the cheap headphones I thought I was going to lose it. But I'm making progress. My annunciation is improving, and I'm using a strategy to produce the demo in shorter segments. This makes editing in Camtasia much easier, and I think it is better to separate long presentations into shorter videos to make it easier to index.

I strongly believe there is value for developers and technical managers in honing presentation skills (and I am surprised by my lack of productivity in this area), so I will stick to it, but I find myself wanting to retreat to the warm confines of editing code in emacs.

The netbook represents a serious threat to Microsoft's core OS business. For years, I've believed Microsoft was in a precarious position in the market because the cost of software had become a larger precentage of the cost of a new PC.

In 2004 I said:

When PCs cost $3000+, DOS and Windows ran about $100 for OEMs. That amounts to about 3% of the retail cost. Fast forward 10 years. A PC can be had for less than $500. If Windows cost even $50 (which is low), that is 10% of the total cost...

As hardware costs continue to fall, the software costs will become a greater percentage of the total cost of a PC. Eventually something is going to give. Either Microsoft will have to lower their prices or the manufactures will start looking for alternatives. Neither is good for Microsoft's profit margins.

These days a netbook can be had for less than $300. The netbook represents an extreme in low cost computing, which according to Steve Ballmer, means, "a little less revenue per unit to Microsoft." At the same time Microsoft is positioning themselves as the premium product for business computing over Linux. This opens a significant foothold for Linux in the low end of the market, and the day that Linux finally starts to topple Microsoft on the desktop is here. Windows 7 will run on the netbook, but it will not create the monopoly margins of Microsoft's past.

What I've been expecting since the 90s is becoming a reality. The desktop OS and software are becoming a commodities. The PC is just a conduit to access the far more vast resources of the net. In the words of the great JWZ, "It's all about the network."

Outside a few choice racing sims, I've never really gotten into gaming. I've always found coding itself to be enough of a game to keep entertained at the keyboard. But Jeff Atwood, he's a gamer, and it makes him a better developer.

Until recently I didn't think that gaming could improve my understanding of general application design, but it is becoming clear that Jeff's appreciation for the psychology of gaming (aka fun computing) is helping to make Stack Overflow a success.

Consider the following from the 13th episode of the StackOverflow Podcast [transcript].

[Listener question] Isaac Moses: How do you plan to get people who know stuff to keep coming back to your site, and find questions that they know the answers to? Thanks, 'bye.

Atwood: Ah! This is... this is a feature that's near and dear to my heart. 'Cause I just implemented, uh, what will be called badges, so... I am also a big fan of the Xbox 360, I believe it is one of the best products Microsoft has released in a long time...

Spolsky: Do they call them "badges"?

Atwood: ...much better...Ah, they're called "achievements" in the Xbox 360 system, and it's amazing how seductive these things are...

As business application developers, we often focus on the nebulous concept of 'user requirements,' and fail to ask why would a user WANT to use the application. The most successful business application I've worked on gained a bit of a cult following in its niche and garnered a lot praise, but one user's comment stands out in my mind. "I love the application. It's like a video game."

While I processed the comment at the time, it didn't really sink in until recently. The application, for its class, provided a high level interactivity. It also gives the impression that a better solution to the user's problem might be unearthed by spending just a little more time with the application.

The ability to define and manipulate "whatif" scenarios, has helped make the spreadsheet metaphor an enduring success since the early days of VisiCalc. When using a spreadsheet, not only do users get to define the rules of the game, they get to play the game over and over.

What if we lowered our unit prices and raised our service fees?

What if the cost of electricity was 10% higher?

What if gravity was 10.4 m/s/s?

And so on...

I'm becoming convinced that as developers fight for attention among an ever increasing number of options, those who succeed will be those who can answer: "What makes this application fun?"

Note: This is a work in progress, and I'm interested in soliciting feedback. These are the guidelines I use with my own team, but this is my first attempt at formalizing them.

Often when there is a recommendation to omit goto from a language developers pointing out the edge cases where goto can make sense will argue for the inclusion of the construct, and surprisingly even relatively new languages often contain a goto statement.

There are extremely few cases where a goto is optimal, so developers should take a significant pause and be prepared to justify their decision in a code review, before using goto in production code. I believe the same can be said about other programming constructs: macros in C, template meta-programming in C++, or the use of threads.

I've spent enough time debugging or trying to mentally 'prove' the correctness of threaded code, that when I read threaded code my palms get sweaty and I start having flash backs of dark, lonely, nights working by the warm glow of the debugger. Threads are powerful, but threads are also extremely difficult to prove correct, debug, and often result in numerous Also I believe most developers intuition that doing multiple tasks simultaneously or creating multiple threads will increase performance. Because of this I developed some guidelines about when it is appropriate to use threads.

• Utilization of Multiple Core/Processors
• UI Responsiveness
• Concurrent Blocking I/O

Ultilization of Multiple Cores/Processors

If a developer wants to scale a CPU bound application across multiple processors or cores, there is no alternative to threads. It is not common for the OS to provide the programmer the ability to specify which CPUs that their tasks will be scheduled on, and the CPUs will be shared with OS threads and other processors. With that said, if your application is CPU bound and parallizable, it might be appropriate to construct a system which starts as many worker threads as there are CPUs, although it has been my experience that contention either from heap, OS, or hardware will still make it unlikely that adding a second CPU will double the performance of an application.

UI Responsiveness

I got my start in the dark ages of programming under Windows 3.1. For developers who have spent their careers working in modern multitasking environments, it maybe hard to fathom that early versions of Windows and MacOS had no concept of threads or pre-emptive multitasking. Not only did applications run in a single execution context, the entire operating system did.

To give the impression of concurrency, the OS had a main message loop which would pass control to applications by sending them messages. While the application handled the message it had exclusive control of the system, but to keep the system responsive, well behaved applications would have to quickly handle the message (for instance a request to redraw part of a window) and relinquish control back to the OS. I learned the implications of cooperative multitasking when developing a serial I/O library to communicate with a hand held device. While the library used perfectly structured code, or so I thought, with new fangled OO techniques in C++, when the update operation ran, not only did the application become unresponsive, the entire OS came to a halt.

The solution to this problem was to break a long running task up into a series of small tasks that the OS could schedule over multiple events. To do so the application developer needed to create a state machine to model the current step of the long running task. Before the application relinquished control back to the system, the application state would be updated so when the next event occured the application could pick up where it left off. If the application wanted to do something like update a progress bar, when handling a message to draw the status bar, the application would reference the state machine to determine the progress of the long running task.

For many smaller programs this technique works reasonably well, and even in modern threaded OS it is still used. The difference on a modern OS is that if a application spends a long time handling an event, the rest of the OS can continue to operate even if the application appears unresponsive. Most modern applications now create separate threads to handle long running tasks while the processing of UI events is handled by the main application thread. The reason is that is trying to break large tasks up into state machines can become untenable and most developers tend to think of algorithms sequentially rather than as series of state transitions.

Unfortunately using multiple threads to update an applications UI and to execute long running tasks has the drawback that of requiring synchronization of the application threads, and while I believe UI responsiveness is a valid justification of using threads, it also extremely difficult to get right. On the Windows OS it often means sending messages to synchronize the threads through the application's message loop.

It is worth pointing out that the structure of a thread mimics the state machine by implicitly maintaining state in the thread's call stack and instruction pointer. Also instead of allowing the application to control task scheduling by the length of time to handle one event, the OS handles task scheduling by implicitly switching control to another thread or task based on a clock interval.

Concurrent Blocking I/O

In modern networked environments, implementing concurrent blocking I/O this is most the common use of threads and typical in network servers, or clients which must maintain multiple server server connections such as a load test application. Internet facing servers must handle requests concurrently from multiple clients at unknown data rates. Excluding asynchronous or non-blocking I/O, when the server attempts to read or write data from the client, the operating system will automatically switch the context to another thread until the I/O has completed. If the server is handling connections from many clients in a thread per client or connection scenario, many of the threads will be in a wait state consuming few resources. When read or write operation is complete the thread will be activated to continue processing.

It is interesting to note that the GNU pth library is a user mode co-operative threading library which take advantage of the fact that many applications use threads to implement concurrent blocking I/O and hence when the read and write functions are called the library takes the opportunity to switch the context to the next running thread.

Disk I/O is also a common source blocking I/O, since disk access is a local resource it has significantly different properties than handling slow network clients. Starting a large number of threads to concurrently access the disk almost certainly will result in degraded performance as the throughput of the disk system is reached and thrashing increases.

While it is beyond the scope of this discussion, most high performance servers no longer use a thread per connection architecture. Dan Kegel laid the ground work for modern *nix server design with his outline of the C10k problem. Many modern servers including Apache use a hybrid event driven/threaded architecture.

I happened to be looking through some old emails, and I found my review of ASIO.

In my opinion the library should be accepted. This is the best example of an asynchronous library available in either C or C++. All other major program platforms Java (NIO), .NET, Python (twisted) have well accepted asynchronous networking support, and I think this is important for C++ as a high performance networking platform going forward.

I do have one concern, but the over all design of the library is sound.

A memory allocation / deallocation is required PER REQUEST. I could live with this if it was an inherent problem with the asynchronous design pattern, but I have convinced myself that it is an artifact of the boost::bind interface combined with deferred execution. Because the size of the functor is unknown by the library it must be allocated dynamically. It is my feeling that the allocation could hurt adoption in certain markets.

Library users should be provided with the option of providing static function pointers which take an untyped parameter such as void* or boost::any as callback targets. This is how nearly all deferred allocation mechanisms currently work, and it would eliminate the allocation of the functor. Plus more complex interfaces, such as the current bind interface, could be layered on top of this architecture.

In the last year I transitioned from lone cowboy developer to project manager. In this roll I find that I am called upon to make quite a few judgment calls both on the behavior and the architecture of the application.

I am really fortunate to work with a great team who I respect and are far better developers than me, so generally this goes pretty smoothly. But occasionally, either due to my own biases or experience, I find myself in disagreement with a recommendation of one of the team members.

I have a simple solution to this problem. I request that the developer put the recommendation in writing. I do this for the following reasons:

• If the developer doesn't have the energy to codify his or her argument in writing, then it probably isn't that important of a decision and we can move onto the next problem. There are always more problems to solve.
• Putting the request into words forces the developer to think through what is being proposed.
• It is far more likely that a well written argument will sway me than a half thought out verbal discussion.

We use an iterative methodology and don't specify every program element. While I am afraid being a Certified ScrumMaster might still be illegal in some Southern States, I am fan of iterative development. But there are cases where there is value in working out a problem in writing. It forces you to consider possibilities that a purely mental model might omit. If there is enough contention in a decision to actually cause a disagreement, it is a strong indication that the time spent working out the issue in writing will be a good investment. I also believe that being able to defend a recommendation or decision is a fundamental sign of maturity in a developer.

I try to hold myself to same standard. I recently caught myself in a discussion where I was arguing a point verbally in a way that was not fully formed. This left me feeling uncomfortable, and I forced myself to research the problem and present my option in a more educated way. Ultimately this puts the onus on the other party to define their position as well, and the end result is a more thoroughly considered solution.

Developers reading this may ask themselves, "Why do you insist that team members defend their positions rather than just trusting them? Don't you trust your own developers?" I do trust them, but in the past I've worked on projects with multiple smart developers, of one I consider myself, who all had their own ideas about the "right" way to do things. Chaos resulted. It wasn't that any one developer made a wrong decision, but we all made different decisions, and in a large scale software project this is a recipe for disaster (I'd also argue that this is why the philosophy of TIMTOWDI is seriously flawed, but I'll leave that discussion for another day).

I consider one of my rolls to be the arbitrator of chaos, which ultimately means that every developer is not going to get to do things the way they want. This is a professional software development environment, and unfortunately it requires that developers perform their tasks in a manner that is in agreement with the ground rules of the project. That is why I highly recommend that developers unleash their experimental desires in a side project, and I'm even willing to turn a blind eye if they spend a few hours in the office working on it. I can fairly say that my side projects made me A LOT better developer.

But (there is always a but) there is also something to be said about allowing developers have it their way. Yes I still believe we could have gotten away with one less abstraction layer in app, but at the outset it wasn't worth making the developers miserable to enforce an architecture on them that they disagreed with. Happy developers are productive developers, and we had a lot of code to write.

I'm upset by the turn of events in our financial systems this week. It is my feeling that nationalization of a large amount of our financial system will change the face of business for years to come. We are moving to an unprecedented level of socialism in this country, where it will be much more difficult to find credit needed fund new ventures and purchases. Putting the lending system into the hands of the government will result in politicizing our entire economic system. This is not something I am looking forward to.

It is also unfortunate that citizens that have worked hard and acted prudently will now be forced to pay off the debts of those who acted frivolously. This country has lost the sense of self reliance and responsibility that made us great to begin with. I am saddened to watch the greatest free market system in the world be brought to an end in the span of a couple weeks.

With that said, damn did you see that market rally today :)

Kathryn and I spent some of our time off, day hiking on the Tahoe Rim Trail. Sometimes I forget what an great backyard Tahoe provides. I love the smell of tobacco brush and sage late in the summer.

Before we left, I grabbed my Tom Bihn day pack, filled two Nalgene bottles, and then off to the trail head. When I was looking down on the lake, my mind started to wander and I realized the pack exactly the type of product I wanted to discuss here.

I've owned this pack for 12 years, and it has been more places with me than I care even remember, and it still looks and functions like new. Years ago, when I was interning in San Jose, my Jan Sport pack fell to pieces and I wanted a replacement that would out last it, and the mainstream packs didn't instill confidence. I happened into Tom Bihn's small shop in Santa Cruz, and met the designer himself. I knew I wanted one of his packs.

At the time, Tom's packs and bags were made in California from heavy nylon with extra large zippers, a padded back, and held together with perfectly stitched seams. Tom himself seemed to care about the product he was creating. While some mainstream designers have taken to the same over sized design esthetics, I can't imagine any would ultimately be as bomb proof or as well made as this pack.

I pondered the decision, as the pack was about $100, about twice most mainstream day packs of the time, and for a student it was good money. I now expect the pack to last at least another 8 years which would it put its useful life span at 20 years. I think it was money well spent.

A couple years ago when I was looking for a messenger bag, I was happy to find that not only was Tom Bihn still in business, but they had grown considerably. I was even more pleased to find that although the company had moved to Washington State, it had stuck to its original values and still made high quality bags in the U.S. My "new" messenger bag gets daily hard use and it too has been flawless.

The formula:

• High Quality Materials
• Hand production
• Attention to detail
• Experience

The result: I whole heartedly recommend the company to anybody who asks about my bag, and they have kept me as a customer. I am now considering a small messenger bag, and their site is first place I will look.

Growing up in rural Upstate New York, the margaritas I knew were a concoction served from rotating machines, resembling a white 7-11 slurpy mixed with cheap booze. They were something you drank if for some unexplained reason you didn't like the taste of Genny Light. I didn't drink margaritas. I drank Genny Light and jug wine.

In California I ordered Margaritas on the rocks with salt and they became an acceptable alternative to beer after a bike ride on a hot day. When I first made margaritas myself I used a florescent green mixer I bought at Safeway and Cuervo Gold. The result wasn't very good, and these bottles have been sitting on my liquor shelf for 4 years now:

I never truly understood Margaritas until Kathryn and I found Tommy's in an unlikely location in one of the foggiest districts of San Francisco. While the bar and restaurant is probably home to more roaches than we'd like to admit, they have by far the best (and most intoxicating) Margaritas I've ever had.

Their recipe is simple:

• 100% agave tequila
• Fresh lime juice
• Simple syrup
• Ice
• Salt

To the left of the door at Tommy's there is a huge pile of limes, and that's the key. No mixes. Only fresh, hand made cocktails. High quality materials, hand production, attention to detail, and experience. This is a recipe for a quality product.

The overall cost of option 1 (florecent mixer and Cuervo) and option 2 (fresh limes and agave tequilla) isn't much different. Agave tequila is now plentiful at most liquor stores, and I bought one that was on sale. 14 limes, enough for ~7 margaritas, cost $2 at the local produce market.

I'm materialistic. I like things and the design and process of making them, and I don't apologize for this affinity. While materialism received a decidedly negative connotation during the post-industrial boom of the 80s, ultimately a functioning economy and society is materialistic. Succeeding in modern creative industries, including software development, requires a critical eye toward objects and our interactions with them.

Unfortunately, I believe the lack of emphasis on skilled trades and manufacturing in the U.S. has decreased our ability to value goods. Modern consumers rely on branding and advertising to shape perception and purchasing decisions. As a result we have become poor judges of quality and often we receive poor value for our dollar.

As a consumer, I have obsessively sought out U.S. made goods. I'm not a card carrying union member or flag waving patriot, but I believe many leading U.S. companies lost much of what made them great when they abandoned their U.S. manufacturing base for lower cost operations. Some of them lost my business as the choice to move manufacturing offshore wasn't driven by the desire to increase quality, but to decrease costs.

We are now inundated by parades of container ships, but it is increasingly difficult to find goods that offer both quality and value. I find it almost impossible to discriminate between goods sold at Wal-mart from those available from what were formally well regarded department stores.

But I believe attitudes are changing. We are more informed consumers, and as a result of increased commodity prices and a decrease in the value of the U.S. dollar, I believe there will be a shift from the multitudes of low quality goods, to fewer, classic, durable goods of high quality. So after a hiatus from blogging, I'm starting anew with a focus on the things I love (or hate) and our interaction with them.