Systems, Software and Solutions

We've Moved

Recently George Dinwiddie mentioned that some people may wonder why this blog has been so quite lately. Well, we've moved. I'm currently writing in two blogs:

An Alternate Reality
and
Systems Thinking

This blog is a place holder so anyone linking to the old articles won't have to change their links.

I appreciate George for pointing this oversight out to me.

The Only Constant is Change

And I've changed how and where I do my blogging. I've converted my web-site to a tiki-wiki based existence. I can now update my web-site from anywhere.

If you've arrived at this blog location by following a link from another site, please point your browser to my new blog area.. I'll "see" you there!

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

What's Your Point of View?

We recently pruned the fruit trees in the backyard. I did it by myself the previous time, and the results were, well, interesting. So this time we did some research, planned the event and waited for a cool spell. Karol would do the directing, and I would do the pruning.

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: 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

Seeing Forests and Trees

"If I had six hours to cut a tree, I'd spend the first four sharpening my axe." - Abraham Lincoln

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

The Software Cynic

I found the following in some notes from October 2000. I don't remember why I made the observations.

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: 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.

Now, What Is Change?

Re-reading my blog titles occasionally leads to interesting thoughts. Many titles mention change, and most entries have something to do with change. But after all these entries no one has asked me, "Don, what do you mean 'change'?". Until recently, I haven't asked me either.

It's understandable. We all know what change is. We've been involved with change all our lives. Thus we each have an idea what change means. However, as I mentioned earlier (Different But Useful), the map is not the territory. It's quite likely that your definition varies from mine. Like the air we breath, we don't notice it until something goes wrong.

So, what is change? Change is the transition in a system between two steady states.

Transitions requires time. Smaller less complex systems generally require less time to make transitions. As an independent consultant, I can implement changes much faster that Microsoft can. I don't have empirical data but I'd guess by the time I'm finished with a change, they'd still be discussing it.

Transitions also require energy. Some energy is required to move the system from its stable state. If an external event creates a life and death response in the system, this energy probably isn't hard to find. If the change "comes down from on high" and involves doing something differently (such as process improvement), the energy may not exist to get the transition started. Once the transition gets underway, more energy than normal gets expended as the system attempts to re-organize and find its new stable state.

Seem reasonable? Got a question or something to say? Let me know. don@donaldegray.com

So, What is a System?

I'm working backwards. I started this entry on defining change. Then I realized change can't exist without systems. So, what is a system? I like the following (heavily inspired by Systems Thinking Basics: From Concepts to Causal Loops)

Systems have several essential characteristics:

1. A system’s parts must all be present for the system to carry out its purpose optimally. If you can take components away from something without affecting its functioning and its relationships, then you have just a collection, not a system. A pile of quarters on the table would be a collection. The company for which you work is a system.
2. A system’s parts must be arranged in a specific way for the system to carry out its purpose. If the components of a collection can be combined in any random order, then they do not make up a system.
3. Systems have specific purposes within larger systems. To paraphrase, "It's systems all the way down." Your company, your department, your team, you, your various physical systems, and smaller the systems get until you reach the sub-cellular level.
4. Systems maintain their stability through fluctuations and adjustments. Systems achieve this stability through the interactions, feedback and adjustments that continually circulate among the system parts, and between the system and its environment. If a systems doesn't achieve stability, it generally doesn't last long enough to get noticed.
5. Systems have feedback. Feedback is the transmission and return of information. The most important feature of feedback is that it provides the catalyst for a change in behavior.

A system has feedback within itself. But because all systems are part of larger systems, a system also has feedback between itself and external systems.

Finally, feedback is not necessarily transmitted and returned through the same system component or even through the same system.

What would you add or change? Send me a note: don@donaldegray.com

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

Intake: Abstracting and Represenational Systems

We take in information from our environment in discrete steps. We abstract from the continuous data streams (aka "The Real World") in the following order:

1. Something happens (Event)
2. We sense what happens (Object)
3. We recognize what happens (Description)
4. We generate meanings for what happens (Inferences)

This pattern was first published in 1933 in Korzybski's Science and Sanity: An Introduction to Non-Aristotelian Systems and General Semantics. From these abstractions we create the parallel experience in our mind that allows us to recreate the experience. Here is a review of the abstracting process.

