One task which many of us either choose or have thrust upon us is predicting the future. We usually perform this task poorly. An aid to declaring “the future will be thus” is reframing with a few introductory words.

The future will be awful.

There is no way out of this. We are doomed.

We will run out of oil reserves before 1995.

I have heard these and countless other predictions of the future. The third quote came from a fellow grad student in 1985. He had worked several summers for oil companies and had seen inside information on oil reserves. He had inside information; he knew we would run out of oil. He was buying bicycles and parts now while they were cheap because once 1995 came around bicycles would replace cars and cost tens of thousands of dollars.

As a systems engineer and sometime project manager, I predict the future daily. I tell people that our system under construction will be:

• Three weeks late
• On time
• A day early

And so on and on, all variations of

The future will be thus.

I wish people would insert a phrase in front of the future will be thus. Change it to

Unless something happens, and something often happens, the future will be thus.

I know this has more words, takes longer to say, longer to type, and sounds like your are “hedging your bets” and every other bad indecisive quality we can imagine, but it is much more accurate.

My fellow grad student’s prediction from 1985 would have been

Unless we find more oil reserves, and people have been finding more oil reserves for a hundred years now, we will run out of oil reserves before 1995.

Many of today’s predictions of gloom can be reframed.

Unless we have a breakthrough in battery technology, and breakthroughs happen, hybrid cars will not be practical.

Unless we make gasoline engines more efficient, and efficiency improvements often occur, we will all have to drive hybrids.

Unless we have some true leaders in Washington, and such leaders come around every generation or so, we will never get out of our financial mess.

The last reframe above is the least likely, and unless we beat all the odds, and we tend to beat all the odds now and then, we may be in trouble.

Just a thought on health insurance from an engineer.

I see that President Obama doesn’t like what existing health insurance companies are doing with their rates and policies. It seems that the president wants health insurance companies to be non-profit and insure everyone regardless of pre-existing conditions.

Health insurance seems to be a pretty simple concept (at least from the perspective of a little-knowing engineer).

• A group of people pay into a fund.
• When someone is sick, money is pulled from the fund to pay the bill.
• If a lot of people become sick in one year, everyone has to pay more into the fund to cover the expenses.
• If few people become sick in one year, fewer funds are withdrawn from the fund and people don’t have to pay as much that year.
• There are expenses to managing the fund and collecting the contributions.
• A non-profit health insurance group manages the money closely so that money in equals money out.
• A good non-profit health insurance group operates efficiently by employing smart, well-meaning people and keeps costs really low.

I think it is legal to start such a non-profit health insurance company. A good, efficient non-profit health insurance company would offer better and less expensive services than the existing for-profit companies and people would flock to it.

Perhaps President Obama could start such a non-profit health insurance company himself. At least he could use his position of influence and leadership to inspire others to start such non-profit health insurance companies. Pardon my ignorance, but I think that is what a President of these United States should do - state his beliefs and inspire others to follow those beliefs.

History shows us that it is incredibly difficult to pass legislation that requires people to be good. There are also many unintended consequences of such laws. Just a thought.

I invite comments on this thought. Perhaps the discussion can lead to someone beneficial.

I have always been driven by setting and achieving goals - big goals. Recently, however, I have learned the value of setting a minimum expectation for any endeavor. That minimum removes much of the stress that I have imposed on myself for much of my life.

Back in December, we were attempting to drive from our home in Northern Virginia to Louisiana to visit family for the holidays. We drove into a snowstorm and spent a night parked in a gas station next to the Interstate (for more on that adventure, see here). It wasn’t much fun, but we were fine.

The surprise for me was that I  wasn’t upset. I would normally be fuming every minute of the wait. Think of all the time we were wasting! A couple of months of perspective has helped me to learn why I wasn’t upset:

I had a minimum expectation for the trip, and we were beating that.

We left home on a Friday. We absolutely had to be at the New Orleans airport the next Tuesday morning to meet someone. That was the minimal expectation. If we arrived in Louisiana any time before Tuesday, we would be fine. We arrived in Louisiana at 1:30 AM Sunday, beating the minimum by more than 48  hours. All was fine.

Some thought, and this concept of the minimum expectation can be applied to most endeavors. Some examples:

