Working Up

by Dwayne Phillips

Here is a technique to express a story (short story or full novel) in one sentence (or two). It is from Dwight V. Swain.

I have been reviewing some of the books on writing that I have read in the past decade. Good books are like that – you can review them and relearn wonderful things.

Here is a good starting point for a story from Dwight V. Swain’s Techniques of the Selling Writer (a 30-year-old book).

What elements do you really need in a story outline? You should have:

a. A focal character.

b. A situation in which this character is involved.

c. An objective Character seeks to attain.

d. An opponent who strives against Character.

e. A potential climatic disaster on which to hing the resolution.

For example, (also from Swain’s book):

Pursued by his boss’s amoral wife, Linda, Steve Grannis decides to seek a transfer, so that his home and career won’t be destroyed. But can he escape, when Linda swears that she’ll have him fired and ruined if he tries to leave?

Here is another example from a short story I am writing currently:

Matt is saddled with college debt, but he has a plan to work his way out slowly. He is doing well, but can he keep to the plan or will fatigue overcome his efforts?

by Dwayne Phillips

Whatever it is we are doing, there are probably other people doing much the same thing. Sometimes we have to look in the dirt to notice their footprints.

My wife and I went “hiking” (walking in the woods) recently in the Shenandoah National Park. The trails were pretty easy to follow – especially if you looked at the footprints in the dirt.

Someone might as well have posted a weather-proof aluminum sign that read: Nike was here. There is was in the dirt – the imprint from the bottom of shoes from other people.

I guess the people who came after me on the trail would read: New Balance was here – as that is the brand of shoe I wear when walking.

This isn’t terrible. People are out walking and enjoying the park (that we pay for with taxes so we might as well enjoy). We wear shoes, and the shoemakers, well they have figured out how to advertise.

Is there a point to this rambling? I think so. There are signs all about us in the woods of other people doing the same that we are doing. There are signs all about us in the fill-in-the-blank of other people doing the same that we are doing. We just have to look at the dirt and read the foot prints.

by Dwayne Phillips

One of my personal heuristics about projects is that on a good project, all the challenges come from technology and all the joys come from people. Bad project are the other way around.

A year or so ago I found myself in a conversation with a woman who was starting a technology project in her office. She, the Project Manager or PM, was interviewing people like me to work on the project. The conversation went something like this:

PM: What do you see as the possible problems on this project.

Me: Three things: people, people, and people.

PM: (sighing and rolling her eyes) Yes, I know, but what about technical risks.

Me: Oh that. There will be some technical risks, but they are minor compared to the people involved.

PM: How so?

Me: Is everyone in your office in agreement that this project should happen?

PM: Yes.

Me: Really? Everyone here wants this project to proceed. Everyone here agrees how it should be done? Everyone here agrees that this project will solve major problems in your work?

PM: (no answer)

Me: If everyone here wanted this project, agreed on how to conduct it, and agreed that the project is good for the work, the project will only have to contend with technical problems. And there will be technical problems because you are trying to do something that no one else has done before you. If other people had done this project before, you would merely write them a check and they would sell you a copy of their solution.

PM: What are the problems?

Me: Some people in your office probably disagree with you on this project. They probably think there are non-technical solutions to improving the work here. Since this is an office with people, there are probably non-technical solutions to improving your work. Those solutions, however, won’t be implemented. Someone is stopping them or you would have already used them and this problem wouldn’t be here and we wouldn’t be talking.

PM: (no answer)

Me: So, here we sit. Your organization has problems in its work. People disagree on how to solve the problems. You are trying to implement a technical solution. Some people here will either fight you quietly behind your back or openly, but they will fight you. You will have technical people working to solve technical problems, and they will solve those problems because you will hire smart people and the problems have solutions. Still, the work will languish because some people won’t want to see the technical approach succeed.

PM: What do we do?

Me: Have everyone sit in a room until you reach consensus on what the problems are and how you will approach them.

PM: But maybe the consensus approach won’t include this technical work.

Me: Yes, that could happen.

PM: Then you and no other engineers would work here.

Me: Yes, that could happen.

We never talked again. I wasn’t hired to work in that office, and I don’t know what they did. I hope they reached some consensus and solved the problems with their work. She seemed like a good, caring, devoted person – the type of person I would love to work with on a project.

by Dwayne Phillips

I often saw companies blamed for bad management. The real problem was estimating in time of greatest ignorance and customers not mitigating the risk of such estimates.

For a couple of decades, I monitored the performance of companies on government contracts. Part of this job was to grade the companies on how well they performed. The typical grading focused on (1) technical performance and (2) management performance.

The vast majority of the time, we graded companies as good technically, but with poor management. We were wrong.

A typical project performed for the government was based on a proposal submitted by the company. They estimated a schedule and cost by which they would deliver technical products.  Most projects followed this pattern:

• Everyone was happy to start work
• The first six months had a few problems, but we were all still happy
• Problems showed in the second six months – behind schedule and over cost
• Problems continued through the middle half of the contract
• Products were eventually delivered, and people were happy again

Notice the problems – behind schedule and over cost. Notice the happy ending – products delivered. The responsible parties?

• Managers are responsible for cost and schedule
• Engineers are responsible for products

Hence,

• Bad management
• Good technical

I now conclude that these conclusions were wrong. The company was behind a schedule that was estimated in a proposal. The company was over a cost that was estimated in a proposal. The real problem was the estimate contained in the proposal. People didn’t estimate well. And, by the way, most of the estimates were created by the technical people, not their managers,

Why don’t people estimate well? Two factors:

