Working Up

by Dwayne Phillips

Simple yet oft-forgotten principles: commit to only what I can control. If I commit to things that are outside my control, I am assuming risk.

I ran into the situation recently There are many times in my life when I am surprised to find people doing things that go against time-proven principles. I should get over these surprises.

Commitment: I was do such-and-such by such-a-date. It is important to meet my commitments. If I don’t, people will label me as unreliable, undependable, and just maybe a big fat liar.

To avoid these labels, I should only commit to things that are outside my control. For example,

I will be at the coffee shop at 8AM tomorrow.

I can control almost everything related to that. Yes, if traffic is snarled, I won’t make it on time. If someone hits my car, I won’t make it. If I wake with the flu, I won’t make it. Those events, however, have a low probability of occurring and they are largely in my control.

Risk: Try this example,

I will have coffee with you in the coffee shop at 8AM tomorrow.

This assumes that the coffee shop will be open as advertised tomorrow. They coffee shop probably will be open tomorrow, but I have no control over that.

This second commitment causes me to assume risk. Something can go wrong (the coffee shop doesn’t open), and that possible bad situation is a risk.

Am I willing to assume that risk? If the coffee shop doesn’t open, I could be labeled as unreliable, undependable, and just maybe a big fat liar. Am I willing to stake my reputation on the reliability of the coffee shop?

by Dwayne Phillips

I still learn new things. I still want to learn new things.

I recently learned how to make the em dash and en dash characters in OS X with keyboard shortcuts. I no longer have to go to the “insert symbols” function to insert these special characters.

One of the disappointing results of this is that I have yet to find anyone who cares about the em dash or en dash or recognizes any value in them.

There are, however, more encouraging results to report. One is that I never knew how to do this before. Now I know and I can complete my writing in less time than before. Hence, I have improved one aspect of my writing. As I consider that, I can denote aspects of my writing that I have improved each of the last thirty years.

There are (at least) two consequences of this experience:

1. Don’t wait until you know how to do it all correctly before trying to do it.
2. Don’t settle for what you now know.

A third consequence is that when I meet someone who doesn’t know how to make the em dash with keyboard shortcuts, I remind myself that there was a time, and that time lasted for decades, when I didn’t know how to do that either.

by Dwayne Phillips

A change in the behavior of a system means that someone has changed something. We as people, often love to ignore this.

Here is a situation I experienced a few years ago in a digital signal processing laboratory. One day, a piece of software didn’t work. A user ran the software, and the software stalled in a state so that the process had to be killed by a system administrator.

Someone investigated the problem. They found that if they changed one line of code, the software would no longer stall. The error was corrected.

A skeptic, (those skeptics can be a pain, but we must have skeptics about to keep us honest) was upset with the “fix.”

“That line of code was the way it was for ten years,” chided the skeptic. “The software never stalled before.”

The skeptic was correct. The problem, whatever it was, was not in the software. Yet, changing the one line of code did fix the problem. The skeptic, however, was unable to convince anyone of his thought. Given some twenty years of consideration on my part, here is the convincing:

Something had changed to “break” the software. That errant line of code had been present for ten years and had never caused a problem. Now, all of a sudden, out of the blue (toss in any other cliches you know), that line of code was incorrect(?).

Some possibilities:

1. The data the user ran on the software caused something that had never occurred before.
2. The operating system of the computer had changed in a way so that the line of code damaged the operating system.
3. There were too many people running too many programs with too much data on the computer. That new situation caused the software to stall.

Given time, I could create other possibilities.

What did we do? We kept the change in the one line of code. After all, the software did run correctly after the change. We did not investigate any other change possibilities. After all, the we had too many other things to do that day. We never knew what really caused the software to “break.”

Still, I must go back to the italics statement earlier. The software worked one day and was broken the next day. Something changed, else the software’s behavior would not have changed. Practical considerations, e.g., time, money, headaches, etc., pushed us on to other things.

by Dwayne Phillips

Any change to a situation will change the situation. It is often difficult to discern which came first.

When a new person walks into an existing group of people, that group changes. There is no way around this—at least I know of no way around it. To have a new person without change, I would have to find a person who is exactly like the persons who are already here. I don’t know how to find such an exact match in a person.

In a reverse, round-about way, a change in a situation means that someone has changed something. For example, several years ago I was part of a group of cars driving to a soccer game. One person’s car did not start. The car worked fine two days before. One day before, the car was in an auto shop where they “did something.” Of course, the fault in the car was caused by the auto shop.

That car problem was easy to diagnose as there had only been one change made to the car, and that change happened one day earlier.

