Systems, Software and Solutions

Point of View - From Another View Point

I found more information on view points. These are referred to in NLP as Perceptual Positions.

Self

The normal and healthy position of seeing, hearing, and feeling from out of self. This position is needed in order to speak with authenticity, to present yourself, your thoughts, feelings and responses congruently, to disclose, listen, inquire and be present with another.

When Stuck here: Selfish, sociopath perspective.

Other

To understand, feel with, experience empathy for and see things from another's view point. Here you'll feel in accord with the other and have a strong sense of his or her perceptive.

When stuck here: co-dependent.

Meta

To step back, gain a sense of distance, observe, witness, feel neutral, and appreciated both positions fully.

When stuck here: cold, over-rational, "computer" mode.

System

To understand the contexts (cultural, linguistic, business, family, etc.) that influence all of the larger systems and contexts of our world.

When stuck here: "Company Man"

Universality

This speaks to viewing from the individual's position of highest power. For the religious minded, it is to be present with God viewing the situation from His position.

When stuck here: "So heavenly minded you are no earthly good."

Truth in Blogging

These definitions are from the Meta-NLP training manual, page 80. I appreciate Bobby Bodenhamer and Mike Davis for sharing this information with me.

Context Switching - The "hardware view"

I met George Dinwiddie so long ago, CompuServe ruled the online world. We participated in the Software Development Forum. He recently added to the context switching discussion. You can read George's thoughts here. In it he states "This [hardware interrupt handling] is a very efficient and deterministic process. People, unfortunately, can have a little more trouble making such a context switch and then switching back."

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 for Fun and Profit

I recently read Johanna Rothman's article on Context Switching. I need to let you, it just ain't so.

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: don@donaldegray.com

We have met the enemy

I just about finished the next blog post. The entry had everything. Marvelous content. Humor. Natural seques. I was to the last paragraph and decided to flip from HTML mode to Preview mode. I noticed I forgot to close a "b" with a "/b" making most of the text bold. I decided to fix it.

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 at don@donaldegray.com

Famer Meditation

At one time, where I live in North Carolina was within 2 hours of 5 different NASCAR race tracks. Since I'm not originally "from around here", I summarize NASCAR as "A bunch of good ol' boys. Drive fast. Turn left." The locals tend to have a different view, so I usually keep mine to myself. However I have borrowed the "turn left" for my benefit.

See, I have a basic problem. When I meditate, get comfy, and calm my mind, I fall asleep. While this is restful, I don't seem to do much undirected thinking. I needed to find an activity that required me to stay awake, but didn't require a lot of "brain power" to execute. I developed an activity I refer to as Farmer Meditation.

In a nut shell, Farmer Meditation involves "going slow and turning left." To do this I attach the bush hog to the tractor, head out back, and find a field that needs bush hogging. A bush hog is basically a 6 foot wide mower that will mow just about anything, including small trees. My operating philosophy is: If I can drive the tractor over it, the bush hog will eat it. You can see the basic equipment here. At full "hogging speed ahead", I'm traveling just under 8 MPH.

This activity minimally occupies my conscious mind, leaving plenty of processing power for the unconscious mind to wander where it will, and ease the information into consciousness. I keep 3x5 note cards and a pen in my zip pocket. When I notice something I want to remember, I stop the tractor and make notes.

How do you stay awake while meditating? Drop me a note: don@donaldegray.com

It Looks Good From Here

I went on a kayaking trip with some friends. We stopped and looked at the first rapid on the first river from the bridge. I distinctly remember saying, "It looks good from here." And it did. What I didn't see was around the corner. The river bed narrowed, the rocks got closer together, and paddling became, well, much more interesting.

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 themself.
• 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.

Single Point Requirements

The "Simple Case of A500" occurred 10 years ago. I'm currently coding the "Son of A500". Completely different companies, completely different products, a decade apart. I'm the only common factor. And even I'm different.

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 to don@donaldegray.com

Different but Useful

"A map is not the territory it represents, but if correct, it has a similar structure to the territory, which accounts for its usefulness." - Alfred Korzybski

Recently I spent two weeks in Berkeley CA helping a client upgrade one of their control systems. I wasn't involved in creating the original system, but I do have experience with the software. We reverse engineered and re-created the system. Testing went well until the fateful day we hit the wall.

The task is simple enough. The operator makes a selection, which sets a boolean value TRUE. The control computer detects the FALSE-to-TRUE transition, and sets a local variable to TRUE. Six seconds later, the operator's value gets set to FALSE. The value in the control computer remains TRUE until other events occur that set the variable to FALSE.

This was the map I used until things didn't work. The communication between the two computers wasn't happening like it did with the original system. The original communication protocol worked synchronously. The new communication protocol works asynchronously. This didn't matter for most actions, but did create problems with this particular code section. And while we could bend, fold, and mutilate everything on the operator's computer, we couldn't make any changes on the control computer. To make matters more interesting, the interface logic occasionally worked. So my map was sometimes correct, and sometimes wrong!

After a day of testing, re-coding, and testing again, we finally resolved the issue so the interface reliably worked. The actual code changes were simple. We spent the majority of the day deciding if the map was correct and the territory wrong, or the territory was correct and the map needed changing.

Maps make it easier for us to work with the real world (whatever that may be). Some detailed information gets removed, but if the structure is similar to the territory, the map is useful. The problem is deciding when and how to change maps.

Giving Up - Reframed

On your blog of Thursday, September 01, 2005 "Giving up to get ahead" you talk about moving insurance agents. I've just been through the process of 'firing' my accountant of near 10 years.

She hasn't served me well for a number of years and done some things that have severely impacted me - instead of a $7,500 tax refund, I got a $3,000 bill (because they got a $15,000 donation wrong) and I was given a bill for $2,000 with a single line itemisation "professional services"...

Not entirely dissimilar to your insurance agent.

What's the pattern/anti-pattern here??

Loyalty + Outsourcing. (I reckon :-) )

As a small sole-practitioner, I need to outsource many things - normally you'd think of large organisations outsourcing, but I suspect that small business are the major outsourcers. There are a bunch of things that I have to hire 'professionals' to do - down to having a mechanic for my car, an accountant, insurance agent, employment agency, lawyer, bank, ....

I need to focus on my business, what I do well, and hand off to others things that are peripheral and I don't have the time, inclination, training and possibly aptitude to do well enough, or maybe be sufficiently expert in... I can afford to pay a premium for those services (in terms of hourly rate) because (apart from the recruiters) I only use them occasionally and the total impact on my budget is small. It's like building a pipeline - the straight bits of plain pipe are commodity items and priced accordingly, the tricky bits - bends, joins, valves - are a very small but important part of the pipeline. There aren't too many people that can do this stuff and they can charge a premium. It has to be right, it has to be on-time and it's under 1% of the total contract (a guess).

So back to my accountant. I selected her by asking friends for references. We got on well enough and the price/service was acceptable. Then it was a 'handled' problem - I'd outsourced the work and it just kept ticking over - no decisions required. It's not laziness, but prioritisation, like cleaning that attic, basement or garage out. Things will keep running just fine unless there is an emergency like a fire, flood or a relative moving in. When people die, others get to look at the things they've 'deferred' dealing with - and it looks like a complete mess and a hopeless tangle of junk... But they lived just fine that way. [In Australia, farmers build another shed to store stuff. These are amazing places to find old & sometimes valuable things. "Clearance Sales", when the *entire* contents of a farm are sold by auction in one day are quite some fun.]

And I'm pretty loyal as well. That's a pattern that usually works well for me personally and professionally.

Finally, I'd reframe your blog question from "What's the anti-pattern", to "When does a useful pattern become an anti-pattern?"

Having a single insurance agent you "just go to" is a very useful pattern - until they screw up or screw you around. Then you have to go through the pain of finding someone new... It's trivially obvious that doing a through & exhaustive evaluation of *all* suppliers in the marketplace for *every* purchase/service is a waste of time - especially for micro- and small-business where you have very limited internal resources. And, if you work out the opportunity cost, the money saved each time will be much less than you could've earned with that time... Guess that's why bigger organisations tender for goods & services - but only for a limited time. Take the hit on selecting someone - the pain, time and cost - and then reap the benefits of a single supplier. At least with a contract, you schedule when you're going to reconsider a relationship.

Remember in PSL the lesson of "success leading to failure"?? Early success leads to a 'lock-in' of the solution method. Mostly the method doesn't scale, but it's always worked for you, so you have to stick with it until it fails catastrophically. Hopefully, you're still around to be able to rechoose.

Stephen Jenkin, Australia

Giving up to get ahead

Insanity: doing the same thing over and over again and expecting different results.
Albert Einstein.

In my years in "da biddness", I've seen people time, and time, and time again do the same thing, and wonder why it didn't work. And when what they were doing didn't work, they would do it again, and marvel that once again, their actions didn't return the results they hoped for.

I'd like to say that I never do this, but recently ... I'd been working with my insurance company to get some special coverage I needed for working with one of my clients. I had this coverage in the past, so I didn't think it would be a big deal. After a week of them stringing me along, and me placating the client, I finally gave up. I started looking else where, and in a half hour located the insurance I needed for less than half the cost my insurance company was quoting ... IF THEY COULD INSURE ME.

Why did I wait so long to look for other options? What process what I using? What antiprocess was working against me?

Got examples of antiprocess in action? Drop me a line at don@donaldegray.com

Developers Testing Software, Take 2

Charles Adams quantum6013ATcox.net had the following comments about developers testing software.

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!

Can Developers Test Software?

The Pacific Northwest AYE Community members gathered on 3/6 in Seattle. The group, split between developers and testers discussed the recent phenomenon of using developers to do testing.

It Only Makes Sense

After all, developers have always done some testing.

• Does the code compile?
• Does the project still build?
• Does the new code do what it should?

Great! What's next on the list of things to do?

Agile methods promote test driven development. The testing plan gets written before the code does. Management is simply proposing the logical result. Fire the testers since the developers are now doing the testing! But does this really make sense?

You Mean There's More To Testing?

