Working Up

Working Up in Project Management, Systems Engineering, Technology, and Writing

Working Up header image 1

3D? I Want 2D

May 2nd, 2016 · No Comments

by Dwayne Phillips

Call me too literal, call me too geeky, but I want to have actual 2D anything.

3D! 3D! 3D!

Everybody wants 3D everything. We want…

  • 3D printing
  • 3D user interface on the smartphone
  • 3D movies
  • 3D gestures for control of computers
  • 3D integrated circuits

The list goes on.

Silly me, I want to have 2D. Give me a printer that actually prints in only two dimensions. Yes, actual, real, true absolutely flat print with a height of Z E R O. When we can do that, we will really have something. We will be able to build computers with zero height. We can then fold these flat computers over and over again and still have zero height.

Can you imagine what we would have if we had computers that are as thin as, well, as thin as nothing? That would be something!

Sorry, sometimes I wax into the ridiculous.

→ No CommentsTags: Computing · Expectations · General Systems Thinking

My Customer and Me, and Our Difficult Problems

April 28th, 2016 · No Comments

by Dwayne Phillips

When confronted with a difficult situation with a difficult customer, it is often better to step back and ask a few fundamental questions.

The setting: I am a developer. I am building a system for a customer. The work is going poorly. We seem to make progress on some days, but most of the time we restart the work with great angst.

Let’s ask a couple of questions so that we can then ask better questions and possible work our way into a better situation.

  1. Are we discussing the developer’s problems or the customer’s problems?
  2. Are we discussing the problems or the symptoms of the problems?

The first question: My customer is not me. I cannot say, “My customer’s problems are my problems.” No, they aren’t. I can say that to try to establish a relationship with my customer, but it is not a true statement. We are different persons, we have different problems.

The second question: This one often confuses me. For example, “My problem is that I’m not getting enough sleep.” That is not a problem; it is a symptom. What is causing me to not sleep at night? The answer to that will point me closer to the actual problem.

Here is the summary advice. When I’ve been in these situations I hated hearing this advice because it caused me to think. Instead, I wanted quick, miraculous solutions. Too bad as quick, miraculous solutions rarely exist. Instead:

Get questions (1) and (2) straight, and then talk, but not before.

→ No CommentsTags: Problems · Reframe · Work

Neighborly

April 25th, 2016 · No Comments

by Dwayne Phillips

I encourage managers and other influence-rs to speak to their colleagues in the place where the colleagues are most comfortable.

I encourage managers and other to speak with each of their colleagues. I find two points here:

First, speak to your colleagues everyday. If nothing special is happening, talk about “the weather.” I use this expression to mean talk about anything. Your colleagues will learn that you like to talk with them. Those folks who study this type of thing call it “establishing a relationship.” I call it being neighborly.

Next, speak to your colleagues in their place. They are comfortable in their place. Look at their desk, the walls, everything. Notice what is present. Talk to them about their life, their interests, anything you see in their office. Again, this is being neighborly.

The opposite this visiting a colleague only when you want something from them. Some bad event has occurred and you need your colleague to do something for you. They learn that you only show your face on bad ocassions. You only bring bad news.

Who wants to be that way? Not very neighborly.

→ No CommentsTags: Authentic · Consulting · People · Trust · Uncategorized · Work

Buying and Building an Intel NUC

April 21st, 2016 · No Comments

by Dwayne Phillips

I replace a large home computer with a small Intel Next Unit of Computing.

Our kitchen home computer was failing, so we decided to replace it. A colleague had spoken to me about how he uses the small Intel Next Unit of Computing (NUC) machines. I did some research and bought a NUC5CPYH (yes, the product numbers drive me crazy). This comes complete with memory, a little SSD, and Windows 10 installed for under $300. Intel calls this NUC the “Grass Canyon.” I suppose that name means something, but the big deal is that out of the box you have a working Windows 10 computer.

But wait, there is more. Of course it doesn’t come with “enough” memory or disk space. Hence, I bought some memory and a 256GigaByte Samsung SSD.

Now the fun begins. Intel made a big mistake somewhere along the line in packaging these machines. They neglected to put a necessary cable in the box. The mistake is so big and common that there is a special page online that shows you how to get the cable. Here is the page.

Once the parts arrived, it was easy to assemble with a screwdriver. Viola! A little Windows 10 computer that fit in a little basket under the table that held the monitor. I then purchased a generic wireless keyboard and mouse.

I could have bought an all-in-one Windows 10 computer from HP or Dell for less money and less aggravation. I wouldn’t have learned as much, but those sources are excellent choices as well.

Now, all I have to do is wrestle with Windows 10. For me, a Linux install and use would have been simpler and cheaper, but this computer is not primarily for me.