One day we notice that an organization of a hundred people is different. What was the change that brought the difference? I don’t know how to discover the answer as there are too many people and too many days and too much that could change. (I can easily find persons who “know” what change brought about the organization’s change. I quickly dismiss those people as being overly optimistic in their powers of observation.)

So, write this down:

(A) If a situation has changed, it is because someone changed it.

Also, write this one down:

(B) If you want a situation to change, change something.

If you know someone who can always find the one little change that will lead to the desired big change (from (B) above), please introduce that person to me. I really need them.

by Dwayne Phillips

If you want time alone to think, do something distasteful to your colleagues. They will leave you alone.

A few years ago I was in a job where we had a small refrigerator of soft drinks in the office. One thing that comes from such is that someone has to refill the refrigerator—almost daily in our case. I found myself often doing this.

I can be overly conscientious at times (a birth defect). Instead of putting warm soft drinks into the front of the fridge, I would pull the few cold drinks out of the fridge, put warm drinks in the back, and put the cold ones in the front. That way, if someone bought a drink, they would have a cold one. This little stocking exercise took ten or fifteen minutes a day.

I noticed something: no one spoke to me while I was doing it.

It seemed that they were embarrassed to see me doing the menial task while they wandered about doing nothing.

I looked forward to this stocking exercise everyday. I could move the drinks about quietly and think about my job. No one interrupted me. It was the only uninterrupted thinking time of the day. Wonderful.

I mentioned this to a friend, Jerry Weinberg, who is a noted author and consultant. He replied that he had done something similar while he was a college professor. He walked about the campus picking up trash and putting it into garbage cans. There was always plenty of trash on the ground, so he had all the quiet thinking time he wanted. No one interrupted him. They were embarrassed to do so because they weren’t picking up trash.

Quiet Thinking Time: If you want such, find a menial task that needs to be done but is distasteful to your colleagues. They won’t bother you while you are doing it. Stock the fridge. Clean the fridge. Pick up trash. Think with out interruption.

by Dwayne Phillips

It is easy to let other people control your day and make it a big waste of time.

Here is a story, a true story.

I was at work. Later in the day I was to brief a roomful of important people. But for now, and the next few hours, I had nothing to do. I decided to go to the grocery store and buy a large amount of soft drinks for the office refrigerator.

I walked down the hall towards the exit. Standing outside the conference room were two conscientious persons waiting their turn to brief a roomful of important people.

I went to the store and bought a large amount of soft drinks. I parked my soft-drink-filled vehicle next to the office entrance. I went to find our office cart to haul the soft drinks. On my way to the cart, I passed the conference room and noted that the two conscientious persons were still standing by waiting to brief a roomful of important people.

I found the office cart and headed back towards my vehicle. On the way, I passed the conference room and noted that the two conscientious persons were still standing by waiting to brief a roomful of important people.

I filled the office cart with the soft drinks and entered the building. On the way to our soft drink storage area, yes you know, I passed the conference room and noted that the two conscientious persons were still standing by waiting to brief a roomful of important people.

I put all the soft drinks in the soft drink storage area. I returned the cart its proper place and headed back to my vehicle still parked in front of the entrance. Once again—yes this is monotonous—I passed the conference room and noted that the two conscientious persons were still standing by waiting to brief a roomful of important people.

I went outside and parked my vehicle. I entered the building and on the way to my desk passed the conference room. Still, two conscientious persons were still standing by waiting to brief a roomful of important people. They had been standing there while I had done my soft drink run. This took about an hour.

I could no longer stand it. This time I stopped to address the two conscientious persons standing by waiting to brief a roomful of important people. I told them

What I’ve done probably isn’t very important, but at least I accomplished something.

We all smiled.

It is easy to allow other people, like all those important people filling that conference room, to control our day and turn it into one big waste of time.

by Dwayne Phillips

Sometimes, projects and the people working on them lose their way.

This is an expression I heard many times over the years.

They’ve lost their way.

I didn’t understand the expression. I suppose it was one of those grand mistakes that I never assumed people would make, but time showed me over and again that people do indeed make this mistake.

Losing Your Way: A project begins with a clear goal. Some people call this a Mission Statement. Time marches on and several months or years later, no one on the project can tell you the goal of the project. They have lost their way.

Where is Here?: Becoming lost is an easy thing to do. A project begins with a goal, and the goal leads to a set of requirements. People work earnestly to meet those requirements. One day they awaken to murky if any requirements. They are unsure where they are; they are lost.

How Did We Get Here?: Things happen in a project. Someone discovers that they don’t have the technology to meet a requirement, a.k.a., this is impossible. Then someone else walks in the door with a couple of new requirements.

