Geeks With Blogs
Joe Mayo

Async is short for asynchronous, the ability to start a block of code and immediately return to the calling code. This is the opposite of synchronous, where the code goes off and performs a block of code and doesn’t return to the caller until it’s done. If you’re going to Tech-Ed this year, be sure to check out their sessions on language support of async. The crux of this post examines what async means to the user experience.

Much of the discussion of async these days focuses on how easy the next version of C# and VB make it for the developer to code async. This is important because the alternative is that a developer tires of the complexity in past and current async technologies and goes synchronous.  However, there’s a more important issue that trumps the personal preference of any developer: the user (a.k.a. customer).

The customer is the reason a developer has the job they do.  The customer has the money, sets priorities, and establishes requirements.  Granted, a customer might not be technically sophisticated enough to create a requirement that says “Feature X must operate asynchronously”, but that’s where the developer needs to do the right thing.  I use developer in a very loose sense, to cover anyone involved in the technical endeavor of designing and constructing software. So, what I’m saying is that the right thing to do is look at how a specified feature is suppose to be used, the resources required for doing the work, and (if necessary or possible) properly estimate the additional time required to add async capabilities to the code. 

Notice that I said, “If necessary or possible”.  One example that might not pass the “necessary” criteria is an algorithm that completes so fast that the perceived performance (what the customer sees) is immediate.  The “possible” criteria appears when you, the customer, or anyone else can’t see far enough into the future to see what the impact of a feature is.  The calculation to perform an operation could be fast today, but requirements might change or resources increase later, affecting the scalability of the solution.

I digress in qualification, but the real issue here is the user experience. Have you ever used a program, hit a button, and the screen went blank or became non-responsive for a number of seconds or longer?  How did it make you feel?  Curious, unsure, anxious?  Put yourself in the seat of the user that has no indication of whether the program is ever going to return.  Think about the user who is minutes away from a deadline, only to wait on a software program that isn’t telling them anything.  Consider the person who has worked for hours on a project and is very afraid of loosing their work to an unresponsive system that is hanging.  If there’s hard-drive activity, they might get a sense that something is happening, but if the logic is compute intensive or blocking on network I/O, there’s no way to know what’s going on.  After a while, panic sets in and they repeatedly click, push buttons, or might restart the system.  If they’re patient and wait, eventually, that panic will give way to relief when the application finally comes back alive.  More technically savvy customers might transfer their emotion to anger and wonder why they receive no feedback from the application.  Clearly, async is a practical consideration, but the customer doesn’t know that; they just hate you.

The point I’m making is that the “Lazy Developer” scenario shouldn’t be the real motivation for async.  Meeting and exceeding customer expectations is a mark of professionalism. A good application will keep a user in a comfort zone and in control of their work. Async is important because it can be a useful tool to improve the customer experience and confidence in those who delivered the application.



Posted on Saturday, April 23, 2011 11:23 PM | Back to top

Copyright © Joe Mayo | Powered by: