Working Up

by Dwayne Phillips

Systems engineering consumes resources. It isn’t “real engineering.” It, however, is usually necessary.

Systems engineering—one part of it—enables us to record what everything is and what everything does. But we already know that, duh! Or do we?

Consider an organization with three or 33 software systems.

• What does #1 do? #2?…#33?
• How does #13 differ from #23? from #33?
• Are there common parts? Unique parts? What are they?

Can we answer any of these questions with CERTAINTY? And CERTAINTY means if you answer one question wrong you don’t get paid this week. Well? Certain?

This is one result of not performing systems engineering. A group of persons starts with a basic problem and a basic system. We understand it. We hold it all in our heads. One day we awaken to a large group of persons (What is that new guy’s name? What does he do?) and a large number of large systems (What is the purpose of the TPS report?). The only persons who know what they are doing work in the Redundant Department of Redundancy.

Life at work isn’t funny or fun anymore. The resources consumed keeping track of everything and tracing everything to something worthwhile are worthwhile.

by Dwayne Phillips

Beware of those who provide large numbers. Is anyone asking, let alone answering, the next question?

Many times in my endeavors I have heard persons proudly quote large numbers. “We are bringing in gazilli-tera-humongous bytes of data every day!” “We can access the data on every grain of sand on every beach and sand dune in the world!”

WOW!

But the next logical question—the one infrequently asked in one form or another—is, “Now what happens?”

What will we do with all that stuff prefaced by that large number? Is anyone interested? Can we find the answer to someone’s question in that large, large accumulation of stuff? Do we have an attic or a basement large enough for all that?

Large numbers are large. Large things can be impressive. Large things, however, often lead to nothing but large waste. Before touting the large numbers, lets try to find the answers to the next questions, which are often equally as large.

by Dwayne Phillips

Makers of systems might consider an old, old list when considering the -ilities or non-functional requirements.

“This system is fool proof!” said one person. The other person replied, “I know some pretty big fools.”—paraphrase from something written somewhere at sometime.

Considering the “fool proof” system brought to my mind a few questions like, “Is it greed proof, lazy proof, etc.?” Which led to the concept of the Seven Deadly Sins, which in one form or another are: lust, gluttony, greed, wrath, sloth, envy, pride.

Can we build systems that withstand any or all of these seven? But the people who use our systems are professional fill-in-the-blanks, dedicated to fill-in-this-blank-as-well. Hmmm, I’ve heard that before. I’ve also heard head shaking and eye rolling when those who said those things were filled with shock and dismay.

These things fall under non-functional requirements. The best-known of which is “easy to use.” “Our systems are easy to use,” claim the builders of systems. If it isn’t easy to use, the wrong person is trying to use it.

Perhaps the fool or angry person isn’t the right person to use the system I built. I can always claim such regardless of anyone believing me. Building systems for persons isn’t easy. We all have so many faults and bad days and such. Let’s try to be a little more forgiving.

by Dwayne Phillips

Teacher? Not me. Of course me. Understanding what it means to teach reveals that almost all of us are teachers.

teach: verb, show or explain to (someone) how to do something.

Have you ever told someone something that they didn’t know before you told them? Congratulations. You are a teacher.

It really is that simple. It really is that common. It really isn’t much more complicated than that.

Presentation skills? Organization skills? Yes. These exist and they enable teaching for longer periods of time, which is necessary when trying to convey subjects that require more time.

Teacher? Yes. Almost everyone I have ever met is a teacher—whether they wanted to be or not.

Once we move past the definition, we can move on with the practice, and oh what a wonderful thing happens when we practice.

by Dwayne Phillips

Sometimes we can do it right the first time. Other situations render this nearly impossible. Let’s understand the difference and manage accordingly.

There is an old saying that goes something like:

We don’t have time to do it right, but we seem to have time to do it twice.

Some say the origins of this go to basketball coach and philosopher John Wooden. Others say its is so old it has no originator, but is muddled in there with all the other famous sayings.

In our world of Agile development and Agile Scrummed this and that as a service, we always do it two or three times. In those cases, we plan to do it several times. These methods admit that we make mistakes, so we reserve a small amount of resources for the first time and save other resources for the second and third times.