1. I start writing a book, minimum expectation of sales is zero.
2. I look for a new job, minimum expectation is no job.
3. I send someone an email, minimum expectation is no reply.
4. I start any new endeavor, minimum expectation is that I learn at least one thing.

Consider example 1. When I start writing a book, the effort is a success if I finish writing the book. Any sales are a bonus. Upon further consideration, if I write one chapter or one page or one sentence, that is a success in that I have written more than if I never started.

That leads me to example 4. I can consider any endeavor a success as long as I learn at least one thing. All else is extra - a bonus.

Setting minimum expectations is hard for some of us - especially me. I have always accomplished much in my life. Setting big goals and reaching them is a way a life.  Retreating from that is…well it is not good. Perhaps, however, I have learned a few things along the way that help me to accept minimum expectations.

The odd thing about accepting a lesser goal is that life is easier. I sleep better; I am happier, and people around me don’t have to put up with an obsessed person.

Another thing about minimum expectations - they affect decisions. The minimum expectation was to reach Louisiana by Tuesday morning. Any accident would mean not reaching that expectation. We decided to stop and wait and wait and wait. Moving forward into the snow in the dark would have incurred unnecessary risk. That was a good decision.

I experimented with using a wiki to gather and trace requirements. I tried the MediaWiki software. While it works well for building a flow down of requirements, it is not good at placing the individual requirements into a single Word document.

A systems engineering project is looming at work. We don’t have a commercial requirements documentation and tracing product here. In the past, we have used Office software such as Word and Excel. One of the things I have heard people use is a wiki.

So, I tried an experiment - how would a wiki work for requirements documentation and tracing?

The short answer: pretty well, but not great.

The long answer follows.

I downloaded the MediaWiki software from this site. This is the software that runs Wikipedia and a large number of lesser known wikis on the Internet. I had used this before at work and at home, so I was familiar with the syntax and other features.

To run MediWiki requires an Apache server, MySQL, and PHP. Since I was running on a Windows XP system, I downloaded and installed Z-WAMP from this site. Okay, everything downloaded, installed, and MediaWIki is running fine.

I started a little set of requirements using the classic top-down approach. A system (0.0 System) has two subsystems (1.0 Subsystem One and 2.0 Subsystem Two) and each subsystem has several types of requirements in several components. I quickly became lost and frustrated.

Scrap it and start over.

This time I just entered requirements as they came to my head. Each requirement had a simple structure of:

• Content
• Parent
• Child

What I didn’t know at the time, I left blank. I used the Category feature of MediaWiki to create tags. For example, each requirement that didn’t yet have a parent was given a “Category: No Parent.” Clicking on “No Parent” at the bottom of a page showed me all requirements that didn’t have any parents. That let me know where I needed to work, places where I needed to enter parents and build the requirements flow down.

In the same manner, I could click on “No Child” and see parts of the flow down that went no where. Again, that was a place to go to work.

WikiMedia is a good tool for building a flow down. Using the Categories as tags, you can easily see the holes in your flow down.

Now for the not-so-good news for MediaWiki. I couldn’t think of a good way to move the requirements from many pages to one document. Our customer likes to see one printed document in their hands. The only method that comes to mind is to visit each requirement page, copy the text, and paste it into a single Word document. That is a pain; it is slow, and it is error prone.

A little more good news for MediaWiki. If I have a team of engineers working together, they can each enter requirements on individual wiki pages. A systems engineer would have to go through these pages and use tags to create a flow down. This is a much faster way of gathering and documenting requirements than taking turns editing a single Word document. There would be a little learning curve, but we could work with that.

Conclusion:

A Wiki is an acceptable tool for documenting and tracing requirements. If I could find a wiki tool that would quickly collapse into a single Word document, I would use it.

We often give power and control to our surroundings. This change of words returns those to me.

I have heard it many times and said it a few times. Things like:

I am under a lot of stress.

This is a stressful situation.

The stress here is too much.

Let’s look at the second statement a little closer and try to reframe it.

This is a stressful situation.

Try a reframe like:

I am distressed (or grieved or perplexed or anxious or some other adjective that fits for you).

The first statement gives all power and might to the situation. It is stressful. It has its hold on me. It cannot be stopped.

The second statement is about myself. I am feeling a negative something that I would rather not be feeling.

