Working Up

by Dwayne Phillips

This post is about the person who edits. Most organizations no longer employ an Editor, and that practice is fraught with imminent peril.

Consider The Editor:

An Editor is a professional who is the voice of a company, ensuring that all written materials are accurate and of high quality. They work with writers to improve their content to make sure it flows well while also educating them about best practices for writing well in general.

Some of us remember the day when newspapers had editors who did their jobs, i.e., they ensured high quality in everything published in the newspaper. Per the above definition, newspapers are not the only organizations that should have editors—I believe in editors at every organization.

Writing should be consistent. If we put “banana stand” in one place describing a business, we put “banana stand” in every place that describes that business. We don’t put “a little stall where we sell bananas” and other variations in various places. Newspapers and business are not writing mystery novels. We are communicating or at least attempting to communicate.

Writing should be better. Every day should be better than the prior day. The Editor shows a writer how the written word can be better. The writer takes the advice and writes better from that point forward.

There are many other ways to describe the Editor. There are many sources of information available for that.

Let’s all do better.

by Dwayne Phillips

This is yet another fundamental to providing systems that delight users. Have we validated that we verified before vacation? Or is it the other way around?

There was a time when verification and validation were so commonly used that we called it “V&V.” Then we wanted independent persons to perform V&V so we called it “IV&V.” Folks like to shorten that to “four and five” as the were reading the Roman numerals.

What was all the fuss about? One way we untangled all these Vees was:

• Verification: did we build the system right?
• Validation: did we build the right system?

Nowadays, we pipeline-ly DevSecOps agilely or something like that. Still, V&V is important.

Remember that old drawing about the tire swing and all its variations and what the customer really wanted? Here is one rendition of it. Providing a tire swing instead of a triple-deck something-or-other is an example of validation. The customer wanted a tire swing. Did we provide a tire swing?

Suppose we provide a tire swing, but when a kid sits in the tire, the branch of the tree breaks. ooops, we didn’t verify the specified specification that the system needed to hold a 50-pound kid. Can the 50-pound kid fit in the tire or did we provide a tire that was too small? That is another example of not verifying that we met a specification.

Silly example? Maybe, but over the decades I saw plenty of silly examples of systems delivered to users that just plain didn’t work. Worse, I’ve seen plenty of systems where the user took one look and walked out of the room.

Build the right system and build it right. Back to basics. We can do better.

by Dwayne Phillips

This is a reminder of one of the fundamental documents or documentations in creating systems that delight users. It is the Concept of Operations.

First things first. We want to provide a system that delights users. Where do we start? Let’s talk with the users; watch the users; learn from the users, and speak the language of the users.

Then, let’s record what we have learned about what the user does and what the user wants and needs. That recording is the Concept of Operations or CONOPS. The CONOPS can be a written document. It can also be a session of a podcast. It can also be a video. It can also be anything we can imagine.

There are a few characteristics:

• Describe the user’s day and how a system will fit in that day.
• Use the user’s language.

Here is a suggested question:

• If you had 1,000 people in the back yard helping you do your job, what would you do and what would they do?

The CONOPS does not describe the technology inside the system. The only technology mentioned is that which the user is already using. This is one of the more difficult aspects of the CONOPS for the technical team. We just can’t seem to step away from our wonderful technology.

For example:

• My car stalls at a traffic light. I say, “Stalled, help.” Within a couple of minutes, my car is on the side of the road out of everyone’s way, someone is giving me a ride to work, and someone will get my car to the repair shop.
• I come home tired from work. I say, “Dinner for two prepared in less than 30 minutes.” A recipe pops up using only the groceries in my house that meets the needs I said.
• I’m eating dinner. If someone important to me calls me on the phone, it rings. I know it is important. Otherwise the phone takes a message.

Keep it simple. Keep the user at the center. Don’t try too hard. There will be plenty of time later for trying really hard.

by Dwayne Phillips

The ability to read a product catalog does not make a person an engineer or an architect or someone who can think and reason.

I have encountered this for 30 years. It is as if someone had a cue card in their hand. They spew product names. Things like:

• Kafka
• HDFS
• TensorFlow
• Notebook
• Azure
• AWS
• Databricks
• Snowflake
• Kubernetes

The list can go on and on. These are all fine products with excellent places to use them to solve problems.

These, however, are implementation details. They are not designs. They are not architecture. Reading lists like this does not show the ability to think and reason. Those things (thinking, reasoning) are necessary for being an engineer or an architect or someone with something beyond the ability to read a product catalog.

by Dwayne Phillips

Sometimes it is better to see the Eiffel Tower from across town instead on being on the Eiffel Tower and seeing the slums.

I’ve seen many photographs of the great pyramids in Egypt. I have only seen a few photographs of the city next to the great pyramids. Yikes. I prefer the view of the pyramids from the slums. The same is true for the Eiffel Tower, the Washington Monument, and so on.

