Working Up

by Dwayne Phillips

One of the fundamentals in the engineering of systems and architecture is a “D” word that many loathe in our 21st century.

“Let’s hold off on this until we have to decide,” said a hopeful inhabitant of a post-modern universe.

Yes, there are things that we don’t have to decide until we know more. We should wait on those things that require waiting. Then there is the other 98.6% of the things.

Systems Engineering involves deciding. What are we going to call this? What are the boundaries of this? What are we trying to do? Who are we trying to please? How will we attempt this?

Decisions and deciding. If you are a “J” in the Myers-Briggs world, you decide. If you are an “F” or sometimes feel like an “F” but not always depending on … well, deciding is … what were we discussing?

Sorry about all this folks. To do something often requires deciding on what we are doing to something for someone in someplace at sometime with some method and all those other basic questions.

Don’t want to decide? Try another endeavor. We need lots of folks to try other endeavors.

by Dwayne Phillips

Find the right question. The answer will direct efforts. That is pretty basic, but it seems to work.

The purpose of this blog post is… Well, let me struggle with the rest of that sentence. In my struggles, let me find the right question. How about, “Why would anyone read this?” or “Why is this here?”

I find this to be a useful technique. Ask the right question, think, answer it, work.

• Statement: The purpose of this blog post is…
• Question(s): Will anyone read this? If yes, who? Why would they read this?
• Statement: The Requirements are…
• Question(s): What is the problem?
• Statement: The high-level design is…
• Question(s): In broad, loose terms, what is a solution?
• Statement: The detailed design is…
• Question(s): In precise, concrete, and specific terms, what is a solution?
• Statement: The implementation is…
• Question(s): What works?

The list could continue.

Try the technique. Start with a question instead of a declarative sentence.

by Dwayne Phillips

Let’s step aside from the usual thoughtful post and muse a bit a few days before Christmas.

Sitting in Starbucks as I write these posts, I sometimes see small children pushing open the glass door as they exit. They are as excited when they exit as when they entered. Starbucks has a lot of goodies for those under age five.

And most folks under age five are not as excited about the goodies as they are about going someplace with a special adult.

These small children push the glass door open with their hands. There is a push bar to open the door. That, however, is too high for the average three-year-old. Someone should have put a push bar down low for these children. The children wouldn’t leave their hand prints on the glass. The employees wouldn’t have to be on their knees to clean the hand prints off the glass. That’s a tough job.

Maybe not. After all, the little hand prints down low on the glass door are called a “leading economic indicators.” People, who will one day frequent Starbucks with money and demand for goods, are building fond feelings for the place. They will return.

And is the world worthwhile without the glee of three-year-olds?

One thing I notice is that when one of these happy fellows skips through Starbucks, all the older customers smile. There is something special about being in a place where people smile.

In addition to coffee and wifi, seeing three-year-olds skip with glee is one of the major reasons I come to places like this.

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.