Working Up

by Dwayne Phillips

Excuses are great. As long as I have plenty of excuses, I don’t have to take responsibility for my life.

I have plenty of excuses why my life isn’t the way it is supposed to be. I have plenty of excuses why my job isn’t what it is supposed to be.

Please don’t take away any of my excuses. If you do, I’ll have no where to look or go. I’ll have no one or no thing else to blame for my unmet expectations. I’ll have to be responsible for my own life. That is a frightening thought. I don’t know if I am ready for it.

by Dwayne Phillips

Excuses are great. One of the best is “I have so much to do” as it gives me choice as to what I will do today.

I have ten jobs I do. If I don’t want to do #3 today, I have an excuse as I am really busy with the other ones.

Please don’t hire someone to do #3. That will remove one of my choices, and it will leave me with fewer excuses of why I can’t do what you want me to do (instead of what I want to do).

Hmm, being overworked is a good thing. At least it is good for me. Perhaps it isn’t so good for everyone else.

by Dwayne Phillips

Agile development is not an excuse for knowing what you did, why you did it, and how you did it.

You’re doing agile development. You hold a meeting to start a sprint (different methods use different names for this). You sprint! You meet again at the end of the sprint.

1. What did you do?
2. Why did you do it?
3. How did you do it?

Question 1: at the end of the sprint, you demonstrated what you did. You should record that in some tool you use for agile.

Question 2: you did what you did because someone asked for it. Again, you should record that.

Question 3: you wrote code, you changed code, you tested the result.

The answer to question 1 almost always happens. The answers to the other questions…well, not so much.

If you don’t know who wanted something, how can you demonstrate that something to them to see if they are satisfied? This requires recording information about who asked for what. I know, in agile, documentation is not as important as working code. But still, come on folks, we write software for a person. If we don’t record the person’s name, how will we satisfy the person?

Now the awful question 3. Can we repeat what we did? Do we have the information as to the data and methods we used to prove that our additions and changes satisfy what was requested? If we don’t, we are wasting time and money.

Note how I used the word “satisfy.” This is why we are working—to satisfy someone else.

The answers to 2 and 3 are met by the systems engineering function of tracing. Everything has a reason, a purpose, a place to fit. Tracing allows us to follow the reason through our work. Work without a reason is, well, unreasonable. Hmm.

Yes, working software is more important than documentation. Use of good tools allows agile teams to document work so it can be traced without doing more work. Let’s be aware of what we can do to satisfy others.

by Dwayne Phillips

We are here; we are gone. Sorry, others will forget us.

I’m sorry, but it will be forgotten, and I will be forgotten as well. Sure, computer technology can store my life, but someone has to pay attention, and that is where it falls apart.

In some library somewhere are copies of some of the books I have written. How long will these libraries stand? When will they dump my books into a bonfire as they convert from paper to something else at the local library?

It is just a matter of time. Again, sorry.

by Dwayne Phillips

Questions are just questions. No offense intended.

“No, I am not trying to be mean. I am asking questions to learn as there are some things I don’t know, but would like to know. Please help me understand.”

“I apologize if you think I am de-railing your presentation. I am seeking clarity.”

“If you don’t have an answer, please say, ‘I don’t have that answer now. I am happy to work with you tomorrow to find it.’ “

by Dwayne Phillips

Excellent maintenance sometimes indicates a faulty product or service. Sometimes, no maintenance indicates a superior product or service.

I first encountered this over 20 years ago. We had purchased similar products from two companies, let’s call them Smith Inc. and Jones Inc. for now.

The conversation went something like…

“What happens when a Smith Inc. widget breaks?”

“We call their 800 number, an expert answers, they talk us through the situation, and if necessary a team of technicians is on the road in 15 minutes and be at our location as soon as possible.”

“What happens when a Jones Inc. widget breaks?”

“Don’t know. Never had one break before.”

So, which product would you rather buy? Which company is better for customer service and product maintenance? Which product would you rather build?

by Dwayne Phillips

I recommend an organization for the future or work as we know it.

This is the new company. It is an agile team that has worked together on many software projects. The Team has learned much on all these past projects. The Team has become high performing (it “jelled” a long time ago). The Team can do what seems to be amazing stuff in a short time.

Hire The Team, not individuals.

How do you hire the team? Simple. Here is their “interface” or contract:

