How do the environment and corporate culture impact managerial decisions? In what context does development context switching make sense? Here are three situations that make sense to me. (And I’m on the developer’s side of this discussion!)

1. Specialized skills. This would be those people that management is lucky to have one of, and their existence has to be spread across several projects to justify their existence. DBAs, architects, object specialists. Would agile coaches be included?

2. A project is completed, the programmers moved on to the next project and:
- a defect is located that needs to be corrected.
- the client requests a series of improvements.
Who better than the original developer(s)?

3. A developer hits a wait state based and can’t move forward until something from someone else arrives. Why not let them get started on something while they’re waiting?

I may be idealistic, but I don’t believe managers purposefully create situations to lower productivity.

Congruent Action

When the manager kicks off context switching, the actions make sense at that level. But systems are multidimensional, and his/her decisions impact other people. Congruent action contains three parts: self, other, context.

For context switching to be congruent, the manager needs to consider how the context switching affects the developer. This best way to find this answer is to ask. Anything short of “How it affect you (and your productivity) if I ask you to …?” involves mind reading, or how the manager THINKS the developer will respond. When the manager has this information, they can make an informed decision.

And Why is That?

People are incredible state machines. Our physiology and emotions create our states. We awaken in the morning and (eventually) go to bed, switching states all day long. Some states gradually morph into others. Some states grow stronger and allow us to get into flow situations where we enjoy the productivity of our thoughts and actions coming together creating high output levels. Some state changes happen abruptly when something jars us.

Restating George’s thought, it’s not the context switch out that’s difficult. It’s the context switch back. Unlike the wonderfully linear microprocessor, we humans tend to be incredibly nonlinear, tightly-coupled, loosely cohesioned (if you know what I mean) creations. This applies even to those of us who believe we are linear and straightforward.

The context switch destroys our current state. If the opportunity presents itself, we may have time to check point our thoughts and where we are in the process. But our thinking up to that point, our physiology, and emotions at that point get lost in the winds of change.

The return trip back then becomes a game of trying to find where we were, why we were there, and what we were doing.

I’m Disinclined to Agree

George stated this problem of people “switching and then switch back” is “unfortunate”. From a management standpoint, he may be correct. But managers would like to believe that knowledge workers are fungible, and that output equals the number of hours worked multiplied by some magic constant. That allows them to complete projects quicker by assigning more people, and having those people work more hours.

It just ain’t so. If you haven’t read Slack by Tom Demarco, do so. Order enough books so you get free shipping and give the extra copies to your manager, and his manager.

Context Switching is Fun!

I usually have 3 or more things going on at any time. Right now I’m doing exploratory work for one client (lots of try this, try that, well, how about trying something else?), upgrading a system for another client (I’ve already done three of their systems), and preparing for a class.

Context switching allows me to mentally shift gears. When I need time to think about what’s happening with the exploration, I can spin my chair, slap in another CD, and nudge the upgrade another step closer to completion.

Context Switching is Profitable!

Being able to swap between contexts allows me to supply better value to my clients. I can wonder about what to do next while I’m shuffling CDs. I can do exploration while I’m waiting for the CDs to finish loading. Everyone’s a winner!

Truth in Blogging

If you’ve read Johanna’s article, you’ll realize differences exist between our examples.

• One switches between similar tasks, the other doesn’t.
• I’m not under deadline pressure. (Should anyone be?)
• I get to choose when to switch contexts.

So the real problem is not context switching. The problem remains management that doesn’t understand what they manage, and how to make it fun and profitable.

Context Switching … good or bad? Share your experiences.

When the day arrived, we gathered the pruning gear and headed into the yard. We decked out in safety gear (including ear plugs) and approached the first tree. My first instruction was “Mmph what in the mumble, mumble.” I put the chain saw down, walked over and said “What?” This time I heard, “Cut the limb in the back.” I walked back to the tree, pointed to the branch in the back and looked at Karol.

She waved her hand, and pointed me to a different limb. It turns out we were looking at the tree from two different angles, about 90 degrees apart. Her “back limb” and my “back limb” were different because we had different view points.

And What’s This Got To Do With Software?

Any piece of software has multiple view points.

• The user views the software from how it will be used.
• The developer sees the software from how it will be built.
• The tester looks at the software from how it can be tested.

Incorporating other view points into your mental model gives a better model for the final product.

Got a story about mis-aligned viewpoints? Send me an email.

Ready, Aim, Click!

Since you’re not reading that post, you’re guessing something went wrong. You’re correct. Instead of clicking the “HTML” tab, I smacked the “Close” button. Did the software notice the time I’d spent working on the post? Did it set a “dirty bit” so it would ask “Do you really want to do this dumb action and lose all the work you’ve done?” Obviously not. Gone faster than a snow flake in North Carolina in August.

What’s Up With That?

This reminded me of a recent project I tweaked. After entering data, the user pressed a “save” button. When the screen refreshed, the section just saved redisplayed, but didn’t show the entered data. Fortunately, I had access to the database and could see the data did get stored correctly. But the user connected via the Internet would have no idea that everything was actually OK. I corrected this defect prior to working on the “wish list”.

Mea Culpa

I remember my introduction to “userless” programming. It happened back when RS-232 ruled connecting computers. My code could detect errors and inform the user “Incomprehensible Input. Please scan again.” My client took me aside and said “Don,no one using this program will understand the message. Can you reword it?” And then I understood. When I leave the office, I am in a different world. No one knows everything everyone else knows. We don’t make the same assumptions. And worse, we all act different!

As Pogo said, “We have met the enemy, and they are us.” I started writing this entry as a rant about losing a blog entry. And here I am going, “Yeah, I’ve done it too.”

So What to Do?

• Obviously, I save more often. (I never did save the original post.)
• Oh Look! There’s an icon on the tool bar for bolding text that automatically include the proper close.
• Wow! CTRL-B, the industry standard for bolding does the same thing.
• I have friends using Blogger. I could see how Blogger would let me shoot myself in the foot.

Anything like this ever happen to you? Have a story you’re willing to share? Innocent people can be protected. Email me.

I’m currently working with a client helping them upgrade their systems to the most recent version of their software. Along the way, we’re refactoring and adding some functionality. The programs all have the ability to exchange configuration data via exporting and importing CSV files. In a perfect world, the data would line up between the programs. Obviously, it’s not a perfect world.

So I whipped out my trusty touch typing skills, loaded a handful exchange files into various programs such as Excel(tm) and SlickEdit(tm) and started blasting away. Ed volunteered to work on the next section of files that needed to be rearranged. The task was tedious and we worked in relative silence. An hour or so later, I completed my section and was ready to test.

We compared our strategies for accomplishing the task. While I was “slaying the monster”, Ed had been trying to figure out how to use Excel’s built in functions to parse the data elements to automatically generate two values that we needed. Using Excel’s built in functions to do string manipulation is like cutting a steak with a dull axe. It can be done, but it’s not a pretty sight.

I saw the forest, and all the work that needed to be done. Ed saw the trees, and noticed that our task would be easier if we could find a way to let the computer do the dull, error prone, highly repetitive tasks. We now have a simple (took less than an hour to write and test) little program that does just that. (No, it’s not Excel.)

There’s a handful of lessons in this story:

• Working with other people can increase a solution’s quality. My way would have worked, eventually …
• Don’t confuse activity with real progress. I completed one section while Ed was “not getting anything done.”
• Minds are like parachutes. They both work better open.

Did I miss a lesson? Let me know.

Requirements

The bad news: it’s just has hard to define small project requirements as it is large project requirements.
The good news: since there are fewer requirements, there are fewer interactions between poorly defined requirements.
Cynic: It’s as easy to poorly define a small project as it is a large project. And it takes less time!

Tools