Yes, Virginia, there's more to testing. I'm a developer, not a tester. I know only a little bit about testing, but I DO know that testing methodologies move just about as fast as development methodologies do. It's no longer just about white boxes and black boxes. Check out Quardev and Satisfice for some great ideas in testing. Developers are lucky if they have the resources (time and training) to stay current with new development concepts. What are the odds management will think to include resources for learning how to test?

The View From Over Here

Another point to consider: Developers and testers have different local and global view points. The goal of development is to create and prove software works. Testing tries to discover those conditions where the software doesn't work. Two very different ways of looking at the software. Shannon Severance does both developing and testing, but never on the same project. Once you get a particular view point on a piece of software, it's hard to switch to another viewpoint. The difference in view points leads to better software.

Slip Sliding Away

Given that developers like to develop, not test, how does having developers do testing impact testing time? A quick review of the most project dynamics indicates that everthing can slip as far as delivery except the final ship date. Software development requires discovering what features should be coded, figuring out how to code them, coding them, testing the code and delivering the software. Testing time gets compressed in most projects to the time left (if any) after the major development is completed and the scheduled delivery date. With developers doing the testing, time (if any) will naturally shift to development to squeeze in "one more feature." After all, "I've been testing as I go along."

A Tester, By Any Other Name

Any significant software project involves multiple development teams. Who tests the overall results? Designate a developer to handle this release's integration testing? Doesn't that make them a defacto tester? And an unhappy one at that. Developers don't have the mindset, training, and knowledge to do a good testing job. Why force this on them? Good software needs multiple viewpoints (after all, pair programming is basically instantaneous code reviews). Why not get the view point of some one who wants to do the job?

Let's Think About This Some More

Firing the testers and using developers to test is a Siren's song. Do it long enough, and you'll hear sirens again as the software crashes and burns on your former customers computers.

All Problems Are Not Equal

Head Down and Headed for Cover

I'm an adrenalin junky. I keep agreeing to work with projects in trouble with incredible time pressure. Last Wednesday I agreed to help a project that HAD to be completed by Friday. The team was scheduled to fly home. We made good progress on Wednesday. Thursday we were supposed to clean up the loose ends, buff the application, and make a presentation to the "suits". That was the theory.

I arrived early Thursday morning to get a running start. The team was scurrying trying to figure out what went wrong. Jenny told me "This isn't a good time to make changes. The robots aren't working." She was already gone by the time I started asking what she wanted me to do.

Rudy's Rutabaga Rule

Our physiology allows us to only feel one pain at a time. What hurts most, gets attention. Lesser pains get masked until the current pain goes away. When the current greatest pain goes away, what was the second greatest pain surfaces and we deal with it.

Rudy's Rutabaga Rule¹ reframes this into problem solving.



Until Jenny solved the bigger problem, tidying loose ends and application buffing just wasn't going to happen. And I'm OK with that. Eventually, we'd handle the ends and buffing.

Ain't My Problem

Problem solving with people involves separating their problems from my problems. A list of other things to consider:²

• The Pause Principle
• The Pay Attention Principle
• The Partnership Principle
• The Passion Principle
• The Person Principle

All's Well That Ends Well

The presentation happened late Friday morning. The team flew home to Germany on time, and I'm still an adrenalin junky.

¹Weinberg, G.M., The Secrets of Consulting. 1986, New York: Dorset House Publishing, p15.
²Solving Other People's Problems

Context is everything

Today I had the opportunity to remember that "context is everything". Hurricane Frances continues her slow crawl up the eastern United States. It started raining here in North Carolina yesterday (Tuesday 2004.09.07). This morning my radio crackled with reports of accidents and emergencies. Fortunately, none were in our response area. Then the pager tones sounded. "Squad 86 respond with the local VFD to a one car roll over. One adult and two children confirmed entrapped."

I arrived just before the rescue truck. The SUV lay on its side in the ditch. The VFD had already set up traffic control and fire suppression. Using standard rescue techniques and tools, "Mom" and the kids shortly walked out of the SUV. Other than needing to by a new vehicle, this story ends happily. But what happened? The Highway Patrol report will include some phrase like "too fast for existing conditions". "Mom" has probably drven this road most of her life. It's rained before while "Mom" was driving. But today the amount of rain, the wash over the road and her speed created a new context that "Mom" couldn't cope with successfully.


Like this accident most "interesting events" happen because someone, somewhere, at sometime, loses track of the context. Context involves us and everything we're connected to. "Involves us" includes our mental models, our world view, and our actions. We started changing at conception. We continue to change until after we die. Along the way, we grow, we learn, we change. Accidents happen when we change, but the "everything else" hasn't. Learning may create an accident that leads to personal growth. Personal growth might make us uneasy with our current friends.


"Everything we're connected to" is the environment we exist in. Our family, our friends, our career, our hobbies, everything with which we come in contact is in a state of flux. If our world view limits how we see things, we'll create accidents by missing opportunities or reacting to things that aren't there. If we hold to mental models that no longer apply to our current situation, we'll be out of context when we act. Behaving like a 10 year old doesn't work well now that I'm pushing 50.


We need to learn from accidents. Learn about ourselves, our context, how they interact, and how to keep them synchronized.