We just didn’t think of these at first, but now we are enlightened and this is the way to go (until someone else enlightens us next month and we have yet another new way to go).

Someone forgets to erase the old requirements. Part of the team is working the old requirements while part is working the new requirements while part is talk to new enlighten-ers about the new light and all that.

And then to make matters worse, (or is it to make matters better? Sometimes I confuse the two.) Someone walks in the door and asks us to describe what we are doing. They use the words, “Where are you going?”

Everyone in the room looks at everyone else, starts pointing fingers, and mumbles something or other under their breathe but loud enough so that the room fills with incoherency.

They lost their way.

How to Stay Found: This is pretty easy, but it isn’t as much fun as becoming lost. Here it is:

Don’t change any requirements unless you follow a strict, agreed-upon method of changing requirements.

Aargh. As I wrote above, that isn’t much fun. Please note, the method does not prohibit change. It merely requires working to something we all agreed upon earlier when we knew our way.

by Dwayne Phillips

Science, and just about everything else, continues to advance with the number of eyeballs on every problem.

Linus Torvalds is credited with saying:

Given enough eyeballs, are bugs (problems) are shallow

It is a simple concept: if many people are staring at a problem, at least one is likely to see the solution.

I left grad school in 1986 (yes, I am that old) to return to full-time work. I had much work ahead of me to finish my grad degree. I bought a home computer for $3,000. That is three thousand 1986 dollars which is like several million dollars today (perhaps I exaggerate inflation, but just a tad). That computer had just enough compute power for me to work through my research problem and graduate by the slimmest margin.

There weren’t many people in 1986 who could buy a $3,000 computer so they could stare at a problem in the evening and on weekends.

Today, $500 will buy a powerful computer. And that is five hundred 2014 dollars. If you need more computing power, get a one-year free trial of Amazon compute cloud, just one option of several, and run experiments on your problem there.

The number of people who can afford this approach to stare at a problem is maybe ten million times more than in 1986. I am not writing ten million people; I am writing ten million times more people.

The number of eyeballs has and continues to explode. No wonder the Google boys did what they did. The same for the Facebook boys and all the rest. And this goes behind computing and software and those things. The number of people who can write the next Harry Potter has exploded as well.

There isn’t anything new or earth shattering in this post. It is simple a reminder that we have plenty of problem solvers out there. And I am thankful for that because we have plenty of monumental problems out there.

by Dwayne Phillips

When you consider it, systems engineers do something that everyone already does. Right?

Systems Engineers do a simple task: they ensure that all customer requirements are built, tested, and delivered. They keep lists and tables and all sorts of things that trace all work back to every customer requirement.

So why do we have systems engineers? I mean, who would build a system that did not fulfill all the customer requirements? Who would build a system that sort of “forgot” a few things that the customer wanted, paid, and wrote in the contract?

Answer: we all would. We all would leave out just a few things that the customer wanted.

Reason: we are all human. We all tend to do the things we like to do and avoid the things we don’t like.

The customer asked for a few things that we don’t like. We “forget” them and instead spend all our time building into the system the things that we like. After all, if we like them, the customer must like them more than those other distasteful things that were in the list of requirements. The customer probably added those distasteful things at the last moment and really didn’t care if they were in the system.

And besides, who is that systems engineer? Who does he think he is with all his nagging lists and tables and such? He is just a glorified clerk with all that stuff and nagging us about those last-minute, leftover requirements. He doesn’t understand what the customer really wants. We really understand and we are really building in the important things.

Funny how the important things are also the things we like.

So why do we have systems engineers with all their lists and tables and clerical work? Because we are human, too.

by Dwayne Phillips

I have three adult sons. They are a study in delving into the sharing economy.

I have three adult sons. One has a traditional paid job. He leaves his home five mornings a week, drives to an office, works, and receives a paycheck that is 100% of his income.

A second son works from four to seven days a week. Sometimes he works days and sometimes he works nights. His paycheck is about 50% of his income.

A third son works a few hours a night two or three nights a week. He works an hour or two here and there during the week teaching people one on one. Sometimes he works a six-hour day for three or four days in a row, but then doesn’t do that for weeks at a a time. He receives a dozen different paychecks each month.

My three sons have three different personalities. That is normal. The oldest is four years older than the youngest. Those four years saw a huge difference in the health of the U.S. economy. My third son scrambles for a living. That is explained by his personality and by the health of the economy. The traditional job and economy of the first son described is disappearing.

Maybe, just maybe, one day the traditional economy will return to some of its former health. Until then, the generation of my sons will scramble about in the sharing economy.