In my experience, however, we aren’t really agile and aren’t really planning to do things several times. We make the same old mistakes and meta-mistakes and use “agile this and that” as a cover for such.

Perhaps we can “get away with” making the same old mistakes again. Perhaps we can fool ourselves into thinking that we can make the same old mistakes again. Perhaps not.

Things don’t have to be this way.

Do we have a known problem with a known solution? Plan to do it right the first time. Allocate sufficient resources with sufficient review steps to catch mistakes.

Do we have a partially known problem, i.e., an unknown problem with an unknown solution? Plan to do it several times. Usual minimal resources each time. Take advantage of the time between attempts to think.

We can do this. So let’s do it.

by Dwayne Phillips

Appearances are often deceiving. As managers, we know this, but…

A long, long time ago, I was sitting in a chair against the wall in a meeting. The important persons were huddled around the meeting table discussing what important persons discuss around meeting tables.

To this day, I have no idea what they were discussing. I was leaning back against the wall blissfully doodling with pencil and notepad. I drew pictures of trees and houses. Funny how I remember what I was drawing but nothing of the meeting.

After the meeting ended, one of the important persons at the table came to me and told me how impressed he was with me and my studious recording of the meeting in my notes. Wow.

It is pretty easy to look like you are working.

It is pretty easy to be working and look like you are napping.

Everyone knows these things, but we don’t all act like we know them. We chastise persons for not paying attention, for staring off into space instead of “working.” Why is that?

Looks can be deceiving. There is no rule preventing me from being the person who acts like I know this.

by Dwayne Phillips

Sometimes it is as simple as one word instead of another that can change everything.

Do we manage or cultivate?

Do we transfer or transplant?

Do we tell or till?

We could go on. Is the workplace a machine or a garden? Are our colleagues living, breathing humans or interchangeable cogs?

Persons hear the words we use. Let us consider them—both the persons and the words.

by Dwayne Phillips

Ask for information. Use it to change me—not the other person.

I teach classes on a few topics at work. The best thing I can do afterwards (a few days later) is ask one of the students questions: “What is this? What is that? How would you do this? What is the definition of that?”

(1) Listen.

(2) Act.

Both (1) and (2) are essential. Let’s focus on (2) in this post.

When the answer is incorrect (there are, unfortunately correct and incorrect answers to factual questions), how I respond is critical.

Two responses from me (there are many possible ones) are:

(a) What? Weren’t you paying attention? How could you miss that?

(b) What? What was I saying? How was I teaching? Why didn’t I communicate better?

The difference between (a) and (b) is the difference between “you” and “I.” I can change myself. I probably cannot change the other person. Refusing to admit such is my problem, and I should get to work on me.

The same goes for meetings, speeches, essays, blog posts, and just about everything else. I can blame the recipient or I can work on me. And I can work on me without blaming me, but acknowledging that…

To write is to be misunderstood. (The same holds for teaching, speaking, etc.)

by Dwayne Phillips

Jeff Bezos and Amazon have received much praise for their use of written essays at meetings instead of PowerPoint and bullet points. Great, but not new.

This is a good piece about Amazon’s use of written memos at meetings. Keep the thinking focused. Don’t waste time. Think. Communicate.

Excellent. Great. I love it.

That is why I used it back in 2003 on a government project.

I doubt I was the first. I know Amazon wasn’t the first, because I beat Jeff Bezos to it.

I didn’t become rich and famous, and neither did anyone else on the project. We did, however, save the taxpayers a few million dolalrs, and that was a pretty good thing.

by Dwayne Phillips

It is just a “figure of speech,” but perhaps we would understand better if we used the correct words in the field of artificial intelligence.

Here is yet another article about “building” a neural network. It is a good article that explain neural networks well. It shows some sample source code to do so. I like it.

All except this concept of “building.” This does not show how to “build” a neural network. It shows how to simulate one in software.

I would love to see someone build a neural network. That requires hardware (much of it analog, not digital). An actual neural network built by someone would be a joy to see (at least for me).

Until that joyous day, we will simulate them in software. I know, it’s just a figure of speech, but perhaps, just perhaps…