Working Up

by Dwayne Phillips

The later in a project you correct a mistake, the more it costs. Confirmed again.

There are many wise sayings associated with managing and working  projects. Many of the wise sayings are myths that have been busted. Many, however, are true, and we stubbornly refuse to believe them. Our stubbornness is evidenced by repeatedly ignoring them and hurting ourselves. One of these old wise saying that is true is:

The later in a project you correct a mistake, the more it costs.

A current project I work has a lot of MS Word documents. Word documents are fine alone. When you try to combine them into one document, you can have all sorts of problems with paragraph styles, Tables of Contents, and such. The persons on the project didn’t address these concepts early as they would be taken care of later. Well, later is here, and yes, there will be dozens of person hours spent correcting mistakes that were made early in the project. Too bad they weren’t corrected early in the project when the fixes were simple.

Wise old saying confirmed (again).

by Dwayne Phillips

I observe that some people will transfer the power over their lives to people whom they disdain.

I find this odd, but I find it often. Some people will give other people power over their lives. The conversation goes something like this:

Person A: “That person is ruining my life!”

Me: “How is that?”

Person A: “Why, they said a bad thing about me!”

Me: “And how does that ruin your life?”

Person A: “Why, why, why, well what do you mean? Don’t you understand how that makes me feel?”

Me: “So that person controls how you feel?”

Person A: “Of course!”

Me: “When did you give them that power?”

Person A: “Why, you just don’t understand.”

Me: “I agree with you on that point.”

What I find more odd to the odd is that Person A will give this power to someone whom they disdain. The above conversation will start with:

Person A: “That little so-and-so is ruining my life!”

The remainder of the conversation proceeds as above.

Take the first statement and replace “so-and-so” with your favorite deragatory term for a small, powerless being. Some of the words I have heard include twerp, twit, skunk, idiot, and a number of nouns I will not repeat here.

The point is that Person A is giving a powerless being to power over their life. Again, I find that odd, but I find that often.

by Dwayne Phillips

There is no substitute for knowing what you are doing.

I love working with people who know what they are doing. They come to the workplace, see challenges in front of them, and eagerly plow into the work.

Short pause – I don’t live in LaLaLand. I live and work in the real world. Some of the above-described people actually exist and work in the real world. It is a pleasure to work with them.

One more thing: sometimes, “knowing what you are doing” means “you know how to learn how to do things that you don’t know how to do.”

That is the best “knowing what you are doing” knowledge: knowing how to behave in the face of the unknown. It is the attitude of, “Look, something unknown! Learning will be such great fun!”

by Dwayne Phillips

I find there are three characteristics I want to see in the people who work with me.

There are three things I want to see in the people who work with me:

1. They know what they are doing
2. They have the self-discipline to do it
3. They have the courage to tell the truth (often when others don’t want to hear it)

1. They know what they are doing – I don’t have to tell them how to do their jobs. More on this one in a later blog post.

2. They have the self discipline to do it. I don’t have to look over their shoulder or write procedures or make checklists or have a QA person. I may do some or all of those things, but I don’t have to do them. The ideal co-workers do their jobs they way they know how to do them.

3. They have the courage to tell the truth (often when others don’t want to hear it). I have met many people at work who don’t want to hear the truth. They want to hear that everything is fine, everything is going according to plan, all is well, no reason to think. I would love to hear those things as well, but only if they are true.  Regardless of what it does to my “to do list” for the day, I want to hear the truth. I am an adult; I work with adults.

Adults can work with the truth.

Children pretend other things.

So much for adults and children for the day. I like to work with adults. I love to play with (grand)children at home.

by Dwayne Phillips

If a system fails at one boundary, it will probably fail at another boundary. Hence, if you find a boundary failure, start looking for other boundary failures while you still have a chance at prevention instead of correction.

A few years back I had a problem with my van. I couldn’t reliably turn on the headlights. That was a bad situation, especially after dark. I found myself sitting in a parking lot flipping the headlight switch over and over until the lights finally illuminated.

Then one night, I found that I couldn’t turn the headlights off. Again, that was a bad situation as leaving the headlights on all night would drain the battery and so on. Then it hit me:

boundary condition failures