→ No CommentsTags: Computing

Engineering the Software versus Banging Out the Code

April 18th, 2016 · No Comments

by Dwayne Phillips

There are major differences between engineering systems and “just doing it.” The consequences are both obvious and predicted.

For at least 25 years, I have heard and seen in action the mantra of “good enough software.” Get a partial solution, ship it, improve it.

Great stuff. Except time has shown that the good enough software wasn’t. One of the larger problems with the good enough software is that it C O U L D do more than it was supposed to do.

Systems that are engineered, and this includes software systems, have requirements. The final system meets all the requirements A N D does nothing else.

Let’s consider FTP (file transfer protocol). Per Wikipedia, “The File Transfer Protocol (FTP) is a standard network protocol used to transfer computer files between a client and server on a computer network.”

Great. Trouble is, there are other things you can do with FTP. Hence, people added all sorts of things to FTP to try to eliminate all the extra uses of it. Hmm, sounds like putting a band-aid on a broken arm, but please remember that I am old and have a funny perspective on some of these things.

This is a call for systems engineering—in this case, a call for software systems engineering. Banging out code has its advantages—showing what something can be quickly and inexpensively is one. It also has its disadvantages. We are living with billion$ in problems with the disadvantages with all our cyber security problems.

Bang out code for a demo. Engineer the software for a system. Please.

→ No CommentsTags: Engineering · Programming · Systems

Fun

April 14th, 2016 · No Comments

by Dwayne Phillips

Never by surprised at what some persons consider to be “fun.” Consider this when managing risk.

Recently, Microsoft put an Artificial Intelligence system called Tay on Twitter or something to learn how to chat. Some persons found it and taught it how to chat like a jerk. Microsoft wasn’t prepared for that and had to pull Tay down as fast as they could.

Microsoft failed to consider one simple thing:

You might be amazed when you learn what some persons think is F U N.

Some persons out there in the Internet thought it would be great fun to teach Tay how to curse and tweet racist jargon. Ha ha ha!

Why do persons hack through firewalls at the New York Times? Why do persons hack airline WiFi systems so they can Skype? One answer to these and the Tay question is that some persons see the challenge and the result as fun. They giggle with glee when they “succeed.” Ha ha ha, look what I did!

Let’s pull this back to project management because, after all, the project managers at Microsoft failed to do something. This is part of Risk Management. What could possibly go wrong with having the Internet teach our AI machine how to chat? One answer is that people would teach our AI machine how to curse. Oh, so let’s put some monitor in place and filter cursing and racism and other bad things.

Persons will do all sorts of things in the name of just having fun. Try to consider those funny little things when managing risks.

PS: I knew of one incident where a man pulled a fire alarm and turned on the fire sprinklers ruining thousands of dollars of personal property in the housing unit of a government training facility. When confronted, he asked, “When did this organization lose its sense of humor? Can’t you see that this was just a joke?”

PS: This lesson was first taught to me by consultant and author Jerry Weinberg.

→ No CommentsTags: Excuses · Fun · People · Risk

Doing the Same Thing Over and Over Again

April 11th, 2016 · No Comments

by Dwayne Phillips

Depending on where we draw system boundaries, we probably aren’t doing the same thing over and over again.

There is a quote attributed to Einstein about insanity being the act of doing the same thing and expecting different results. There is a debate among people who debate such things about if Einstein ever said that or if he was the first and so on.

For now, let’s sidestep the debate and the debaters. Instead, let’s consider whether or not we do the same thing over and over again.

Seven days a week I read the Internet and post items that catch my attention to a blog. I upload this blog using a bash script. I run the same script everyday, i.e., I do the same thing over and over again—and I get different results. I run my script while sitting in one of several local coffee shops. These coffee shops use different systems to connect the Internet to their patrons. These coffee shops also change their systems from time to time.

Oh, perhaps I am not doing the same thing over and over again. Perhaps I am using different access systems that change. Someone else, however, is making those changes. They are making those changes to part of my system that is out of my control.

Enough semantics; let’s get to the point. Understand the systems we use. Understand that there is much to our systems that are outside our control. While we don’t need to understand everything about these systems, we do need to realize our limitations and the changes that affect our desired results.

The world is inter-connected. Hence, the “inter” part of the word Internet. Keep our eyes and our minds open.

→ No CommentsTags: Starbucks · Systems · Technology

The Folly of Stack Programming and Developing

April 7th, 2016 · No Comments

by Dwayne Phillips

When you rely upon things from other people, you are sometimes greatly disappointed. This holds for programming computers.

Are you a “full-stack developer?” Do you argue about what a full-stack developer is? Have you been asked, “Given this problem, what stack would you use?”

Sigh.

