Working Up

by Dwayne Phillips

That one person won’t be attending today. Everyone sighs in relief. What does that tell us?

I’ve attended more meetings than most people. I have 28 years of government work to thank for that. There was almost always one or a few people scheduled to attend the meeting that I was happier if they missed.

I was not alone. Most people were happy that so-and-so was absent. The meeting went faster; people were not upset, and we all left happier with more accomplished.

What does this tell us?

• the absent so-and-so was a real jerk
• the rest of us were jerks for hating so-and-so
• the rest of us didn’t understand so-and-so

I could go on. It seems that the question is,

Who was wrong? That one so-and-so or everyone else?

Math tells me that so-and-so was wrong and everyone else was right. Math, however, is not a person and was not involved in the emotions of the persons.

Time tells me that everyone was at fault. So-and-so was doing something that some of us didn’t like. We, however, never said anything. We sat in the room with our fingers crossed under the table wishing that so-and-so would miss the meeting.

Crossing fingers and wishing are childish practices.

(Note, I wrote childish not child-like.)

Adults confront fears.

by Dwayne Phillips

There are practices that time has proven to be worthwhile. Someone in school drilled them into us. We vowed to avoid them as soon as school was out, but life eventually catches us.

I have lost track of the number of times I have seen this on the job. We have a problem; we examine the problem and its causes, and we conclude that someone avoided a fundamental practice. There are no excuses other than, “I didn’t want to do that.”

That is the source of the title of this post. In college or trade school or high school, we learned something basic. The teacher made us do it more times than we felt necessary. We vowed that once we got out of that class or place or the sight of that stubborn, mean, rotten, overbearing teacher, we would never do it again.

Then it happened. We skipped that long-cursed practice, and the ceiling of the world fell on our heads. These long-cursed practices are not nice theories. They are not new inventions that someone wants others to try first.

They are basic practices that have proven their worth over several centuries.

We avoid them at our peril and snicker when we get away with it. Time and circumstances, however, catch us.

Okay, here are a few examples (add to the list):

• experiments should be repeatable
• don’t pour ingredients back into the container
• wear your safety goggles
• wear all the safety equipment
• always have two people present
• ask someone else to read your paper
• if you didn’t document it, you didn’t do it
• if you didn’t test it, you didn’t do it
• if you didn’t document the test, you didn’t test

by Dwayne Phillips

How much oversight, process, testing, and any activity other than writing software should you do? The answer lies in the consequences of failure. Don’t let the quest for better destroy your software project.

• How much effort should you spend testing software?
• How much management oversight should software projects have?
• How much effort should go into all activities other than programming?

I have asked myself these questions for years. I am not alone in my puzzlement in this area.

I have had the privilege of working on software projects that ranged from tiny embedded systems to supercomputer signal processing. I have worked in structured, large-process, heavily managed projects and one-man just-code-like-hell projects.

The answer to my questions?

It depends on the consequences of failure.

I believe that Microsoft learned a long time ago that if a failure means you hit the Control-Alt-Delete keys and wait two minutes, don’t put much effort into anything but programming.

I know that if a software failure means you break concrete and dig out an embedded system to reprogram it, you spend a lot of time and effort testing, reading, re-rereading, and more testing of the code before you release it.

This seems pretty simple. Nevertheless, I see people expend large amounts of resources on software where a failure means only a reboot. There is a good enough measure of software. When the software is good enough, stop working on it. Move on to the next great thing.

The quest for better often destroys software projects.

by Dwayne Phillips

Policy statements can be the most useful things that managers can produce. They help persons make decisions daily.

Yes, managers can, and sometimes do, contribute to work. One of the more useful contributions they make is policy.

Let’s define terms:

Policy statements articulate broad direction for an organization.

For example,

1. Write code that is portable.
2. Write code that is reusable.
3. Reuse designs from other projects.
4. Document your work.

(We can debate the wisdom in these examples, but that is for another day. These examples are excellent in some circumstances and disastrous in others.)

The scientists and engineers working in an organization can use these policy statements to guide their daily decisions. “Should we try this new algorithm from this journal or adapt what we did last year?” Policy statement number 3. makes that a much easier decision. “Should I code for speed or reuse?” Policy statement number 2. makes that a much easier decision.

I could continue with examples without end. My advice to managers,

Decide issues at a high level.

Post those decisions for everyone to see everyday.

This is will actually help the persons performing the work.

by Dwayne Phillips

Agile development can reduce risk, but not every kind of risk.

Agile development does reduce risk. Agile is a form of the spiral development created by Barry Boehm (okay, scream now). Spiral was created to reduce risk and, if used properly (loaded words), it does reduce risk.

So, let’s consider Agile:

Agile development reduces product risk.

By this I mean that using Agile reduces that chances that the user will look at the delivered product and say, “That’s not what I had in mind.” This is because the user is sitting with the development team everyday and telling them the users’ desires.

Product risk, however, is not the only type of risk:

Agile development does not reduce process risk.

Process risk expresses the chances that the development team is using the wrong process. Agile development is not the best process for every type of project. Blindly using Agile carries with it the risk that Agile is the wrong process for the project. Agile development can be the most inefficient type of development in some situations.

And let me continue with:

Agile development does not reduce solution risk.

The solution is the answer to the problem we are attempting to solve.  The solution comes if smart people work on a problem and find a solution.  For example, let’s cure cancer. Agile development won’t find a cure for cancer. The right people with the right technology and the right circumstances might find a cure for cancer. Then again, there is the chance that no one will ever find a cure for cancer. That chance is the solution risk.