The headlight switch failed at one boundary – turn lights on – then it failed at another boundary – turn lights off. My headlight switch was a classic example of a system that worked well in a “sweet spot” or “sweet range” of conditions, but had difficulties at the boundaries or edges.

Now consider a recent project I worked. Some weeks we had nothing to do – extremely light work. That was a boundary condition failure in planning the work for the project. Think about the other boundary condition. Well, I didn’t have to think about it much as the next week we had 80 hours worth of work. That was another boundary condition failure in planning the work for the project.

Hmm, a headlight switch and planning the work for a project. These two things had nothing in common except for boundary condition failures.

Time, and more keystrokes, would allow me to relate more examples of boundary condition failures. A lesson to draw from these examples is:

If your system has a boundary condition failure, start searching around the boundaries for other failures

Boundary condition failures bring more pain than other kinds of failures – at least they have in my life. This is because the boundary conditions don’t happen often, but usually happen at critical points in time – like when you are sitting in a dark parking lot and you can’t turn on the headlights.

by Dwayne Phillips

Change in people (and what other type of change is interesting enough to consider?) takes time. Plan for it.

Change takes time as people just don’t change quickly. Sometimes in an emergency we change quickly, but who wants to face an emergency?

Here is a true story.

I was working on the east coast and had an association with a company on the west coast – let’s call them WestCo. WestCo wasn’t doing well with their software development. Their troubles were causing lots of budget problems, and many sponsors were doubting their ability to actually write software that worked.

The changes needed were somewhat obvious and elementary:

• write on paper the functions the software had to perform
• plan to have the people and other resources on hand
• write the software
• test the software
• integrate the software
• keep track of progress against the plan

Nothing incredible here, but nothing was happening at WestCo.

A colleague and I were to meet with WestCo and try to convince them to make necessary changes.

How could we use time to help convince them of change?

We left the east coast on the early morning flight, landed on the west coast, and arrived at WestCo right after lunch. We met for several hours as we proposed the changes that we believed would help them succeed and would sooth the worries of the sponsors.

The guys at WestCo didn’t like our suggestions – no surprise

We left the WestCo offices at about 3 PM. That gave them the rest of the afternoon to discuss our suggestions. It also gave them the night to sleep on the suggestions.

We returned to the WestCo offices mid-morning of the next day (a lot of boring motel hours for us, but thinking hours for WestCo). The WestCo folks had more time to discuss the suggested changes with their software developers.

WestCo agreed to our suggestions

Had we not allowed all the extra time for WestCo to absorb our suggestions, I doubt they would have agreed. With time, however, they decided that they could make the changes and the changes would probably help them.

Plan for time in change.

by Dwayne Phillips

A learning environment is one where people can learn. It may not be a teaching environment as that focuses on the teachers instead of the learner.

Several years back, author and consultant Jerry Weinberg told me a story about learning. The story telling was years ago, so my memory will fail me and I will have some of the facts wrong, but I hope the point comes through.

Jerry was teaching a five-day seminar. During the first session of the first morning, Jerry told the attendees that participation was voluntary. Anyone could not participate in any session as they wished. The attendees were adults and were free to take care of themselves.

After an hour or so, the seminar had a break. A man approached Jerry to check if Jerry really meant it about the voluntary nature of the seminar. Assured that Jerry did mean it, the man left the seminar and headed for the golf course.

Three days later, the man returned to the seminar. He approached Jerry again with the following:

I spent the last three days playing golf. I learned that I get bored with golf. I didn’t think I would, but I did. I had planned to retire in a couple of years, buy a home on a golf course, and play golf everyday for the rest of my life. I have changed my plans.

Thank you for helping me learn what I will do for the rest of my life.

Jerry didn’t “teach” the man about his life plans. Instead, he created an environment where the man could learn a life-changing lesson.

Teachers work in all sorts of different situations with different constraints. As a teacher, understand your constraints. Don’t assume you know the constraints until you test them. Do what you can to create a learning environment.

by Dwayne Phillips

I learn how NOT to backup an Apple computer.

Apple has a piece of software called “Time Machine.” It automates backups. The software puts all the files on the computer disk into a “big ball of bytes” on a backup disk. You must have Time Machine to access the individual files in the big ball of bytes.