Since the pre-historic times of computer programming, let’s say…oh, the eighth decade of the last century, we programmers relied on other programmers. Someone else wrote the compiler. Someone else wrote the libraries we linked. Someone else wrote the operating system. We implicitly trusted these someone else-s because that is how it worked.

Today, in our post (post(post)…)) modern world, there are many more of these someone else-s involved. These someone else-s wrote all the software in all these stacks. That is how it works. So what’s the problem?

Every now and then, about once a week, someone finds a problem in software written by someone else. They exploit that problem and soon their cousins are buying big-screen TVs using your credit card. Sometimes they exploit the problems and do some real damage to the world.

But this stack is used by a gazillion people in the world.

Yes, and perhaps we can run through the history of the world and cite a few other examples of lots of people depending on someone else who was quite disappointed.

I don’t advocate starting with a blank screen and writing your own operating system and up the stack. I do advocate a realistic approach to programming in any given stack. Analyze the risks for your situation.

Decide, don’t default.

I won’t be surprised this November to walk into a polling place and see computerized voting machines that are based on Windows 10. The day after the election, someone will show how easy it is to hack those voting machines. Of course it is easy. Those machines were built on a tall stack of software written by someone else.

→ No CommentsTags: Analysis · Programming · Risk · Systems

Unintended Capabilities

April 4th, 2016 · No Comments

by Dwayne Phillips

Systems built by persons often have more capability than intended. Someone will arrive who will find and use these.

I stumbled onto this story recently about persons in Angola who have limited Internet access. They found ways to use Wikipedia and Facebook that the creators of those systems did not intend. The systems, however, had capabilities, so these Angolans used them. These Angolans used Wikipedia to store and share full-length Hollywood movies. That was just one use of unintended capabilities.

I have recently studied a bit on Internet security and hacking into systems that people at one time deemed secure. The vast majority of these hacks are examples of finding and using unintended capabilities.

Did you know that if you… you can …?

And so the story goes.

This post could be a plea for better systems engineering where you build systems that meet user requirements and do nothing else. Those systems have no extra capabilities and no unintended capabilities. Those systems also do not exist.

I always go back to the numbers game. Builders of systems hire a group of smart, dedicated persons to build a system. Once out in the wild, another group of persons start poking at the system to see what else it might do. The second group of persons is usually several thousand times larger than the first. The second group has massively more numbers of persons. The second group always eventually “wins” (whatever winning means).

It is now the time to find the moral of the story. I suppose there are many morals. Here are a few:

  • Try harder at systems engineering
  • Hire a few thousand outsiders to pick at your system for a few weeks before releasing it
  • Be ready with a press release that puts a good spin on the persons who find your unintended capabilities
  • And so on

→ No CommentsTags: General Systems Thinking · Systems

The Price is Right (until it was wronged)

March 31st, 2016 · No Comments

by Dwayne Phillips

Often it is better to let people watch a game show at work while they eat lunch.

Here is a sad but true story.

In the early 1990s I worked in a big computing laboratory. At one end of the multi-thousand-square-foot facility we had a “conference” room. This room had a sink, a refrigerator, and a TV. Yes, people used the conference room as a lunch room. They would turn on “The Price is Right” back in the heyday of Bob Barker. They would spend an hour each weekday eating together and watching a silly game show.

These people became friends as they would eat together and idly watch Bob Barker and overly excited contestants. Side chatter wandered to side topics. These colleagues became friends who knew one another as real people—not just boxes in an org chart.

There is a funny thing about friends, they tend to help one another and grease skids so that things get done much faster and much better.

People who are friends tend to work together.

Someone, who didn’t like Bob Barker and also didn’t like the people who would watch Bob Barker, learned of this daily gathering. It is unfortunate that this someone had been mistakenly elevated to a position of authoritative management.

That someone declared with great authority and zeal that, “We’ve got to put an end to this!”

That someone proved their authority and had the “Price is Right” and lunch banned from the conference room. The persons who had watched the show together remained friends, but gradually moved to other jobs and were replaced by people who weren’t friends—they were boxes in an org chart.

Please refer back to “People who are friends tend to work together” and notice the last two words: WORK and TOGETHER. Those two habits vanished from the computing lab. The results were predictable and predicted. Work and quality fell.

That someone, who didn’t like Bob Barker and also didn’t like the people who would watch Bob Barker, moved on to another position of management to wreak havoc there as well for years to come.

I suppose it is time to summarize this story and find a moral or something. If you have read this far, you have probably drawn your own conclusion, but here is one or two of the conclusions that have come to me in the 20 intervening years.

  1. Let people at work become friends—it pays.
  2. If you find someone who wants to end friendships at work, move them out quickly before they ruin everything.

→ No CommentsTags: Management · Work