We interrupt this program...

The worlds of workers and managers are different. Very different.

An observation: Workers work on things, managers work with people. This should not be a surprise. In an automobile assembly plant, the folks on the assembly line (attaching things, adjusting things) are workers. The managers see that people have the tools they need and plan out the work.

For a worker, the 'tools of the trade' are the tools of the trade: hammers, screwdrivers, welding torches, calipers, text editors, SCUBA tanks, ... whatever. Work consists of using these tools to build, fix, or change something.

For managers, the 'tools of the trade' are status meetings, progress reports, and plans. Work consists of talking with others and coordinating activities.

And here we have a significant difference in views.

Workers think of work as 'doing the task'. Managers think of work as 'talking with people'. The talk may be in the form of a conversation, a phone call, or perhaps an e-mail. The tasks of planning and scheduling are secondary to the tasks of communication. Some could argue that a plan is simply a sophisticated form of communication, since it coordinates the work of others.

It's no wonder that managers like status reports and meetings, especially in times of crisis. (Who hasn't been in a crisis where managers asked for daily updates?) Workers, on the other hand, find them distracting.

There is one aspect of communications that is particularly troublesome: interruptions.

I suspect that managers view interruptions as normal, possibly even expected and efficient. Workers view interruptions as... well, interruptions, and consider them detrimental to productivity.

With current technology, interruptions come via a number of channels:

- Walking up to a person and asking "may I ask a quick question?".

- The phone.

- E-mail. Especially when the e-mail system produces noises and graphic alerts that there is a new message.

- Instant messaging.

An interruption requires a 'context switch', a change in thought. When deeply involved in a problem, a worker will give it a lot of thought. Changing the thought to a different topic requires time and effort.

Jerry Weinberg speculates that a context switch reduces efficiency by ten percent. [Quality Software Management, volume 1] This leads to some interesting conclusions: a person working on two tasks (and switching between them) will be able to provide forty-five percent of his time to one and forty-five percent of his time to the other, with the remaining ten percent being 'wasted' in switching from one to the other. The waste increases with the number of tasks.

Project planning software assumes a cost of zero for these switches.

I don't know that I agree with Weinberg's proposed value of ten percent, but I know that I don't buy MS-Project's value of zero. Switching does take time, and the amount of time depends on the complexity of the tasks.

Beyond the cost of switching: Some tasks take time, significant amounts of time. Programmers, working on a problem, will get into 'the zone' where they can focus on the problem (and a solution). They need to stay in that mental state for peak efficiency. 'Significant' will vary with projects, technologies, and tasks, but let us say that a significant amount of time is a period of three hours or more.

If you want a person to work for a significant amount of time, then you cannot interrupt him.

On the other hand, if you (as a manager) expect a person to be interruptible (either by yourself, his co-workers, or others), then you cannot guarantee a period of un-interruptible time, and he will be unable to achieve optimum efficiency.

You cannot have it both ways. Either a person is interruptible (and you pay the penalty for interruptions) or he is not (and you cannot get that 'quick question' answered -- at least not right away).

As I see it, both extremes are bad. Constant interruptions will not allow the worker to finish, and no interruptions will not allow critical questions to be answered. The solution must be a balance, allowing some interruptions but blocking others.

So the question is: What can you do to limit (to a reasonable degree) interruptions?

Canaries in the .NET coal mine

Way back in 2004 (ancient times for the .NET world), Kathleen Dollard wrote an editorial entitled "Save the Hobbyist Programmer", in which she described hobbyist programmers as canaries in coal mines, and further observed that the canaries were dying (figuratively). Hobbyist programmers were not able to keep up with all of the technologies in the .NET universe, and therefore had to move to other arenas.

The editorial provoked a number of responses, some more reasoned than others. Many of them are available on the web (search for "Save the Hobbyist Programmer") although the original editorial is locked inside the Fawcette web site (registration required).

In May of 2007, Kathleen Dollard wrote another editorial, "Pace of Change Leaves No One Competent". In this essay she writes: "No one has time ... to maintain competence in .NET development. ... [T]oday no one can be competent in writing ... modern, high quality applications in any specific genre..."

Both of these editorials appeared in "Visual Studio Magazine", a cheerleader for Microsoft technologies. (The magazine calls itself "Visual Studio Magazine", but most articles are about .NET technologies and not the Visual Studio IDE.)

If the cheerleaders are having discouraging thoughts about .NET technologies, what are the laity thinking?

(To be fair, the second editorial is a retrospective and contains the line "I am more optimistic today". But this line appears a full three-quarters into the article, after a lot of observations on the state of current affairs in the .NET world. And Dollard's suggestion seems to be 'specialize as part of a team', which leaves the hobbyists -- loners, usually -- out in the cold.)

I think the laity are overwhelmed and scared. And they should be: the .NET world is big. Really big. Way too big to learn, and frequently changing. Individuals had a fighting chance of learning C++ and MFC, and certainly could handle Visual Basic in its various incarnations, but .NET is an order of magnitude more complex. (And even Visual Basic required running on a treadmill, with significant changes from one version to the next.)

Microsoft has made attempts to bring hobbyists back to the fold, with the 'Express' versions of products. And while it has worked to an extent, I think Microsoft doesn't get it. Yes, the cost of purchasing products is a barrier for hobbyists, but so is the learning time. Making free editions (crippled or feature-limited) of products does not help the hobbyist when the API contains tens of thousands of entities and changes annually. I don't have time to spend learning an API that I will have to throw away in a year or two. I need to get something working, now. Or at least by the week-end.

Which means that hobbyists must make a choice about .NET: Attempt to learn enough to write small applications, piggy-back hobby efforts onto a day job, or abandon .NET for something else.

Learning enough for small applications is possible, but requires time (and keeping up with changes). A hobby is something I do for enjoyment, in my spare time. It should not be a second job.

Piggy-backing onto my day job may work, provided that my day job deals with enough .NET tech and I have resources to consult. But then my hobby starts looking like my job. Ugh!

Abandoning .NET is not a simple step. For starters, where does one go? Back to MFC? (It had its warts and support will be diminishing in the future.) Change to Java? (That has many of the problems of .NET, although there do seem to be more consistencies.) Switch to Perl, or Python, or Ruby? (They are somewhat more stable, but still require learning.) I don't see a good option.

Maybe I yearn for the "good old days" of BASIC. (Not Visual Basic, but Dartmouth BASIC.) I suppose I could have entitled this rant "The Future isn't the Same as the Past".

But it does scare me that the cheerleaders are complaining.