I prefer the second. In the reframe, the feelings are mine. I can do something to change the way I feel. I can do nothing and keep the feeling. The choice and the power to choose are mine, hence the control is mine.

The reframe has taken me from the situation is all powerful to I am all powerful. I like the latter much better.

I now have a computer in the kitchen that runs Windows 7 and Fedora. If HP would just update their printer driver…

I have finally upgraded my kitchen computer to Windows 7. This machine now is dual boot-able with Windows 7 and Fedora 11 (see this old post for the background). I am running Windows 7 Professional 64-bit edition. Wow, now I can write emails in 64 bits. I kid as there must certainly be some advantage to 64 bits.

The Windows 7 install was easy. After backing up data files, the install only took half an hour. Then, as they say, the fun began.

The troublesome part was the same as the troublesome part with Fedora 11 - my HP PSC 2510 Photosmart All-in-one printer. This printer is five or six or seven years old. The trouble is that it works better now than it did way back when (firmware and software upgrades are a marvel). Why should I throw it away or give it away or put it away or fill-in-the-blank it away? The answer is that HP wants me to buy a new printer. I understand their reasoning. I don’t like their reasoning, but I understand it.

I knew the trouble was coming. A colleague recently upgraded to Windows 7 and had trouble with printer drivers. He tossed his old printer and bought a new one. His experience caused me to look for drivers for my printer that would work with Windows 7. I learned of HP’s decision not to update their drivers. I also learned of a work around.

I told the computer that I had an HP PSC 1600 Series printer. That is close enough to my old model that I can print via WiFi just fine. I cannot scan, but I can print. That is good enough for the kitchen computer. I can scan from the other Windows XP, Windows Vista, and OS X computers that make their way through my house from time to time. Strange how we lie to our computers to get them to work. Maybe that is a topic for another post…

Engineers create wonderful things now and then. Oblivious users turn the creations upside down and use them backwards. Such oblivious use teaches great lessons that smart organizations use before going to production.

Engineers have their babies. Not the human kind of baby, though some engineers have those, too, but the system-that-they-create kind of baby. It is their newly finished computer program or piece of hardware or even a design that is still on paper. It is the thing they created; their pride and joy.

Engineers use their babies with great tenderness and care. The engineers know just how to use the baby; they know just what it is for. They use the baby for only the right reason and only in the right circumstance.

Their baby works just as desired in just the right situations. There are no flaws in their baby; there are no surprises, and no hidden uses.

Engineers convince the managers and marketers of the world of the great worth of their babies. They hold the baby just right and show these others how their baby works. Often, the marketers and managers of the world approve of the baby, fund it, produce it, and send copies of the baby out into the world.

Let’s review this procedure:

1. Engineer creates the baby
2. Engineer shows the baby to managers and marketers
3. The baby is approved
4. Copies of the baby are sent out into the world into the hands of oblivious users

Maybe we should alter and rearrange the steps in this procedure:

1. Engineer creates the baby
2. Engineer shows the baby to managers and marketers
3. The baby is approved to a lesser degree
4. Limited copies of the baby are put into the hands of oblivious users
5. Everyone reconsiders

Oblivious users do strange things to the engineer’s baby, things like:

• hold it upside down
• try to use it backwards
• toss it into the back of a pickup truck
• spill coffee on it
• rest their elbow on it
• drop it
• kick it
• drop it and kick it at the same time

The engineer never intended for anyone to do any of these things to their baby. These people obviously don’t know anything about the baby and what to do with it. There is a reason why I call these people oblivious users.

Oblivious users are the genius of ingenious managers and marketers. The oblivious users don’t love the baby they way the creator engineer does. They just know the thing is there and they try to use it. They have lots of other things on their minds. They are just like the millions of people out their in the world who will try to use just about any old product that comes on the market.

Naive organizations use the first procedure given above. Smart organizations use the second procedure from above. Smart organizations take the baby away from the engineer as soon as they can so they can all learn something about the baby. They learn things that the creator engineer would never know because he is too busy caring for his baby.

The source for all this is the MoinMoin site. I downloaded the 1.9 release from their download page. This docs page explains how to install everything. I used the one-minute install version (no server). It worked.