Now where are we?

We are still in the situation where we should consider the situation. ooops, that word “consider” means THINK. Think before choosing Agile development or any other type of development or whether or not you attempt a project. THINK.

Perhaps, one day, we shall be in a situation where thinking is not required. We aren’t there yet.

By Dwayne Phillips
I am unable to say, “You implied such-and-such.” I know it is a small distinction that difference between imply and infer, but it bothers me.
I continue to stumble upon these two words: imply and infer. I her people say, “You implied such-and-such.”
Since this is my blog, I can rant to my choosing.
When you say something, I can infer things from your statement.
When I say something, I can imply things in my statement.
It doesn’t work the other way around. Perhaps if I were more clever, I would know what you are implying. I confess, however, that I am not clever and I doubt that I will become clever. Therefore, I will continue to only to infer from what you say. I ask the same of you.

by Dwayne Phillips

Can you measure a manager’s good-ness by the weight of the people being managed? I contend that you can.

First, a little story:

I was eating lunch with Rob. Now that he had moved to a new job, he ate lunch in the cafeteria everyday. In his previous job, he rarely ate lunch in the cafeteria. He simply didn’t have the time with the demands of the job and the demands of his manager.

I expected someone who went from rarely eating a full lunch to always eating a full lunch to gain weight. Rob surprised me by stating that he had lost weight.

In the coming weeks, I met several other people who had worked in the old organization for the old manager that Rob had. They all had the same stories: their new job, their new manager, wasn’t so demanding. They all ate regular lunches.

And they all lost weight.

Does a demanding job cause weight gain? Does a demanding manager cause weight gain?

I contend the answer to the second question is, “YES!” The manager at the center of the above story was scatter-brained (giving him credit for having a brain is, well, giving him credit for something that may not have been true). The manager created crises on the hour. People, like Rob and the others I met, were yanked to and fro all day and did not eat regular meals. Instead, they “grabbed snacks” when they could.

They ate poorly. They gained weight. They were often sick.

Perhaps I can extend the weight factor to the general health factor.

How good is a manager? Look at the health of the people being managed.

Are you a manager? How healthy are the people you manage?

by Dwayne Phillips

It seems that everyone is using an Agile process these days. There really isn’t anything new in Agile. And, in some cases, Agile can slow the delivery of software to users.

What? Agile be slow? Yes, Agile processes can slow the delivery of software to users.

Twenty years ago, I worked in a lab where we delivered software updates to users in a day – sometimes an hour. The users didn’t have to wait 30 days for a sprint to end.

A user would come to me with a requirement. I would take them to the right programmer (the programmer who knew that part of the software best), the programmer would change the code, someone else would test it, and the software was on the system for the user to use.

We didn’t have an official backlog of user desires, we didn’t have a burn down chart, we didn’t have a daily meeting, we didn’t have all the wonderful things that good Agile organizations have.

We had some competent people who worked well together.

I am not disparaging Agile; I am not disparaging the concepts behind Agile.

Before Agile, there was a lot of wasted effort and failed software projects. There were also pockets of people who were competent and worked well together.

by Dwayne Phillips

An incident in the cafeteria illustrates blaming and placating – incongruent stances created by a misconception of the self and the other.

First, a story:

A lady – a customer –  is walking through the cafeteria at work. She falls to the floor.

A second lady – the cafeteria manager – runs up to the fallen customer, looks down at her, and screams, “There is nothing wrong with the floor. You tripped on your pants.”

The customer lying on the floor in the middle of the cafeteria jumps to her feet as fast as she can and scurries out of the cafeteria.

The cafeteria manager is blaming. She is acting from the notion of I am everything, you are nothing.

The customer is placating. She is acting from the notion of I am nothing, you are everything.

These are opposite reactions, but they stem from the same emotion: fear.

The cafeteria manager is afraid that the customer fell because the floor was slippery. A slippery floor cannot exist in the cafeteria. The cafeteria manager will lose her job if the floor caused the accident.

The customer is afraid that everyone will think she is clumsy – too clumsy to walk and chew gum at the same time. Clumsy people are stupid, and stupid people lose their jobs.

Neither lady loses her job.

It is unfortunate, but I have seen the same interaction thousands of times in meetings at work. Persons fear something terrible and act from that fear by either blaming or placating. In almost every situation, there was nothing to fear – at least nothing nearly as fearful as the cafeteria incident.

by Dwayne Phillips

Should we send our customers to a veterinarian, i.e., someone who is accustomed to working with beings that cannot speak?

First, a story:

My granddad was a stubborn man.

My granddad was ill and went to a doctor, an MD. My granddad was paying the MD a lot of money, so he figured that the MD should be able to figure out what was wrong with him without telling the MD anything.

After a while of asking my granddad questions and receiving no response, the MD wrote a note and gave it to my granddad.

“Here,” says the MD. “Go see this person.”

My granddad read the name on the note and recognized the person as a Veterinarian.
My granddad protested, “This guy is a vet, not a people doctor. Why should I go see him.”

The MD replied, “Yes, he is a vet and he is used to working with dumb (cannot speak) animals.”

Now back to reality. I am trying to learn a customer’s requirements. My boss tells me,

I want you to work with this customer. They are not capable of telling you their requirements. They cannot tell you what they want. They cannot tell you their priorities.

They don’t seem to be capable of useful speech.

So, why don’t we sent a veterinarian to that customer? Why do we send a systems engineer?

I suppose I don’t understand how the world is supposed to function, but that is just me.