I don’t like my individual files stored in a big ball of bytes accessible only by a proprietary piece of software. I am afraid that the proprietary piece of software will go away, and I will be stuck with a big ball of bytes that makes no sense.

I like the Unix (Linux, whatever) command line and the ls command. I suppose that is a function of age.

Given the above, it should not surprise people that for the past six years I kept a backup of my Apple iMac using scripts I wrote that employed the rsync command. If you read my previous post, you know that my iMac disk was erased and reformatted. I spent a week moving files back to the iMac. I learned a lesson:

Use the Apple Time Machine software for backups of an Apple computer.

Unix scripts using rsync and other commands works alright for data files (.doc, .xls, .c, etc.). They don’t work for applications and other things in between.

by Dwayne Phillips

My iMac disk dies so I have to recover everything from backup. But wait, not everything as my Google world is still there.

Short story about my Apple iMac computer. I was updating the operating system and the installer froze the machine. The guy at the Reston Apple Store was very helpful. In the end, however, he had to erase the disk drive and reformat it.

Not to worry – too much – as I had files copied to a backup disk. Putting all the stored files back on the iMac is a slow, painful, worrisome process (at least I worry while doing it).

I didn’t have to worry about everything. Much of my computing life is on Google. All the mail, email addresses, calendars, and much of what I have written in the past year or three are in the Google cloud. That is a big relief.

by Dwayne Phillips

Giving employees free time may bring great new ideas and products. Not giving employees free time may cause them to “try things” while working on projects. The projects often suffer.

I have met many engineers, programmers, administrators, and others who have great imagination. Ideas come to them (I used to be one of them, sometimes I stray back into that fold) and they try those ideas. Sometimes, some of those brilliant ideas work right now in the system we are building. Often, however, that isn’t the case. Poor odds don’t deter these imaginative people. Close oversight is necessary – well maybe not necessary as there are other choices.

Google is famous for their 20% free time. Though not the only company to have such as policy, “free time” is not accurate. The employees work hard during that 20% trying to create new products – whole, complete, usable, and (hopefully) profitable systems.

There is another type of Free Time policy (see footnote). In this form, the person is allowed to try anything for 10% or 20% of their time. The difference here is that the result of their time doesn’t have to be a complete product or system. Instead, it can be a subroutine, a new algorithm, even just a new way to pretty print source code. This type of free time pays for itself on projects.

I’ve seen  projects set back severely because someone had an idea and wanted to try it. Since they could only spend time on projects, they tried the idea on a project and its product. They had been staring at a piece of code or a design for a circuit and had an idea. They “slipped it in” to see how it would work. No one else knew; no one else would find out; the little change was sure to work. Sometimes the little change did work, but most of the time it didn’t. Since no one else knew about the little change, it was difficult and costly to find and correct it. Project derailed.

The Free Time policy would have prevented this derailment. Consider an example where a programmer sees something in the code that he would like to try. With Free Time, the programmer can copy the code baseline over to the side and try his idea. Failures are on the side away from the product and outside the schedule and cost of the project. Successes can be demonstrated to the project team. The idea can be put into the product, but only following an established procedure of peer reviews, tests, and documentation.

Whatever the result, the programmer’s time is counted on his time sheet (or whatever form of accounting is used) as Free Time. The time isn’t charged to a project; the programmer doesn’t have to sneak around to use his imagination, and projects don’t suffer.

One other advantage of this type of Free Time is that the programmer doesn’t have to sell his idea. I have seen countless hours wasted by people gathering information, preparing presentations, trying to “get on someone’s calendar,” and selling, selling, selling. These “let me sell you on my idea to try” efforts waste the time of not only the programmer, but also of the people who have to either give or withhold permission.

I recommend you try this type of Free Time. I find no magic in the numbers 10% and 20%. There is good in almost any percentage of time or amount of hours. I do find magic in the basic concepts:

• experiments are done outside the product and project
• successes are integrated into the product and project using established procedures (NO SHORTCUTS FOR ANY REASON)
• no time is spent selling the idea to gain permission

Footnote: A form of this idea was related to me in private correspondence with consultant and author Jerry Weinberg (http://geraldmweinberg.com).