1. They are rushed to make their estimates, often working nights and weekends to complete a proposal in a short time.
2. They make the estimates before work begins, at the point of greatest ignorance.

What do we do now?

Customers, the government contracting agency in this example, need to understand the risk involved in estimates made in ignorance. Estimates are predictions of the future. I don’t know anyone who predicts the future well.

Hence, I advise customers to mitigate the risks with budget and schedule buffers. Add a 25% buffer to your budget and a 25% buffer to your schedule. If you have a million dollars for a contract, adjust the product so that the estimates from companies are about $750 thousand. If you need a product in 12 months,  adjust the product so that the estimates from companies are about nine months.

Customers can scream, “Deliver per your estimate or I will get really mad at you!”

I’ve observed such screaming many times. It has never changed anything.

by Dwayne Phillips

A short thought about “play.”

I like to play with my grandson.

When I thought about this, I realized that this is one of the few things I do in life where the word “play” appears. Another place is when I play the guitar. I enjoy that as well.

One outcome of these thoughts is that I should find more activities where the word “play” is involved in the description.

by Dwayne Phillips

Recent events bring an old saying to mind: you don’t need permission to do your job.

You don’t need permission to do your job¹

This thought hit me last week. I was working in a different office and was struggling to get anything done. One of the things that bothered me was the amount of dust and dirt on the desk and floor. I wanted to ask someone for permission to tidy the room a bit. Duh. I didn’t need to ask anyone for permission. Getting something done was my job, and if dirt was preventing me from doing my job, well, duh.

A little thought about this old saying ties it into much of what I read today on the net. There is lots of entrepreneur, work flow, and web 22.0 flying about today. Click, turn on, link in, pin the linch, connect, blink, and all that stuff. They all seem to be spins on the old Nike saying of “just do it.”

The same goes for the above saying. If it is my job, just do it. If I find myself in all sorts of trouble for doing my job, well, that’s life. I was trying to do something positive.

I like to add a word to the end of the above phrase:

You don’t need permission to do your job well

Of course, sometimes doing your job and doing it well are subjective. People will disagree about what they mean. Again, at least I was trying to do something positive.

1. I heard that a long time ago. I can’t remember where, when, or who said that. If you know, please tell me.

by Dwayne Phillips

A simple yet powerful tool for change is to stop and breathe.

This is a simple step in changing the world. It involves only one person – me. Therefore, I can do this whenever I decide, and no one else can stop me.

This step is to breathe. Stop what I am doing. Take a moment. Breathe.

Amazing things happen when I breathe. I think better. I become patient. I become kind. I become happy. I stop most of the negative things that are happening inside and closely about me.

by Dwayne Phillips

Looking for design ideas? Visit a Starbucks once a week.

I love to look a new designs. Designs are plans for solutions or solutions themselves. One of the reasons I loved walking a thousand miles down a road was that I saw how people solved problems with buildings, pastures, fences, vehicles, and so on.

I frequent Starbucks coffee shops. There are two or three different locations I visit depending on what day of the week it is and where my job takes me. One of the Starbucks has retail space and displays coffee cups, coffee makers, water bottles, and other sundries. I love to look.

Starbucks often changes these little items that they have on display. They are displaying designs. How many ways can you make a coffee cup? More than I thought possible. How many types of machines can you use to brew coffee? More than I thought possible.

Perhaps that is it; perhaps that is the reason I like to see as many designs as I can – they expand what I think is possible.

by Dwayne Phillips

Yet another example of someone not eating their own dog food.

My wife and I went “out of town” for a day for our anniversary this weekend. We ate dinner in Front Royal, Virginia. We like that town.

We ate at a local restaurant – locally owned and operated. It was a small place with, what it seemed to be, much bravado. The menu, the signs, the notes in the motel welcome guide – all touted the excellence of the local food.

During dinner, I went to the bar near the cash register to take care of the bill. Two waitresses were sitting behind the bar eating pizza that had just been delivered to them. Hmm. Great local restaurant with a varied menu, and the waitresses were eating delivery pizza.

This is another example of someone not eating their own dog food. I was a bit surprised to find a Wikipedia article on this topic of eating your own dog food.  This is a practice where people use their own products.

For example, do

• waitresses eat the food they serve at a restaurant
• Apple employees use iPhones and Mac computers
• Microsoft employees use the Windows operating system (and Office and such)
• Google employees use Google to search
• WordPress employees use WordPress to blog
• public school teachers send their kids to public schools
• and so on

Funny how the answer to these and other questions are often, “no.”

by Dwayne Phillips

One of the differences between hardware and software is that hardware requires some design before building begins. Software, however, can begin at any moment without design.

I was a bit surprised the other day at work, but people were debating the differences between building hardware and “building” software. (I guess that is a topic for another day, i.e., do we “build” software? “Write” software? What is the correct verb?)

There are many differences; the difference I recognized that day was:

Design

I contend that I have to design hardware before I can build it. I contend that I  can write software without any design.

Consider hardware. I cannot build hardware without parts. Depending on the job, the parts may be as small as resistors, capacitors, solder, and so on. The parts may be as large as A/D converter, USB interface, power supply and so on. Parts don’t appear magically. I have to buy or borrow or whatever to possess the parts. I can’t buy or borrow or whatever without having a list of parts. I don’t have a list of parts without some design.

Consider software. I don’t need any parts. I can start writing software at any moment. Yes, I must have a computer and a piece of software like a compiler or interpreter or the like. Those needs, however, don’t differentiate me from the hardware case as I need a computer and some design software for hardware as well.