Tools are not a substitute for good judgment.
Cynic: Good judgment comes from experience. Experience comes from bad judgment.

Tools used on small projects must be flexible enough to be used for several different projects, or tools won’t be used at all.
Cynic 1: A fool with a tool is still a fool.
Cynic 2: A fool with a tool can foul up projects faster than a fool without a tool.

Communications

The problem owner and the solution provider must share a common vocabulary.
Cynic: I know you think you understand what you think I said, but I’m not sure you realize that what you heard is not what I meant.

Got a favorite cynical observation? Let me know.

At the bottom of the third rapid, there were three paddlers on the shore in various stages of “where’s my gear?” Everyone was safe, and with a little time, we found all the gear. The river widened, the rocks got further apart, and everyone made it to the take out.

As I thought about the experience, the parallels to software projects struck me.

• Some people had more skills than the others.
• We could see the start, but didn’t know all the problems we’d find along the way.
• Everyone on the team knew how to take care of themselves.
• When someone got in trouble, other people would help out.
• We moved as a group, although different people lead at different times.
• We all got to the finish.

The Simple Case of A500 started with a request to automate a recipe generating function. For an example, the customer provided a copy of one recipe, you guessed it, A500. Bravely we marched off, returning a month later with the ability to automatically generate the recipe for A500!

Making a long story short, it turned out that A500 represented the simpler recipes in the class, and for extra enjoyment, the example they provided was the simplest of the simple. It took another 2 months (which means the project took 3 times longer than planned) to finally get the client what they REALLY wanted.

The take home lesson we learned, “Don’t accept a single example for requirements that cover a class.” We even referred to ensuing similar requests (from them and other clients) as “Oh yeah, it’s the simple case of A500.”

Ten years later, I’m still getting requests for “Don, do this, and here’s an example.” The current case started as “We need to be able to detect faulty thermocouples.” and a dataset that showed one of three thermocouples not working correctly.

Being older and wiser, I’m now working with the clients helping them understand that, “Yes, we can handle the request, but with a single example, I can’t ensure that we’ll handle a significant portion of the class, much less all the possible permutations that could arise.” It usually takes a lot more words, but so far I’ve been successful helping the clients understand the need for better requirements definition and examples.

Got an example of “The simple case of A500″? Send me an email.

In regard to “March 17, 2005 Blog Entry — Can Developers Test Software?” For me, your observations go back to the dynamic between verification and validation.

Verification

In my experience the developers have the verification mindset, “Does it do the job?” Most everyone who uses the software has the mindset, “Does it allow me to do my job?” And that is the essential difference. The job or requirements are dependent on what pair of glasses one wears. Developer, project manager, line manager, procurement official, program manager, and user all have different ideas about the software.

Validation

I hold the opinion that “doing the right job”, or validation, is much more important than “doing the job right”, or verification. Validation ultimately includes verification, but not the other way around. Unfortunately verification seems to be the tail that wags the dog, at least in government procurements and way too often in commercial procurements.

To me it seems that software craftsmen are not the only ones who do not look to the user. Jerry Weinberg in his QSM Vol 4, “Anticipating Change” quotes Witold Rybczynski:

“What did ‘getting it right’ mean in practice? To the classically trained architect it meant, first of all, pleasing the client or, in a broader sense, the user of the building (not always the same person). This unassuming, and to most persons obvious, requirement needs emphasizing in a period when architectural design has become a self-expressive pastime. The great Chef Carême said, ‘In matters of cookery there are not a number of principles, there is only one and that is to satisfy the person you are serving.’ If I were to quote his advice to my students, they would find it a hopelessly old-fashioned and intolerable imposition.”

Your comment, “A quick review of the most project dynamics indicates that everything can slip as far as delivery except the final ship date.” is only the beginning. I usually see final ship dates turn into the first of many unplanned ship dates, which begs the old question, “Why do we have time to do it over, but never the time to do it right the first time?”

Appreciations

I appreciate Charles for taking the time to read and respond!