Do we want to see something from afar or be inside of it? We use systems at work. We have to be inside those systems to use them. What is the view from inside the systems? Let’s consider that when we build the systems. Does it look like a slum to the folks doing the real work? That shouldn’t be the case.

Who wants to see a slum eight hours a day? If we are going to spend a third of our life inside the systems, let’s improve the view.

by Dwayne Phillips

We aren’t as smart as we assume. Sometimes we need to do the simple things first before we move forward.

“Can we introduce ourselves before we start?” I asked at a meeting.

“No, we know each other here,” said the person presiding.

We introduced ourselves first. The person presiding was thrilled to know that I was Dwayne Phillips. He had been trying for weeks to contact me.

We introduced ourselves first. We didn’t know as much as we thought we knew. Learning what we didn’t know was a major breakthrough.

Sometimes we need to:

• introduce ourselves
• draw something on the white board
• hand out paper materials
• use name placards on the table
• give each other business cards with contact information
• explain the obvious things

The list could go on. “We’ve got this, we don’t need to…” Perhaps that list of things we don’t need to do are the things that we absolutely must do.

by Dwayne Phillips

What are you talking about? What level of abstraction are you discussing?

There are levels of abstraction. A car moves me from here to there. A car has an engine, a transmission, wheels, and fuel. An engine has spark plugs and belts and hoses. A spark plug has a housing, insulator, and electrodes. These are levels of abstraction. If someone asks me about a car, I should probably not first discuss the electrodes on the spark plug.

This is pretty obvious, right? Obvious is in the eye of the beholder.

Let’s convey information better. What level do you wish to understand? Let’s decide on the level before beginning the discussion. Let’s just discuss that level. While discussing a level, we may wander to one level above and one level below to enhance understand. No more, however, than one level. We don’t jump from an engine to insulators. We don’t jump from a system to which scheduling package we are using in software. That is a jump of several levels.

Let’s keep it simpler. Note, we cannot always keep it simple, but we can choose to keep it simpler and improve understanding for everyone.

by Dwayne Phillips

Busy at work? But are we doing the real work?

Consider for a moment the “fast food industry” in America. I think we Americans invented this endeavor. What are the key words? I believe #1 is “industry” and #2 is “fast.” The concept of “food” is … well, not so important.

This is an industry. The main component is logistics. Move the things to the right place at the right time with a minimum of space devoted to holding inventory. The average food distribution location (we used to call these “restaurants”) has surprisingly little storage capacity. No trucks arrive, no food in a day or two.

This is fast. In and out. We complain if in and out are not less than two minutes.

Food? Preparing and serving food with love? Are you kidding?

The real work of preparing and serving food with love is gone. The actual work is industrial-grade logistics and precision timing.

Now consider your workplace. What is the real work? Caring for the sick? Securing the nation? What is the actual work? Staying awake in meetings and writing reports that are redundant with everyone else’s reports.

Are we doing the real work or something else and pretending? That is up to us.

by Dwayne Phillips

Lots of things to do. Which do I do first? Perhaps I go with the worst first.

When my sons were little, they had tactics about the order in which they ate their food at dinner. One tactic was “worst first” in which they ate their least favorite food first so that they ended the meal with a good experience. Kids.

People have studied job queuing theory (and how to spell queueing queuing) for many years. There are many tasks to do, which do you do first? There is “first come, first served” and “save the best for last” and “the squeaky wheel gets the grease” and “age before beauty” and the like.

My “do worst first” seems to work for me these past couple of years. I am going to write a few things like blog posts. Some have been in the “I’ll get to it” list for a while. I need to do them, but really can’t find the energy. Others are easy and fresh and will pop out in a minute. If I do the easy ones first, that saps my energy for the moment and I don’t write the difficult ones.

The easy ones are easy. Do the worst first. Once done, the easy ones still pop out because they don’t require much energy.

Again note that this is what has worked for me the past couple of years. There were other times in my life when other queuing ideas worked better for me. Find what works best for you at this place at this time and use it.

by Dwayne Phillips

It may be a good idea to have your friends test your system.

Who should test your system? Who should tell you what they think about your idea? Who should read the manuscript of your novel?

Friends or a “friendly audience” may be the answer to these and related questions.

Consider the opposite—let a grouch or someone who hates everything you do perform the above. They may come back and say, “Your system flopped. Your idea stinks. Your novel is awful.”

Now what do you do? Well, that grouch who hates everything I do hates everything I do. Of course that grouch hates my system, idea, and novel. I hate that grouch more than ever.

Not much of an outcome.

What, however, if a friendly person or a close friend tells you that your efforts flopped? They like you and usually like everything you do. This time they don’t like what you did.

Now you have some valuable information.

Of course, your friends could tell you everything is wonderful when it isn’t. They could be so friendly and nice that they won’t be candid with you. That is a risk. If they tell you all is well, move on to another critic. If they tell you, “Sorry, I don’t want to ruin our friendship, but this isn’t very good.”

Now you have some valuable information.