Give us an room (size specified) with Internet access via ethernet ports on the walls (access speed specified). We will bring the furniture, computers, white boards, etc. We setup the room the night before work begins. We’ve done this setup many times and have learned how to do it efficiently.

The Team arrives at dawn—seven persons. You supply someone who can describe the desired product. You pay $10,000 a day.

Life as we know it: Groups of persons work on agile projects. They learn how to work with one another. The group becomes more than the sum of its parts. The project ends; the group disbands, and the individuals go to other groups to work other projects. Start at zero again with the learning and growing.

Life as it could be: Let The Team stay together. Let them use what they have learned. One way to do it is for The Team to form it own company. Yes, this is like “two guys and a truck” and a movie production company and a band that has played together since high school.

Why can’t we do it in software development or in developing any other intellectual product for someone? I suppose there are reasons why the band can’t stay together. Perhaps we can learn from those heart-crushing breakups.

by Dwayne Phillips

We thank the person. We comment on the product. And we let everyone know that is what we do here.

Persons accomplish the work in endeavors. Persons use tools, sometimes they are really cool and expensive ones, but persons ultimately accomplish the work. The outcome of the work is a product (sometimes we call the product a “service”).

So, we have persons and products. How do we discuss them? What do we say to the persons?

I believe we can judge a product. I can hold a pencil in my hand. I can feel it, smell it, feel how it leaves marks on surfaces, see those marks, and sometimes taste the pencil. I can set the criteria for the pencil—how it feels in my hand is more or less important than anything else. I can comment on the product.

I believe we cannot judge the person who accomplishes the work. I don’t know what is in their mind. I don’t know much about the 3/4s of their life that they are not “at work.” I don’t know what and how they feel.

What can I say about the person? Almost nothing.

What can I say to the person? “Thank you.”

I believe this is how we should talk: We thank the person. We comment on the product. We let everyone know that this is how we talk.

Naive? Probably. Common practice? No. Still, I think these are worthy aspirations.

by Dwayne Phillips

Analysts seek to find the difference that makes a difference. What can be vexing is that often there is no final difference.

I believe that technical analysis and the analysis of technical systems comes to one question:

What is the difference that makes a difference?

Is it temperature that makes one system work and another fail? Is it humidity? Is it size, weight, power, color? What is it?

One of the great issues that makes analysis so difficult is that in many situations, there is no final difference. No system will move 1,000 people 1,000 miles in one hour on one gallon of gasoline. No system will move people to Mars in three hours.

Consider professional sports franchises. They draft people to be on their teams. What is the difference that makes Michael Jordon or Tom Brady the one player who will provide long-term dominance for their franchise? A major problem is that there is no one out there who will provide that. Maybe 10 or 20 years from now, some young person will be born with the ability and desire to dominate. Maybe not.

The analysts are searching for someone who doesn’t exist. They fail year after year and maybe generation after generation. The analysts and their methods are despised for their failures.

Continue to look, listen, smell, touch, and taste. Continue to observe. Continue to search for the difference that makes a difference. Understand, however, that there may be nothing to find.

by Dwayne Phillips

Take great care when everyone agrees about something.

Once the world was plagued with the longitude problem. Long-distance sea travel was dangerous and fraught with the great unknown, “where are we?!?!?!?”

Everyone agreed on the solution to the longitude problem. Everyone, that is, except the carpenter who solved the problem. For background, see the Wikipedia article on John Harrison—the carpenter who solved the problem, and the problem in general and the culture surrounding it in another Wikipedia article.

Of course the history is slanted because some people won with the solution and some people lost with the solution. That is the nature of science, engineering, and solving problems. I recommend the hours required for detailed reading. This was a real problem that tilted the world’s economy.

One lesson from this history: Take great care when everyone agrees on a problem. This is especially true when we can’t measure the problem and have to use a lot of approximations and extrapolations.

Consider climate change. The world’s economy rests on this issue. The temperature curves we have use a lot of approximations and extrapolations. The persons doing these approximations and extrapolations are well educated, smart, and caring people. All those people who knew the answer to the longitude problem were also educated, smart, and caring people. They held the great majority of opinion. They were wrong.

This happens with great unknowns. When we “solve” climate change, some people will win big $$$ and some people will lose big $$$. There will be great debate, controversy, and all sorts of grievous vexations.