One caveat - youneed Python installed on the computer. I already had that and was mildly surprised that everything worked as it should. If you don’t have the Python software on your machine, the MoinMoin download page has links and instructions.

I am experimenting with MoinMoin to see if would work as a requirements management or RVTM (Requirements Verification Traceability Matrix) tool on an upcoming project.

When faced with a situation on a system-building project, we can find an approach that will work. We can also find many other approaches. Do we choose the better approach or one we personally like?

Several years ago, a professional soccer player spent a few afternoons helping to coach one of my son’s soccer teams. He emphasized moving the ball from player to player. The ultimate goal was to pass the ball to a position where we could score. If that were not happening, moving the ball about the field kept the other team moving which made them uncomfortable and often led to them being disorganized.

One thing he told the kids over and over was, “Make the easiest pass.”

The easiest pass kept the ball moving safely. We maintained control of the ball and control of the game.

This “easiest pass” concept  led to two and  a half questions:

1. What is the easiest pass to make?
2. What pass did I make?

If the answers to questions 1. and 2. are not the same we come to the next half question, why aren’t they? If I am not making the easiest pass, why am I making the pass that I make? What appeals to me about the more difficult pass?

Now let’s move from kid’s soccer to adult projects:

Given a situation on any day of a project and given that I know the direction I want to go,

1. What is the easiest thing to do that moves me in the right direction?
2. What do I do?

If the answers to questions 1. and 2. are not the same, why aren’t they? I mean, if I know what I want to accomplish, why wouldn’t I choose the easiest path to that accomplishment?

For example, I want to organize a group of people so that we are all working to preserve the integrity of the system we are building. Let’s all move in the same direction instead of every which way. One of the easier things to do is write and follow a configuration management plan.

“Yuck, who wants to do that? Write and follow a plan? Let’s just stay in touch and watch out for any loose cannons running around the halls messing things up.”

So here we are. We know the easier thing, but we do something else instead. There can be many reasons why we go away from the easier thing, and some of those reasons are good. Most reasons for contrary behavior, however, are not constructive. We avoid the easier thing simply because we don’t like it. We find a justification for doing what we like instead of doing what makes more sense.

This is part of the human condition. Given a choice, we usually select what we like, what fits our personality, instead of what has a better chance of working. Ooops, that word just came into the essay - working. If I am doing a hobby project at home, I do what I like. It is a hobby; it is my own time, and I am free to do what I like. If, however, I am at work, being paid by someone, and have my job and the jobs of other people on the line, I should do what makes more sense. The answers to questions 1. and 2. had better match.

We use process on projects. Aargh, process can be irritating and it can be precious.

We are still snowed in here in the Northern Virginia suburbs of Washington D.C. The main roads are clear now, but six to eight inches of snow remain in my yard. Most of us here are sick of the white stuff and sick of talking about it, but then again I am a writer and this is good material.

One of the results of snow on the ground is snow and ice in the parking lots. You can’t see throw dirty snow and ice. Hence, you can’t see lines in the parking lot. You know, those irritating white lines that corral you into tight spaces. Just try driving a van around grocery-store parking lots - a van that has a restricted turning radius, i.e. you can’t turn it sharp enough to squeeze into a parking space without backing up a couple of times.

The  one thing worse than those lines is when those lines disappear under the snow.

A parking lot loses half its capacity when the lines disappear.

That conclusion isn’t from detailed scientific measurement and analysis. It is merely my perception after circling snow-cluttered parking lots in anguish looking for a place to park. Anguish erases irritation; I miss those precious lines.

Those parking lot lines are like procedures, checklists, templates and all other sorts of tools we use on projects. Yes, the dreaded word “process” is related to those sometimes irritating and sometimes precious parking lot lines.

Some processes save half our time and effort on projects. Some processes waste half our time and effort on projects. Reasonable processes are good while unreasonable ones are bad. The trouble is that “reasonable” and “unreasonable” are subjective words. Their meaning varies from person to person. And just like those parking lot lines, the meaning of those words varies with my mood.

Here is a rule of thumb regarding process:

If two people can do everything on a project, just do it. Otherwise use some checklists, templates, procedures, and process.

Of course my rule of thumb regarding process is itself a process. Hmm, can’t seem to break free from those irritating parking lot lines.