We get information from the "real world" via our senses: hearing, seeing, touching, tasting and smelling. As we experience our world, we tend to store the the event information in our memory in the same "sense" that we experienced. We can see what happened, we might hear a loved one's voice, or feel the chill in the air. I found this instrument a fun way to determine my preferred sensory intake channel. You can link to more information about Modalities and Representational Systems from the page. There are only 5 questions, so I wonder about how "accurate" the results are.

Like the MBTI, this way of looking at people's differences helps me understand myself more than tell me the "truth" about you.

What do you think? Drop me a note at don@donaldegray.com

Why Don't You Hear What I Mean? - The Satir Interaction Model

"Communication is a system of interaction. In some sense communication is always flawed because it is impossible simply to put one's thoughts and understandings directly into someone else's head." Bernard Mayer

Two recent events reminded me about the minefield called communication. A friend requested some feedback which I gladly provided. In fact, I thought I did a pretty good job! Based on the reply I received about the feedback, I knew what got heard, wasn't what I meant.

About the same time I was reviewing presentation material from a session I presented with Brian Pioreck at the AYE 2001 Conference titled "What’s Wrong With My Staff? How Management Style Affects Organization Potential." In it, we listed seven barriers to interpersonal communication. Since then I've added two more barriers. Right now the list contains the following items:

• Semantics
• Filtering
• Credibility of the sender
• Different frames of reference
• Value judgments
• Communications overload(ing)
• MBTI Type differences
• Intake modalities
• Bandwidth

So what happened in my feedback situation? First, the feedback happened via email, a very bandwidth constrained channel. I attempted humor anyway, which involved different reference frames. I know we have reasonably different MBTI preferences. Fortunately my credibility was sufficiently high that the other person chose not to ignore my feedback, but instead opened the opportunity for me to get some feedback on my feedback. We used the Satir Interaction Model to unravel the communication snarl.

The Satir Interaction Model

The Satir Interaction Model provides a framework to organize our thoughts about how communication occurs. The model looks like:



First, we take in information. This could be reading email, hearing words spoken, or any other activity where we notice something in our environment. Next we decide, "What does this mean?" Asking "What three different meanings could this have?" helps create a space so we have time to consider possible different meanings. And then "So what?" Is this of significance? If we feel the interaction is significant, we can choose to respond.

This simple representation suffices for most interactions. Jerry Weinberg covers the Satir Interaction Model in greater detail in Becoming A Technical Leader.

Got Something to Say?

How do you untangle messy communications?
What additional communication barriers can you think of?

Send me an email and let me know.

Problems with Systems Health

Can knowing how one system work help you understand how other similar systems work? Do software, project and physical health have much in common? I sent the following to Jerry Weinberg's SHAPE Forum.
This thread started as software health, and wandered through project health and personal health. What do they have in common?

Shiny and New!

First, when starting with a healthy (or new) system, generally no single event causes great problem. The problem comes as the effects of the events accumulate. The sum of the coding choices creates software difficult to understand and maintain. Projects get late one day at a time. New smokers don't get rushed to the emergency room with coronary or respiratory problems. This means we deal with chronic, not acute problems.

Local Optimization

Second, we tend to make local decisions in a global environment. Last week I spent two days helping the oldest son move, and another in the mountains with friends. All good decisions for THAT day. But the overall result was only making it to the gym one time. In the long run, I may have been better off to figure out how to get to the gym a couple of times. Maybe adding this member to the class isn't quite right, but it's quicker than creating a new class, and it's not THAT bad of a fit. And how about managers who would love to do process improvement, but they don't have time on this project. This is optimizing the sub-systems and having abysmal overall system performance.

Compensation
Third, systems compensate when trouble starts. Reporting doesn't change because "I can make up the time," or "A miracle will occur here." Management ignores risks because "they've never happened before." The body changes vascular constriction to increase (or decrease) blood pressure, or the heart beats faster to keep organs perfused. Eventually the system can no longer compensate, and collapses. When the system collapses, it leads to irreverseable shock. In general there are no great early indicators for shock since the system compensates for the problem. The best actions are to know what could cause the problem (shock), and start treating the problem before it manifests itself.

"The thought that disaster is unthinkable, leads to unthinkable disaster." The Titantic Effect (Jerry Weinberg)

The discussion wouldn't be complete without mentioning that denial of chronic problems creates emergencies. Perhaps this relates to the pain level. Someone with a compound fracture doesn't need convincing a problem exists. But someone with "heart burn that makes my left arm tingle" may not see the need to do anything since "it went away last time."