Working Up

by Dwayne Phillips

If we work hard enough and smart enough to the solution, we often find the solution collapses to something small and simple.

At the end of all the work, we find the solution. The solution is messy, but it is a solution.

Then we go home.

Then we come back to work on Monday and see the heart of the messy solution—the real solution.

The real solution is small, simple, and much better in many ways.

Why didn’t we see the real solution in the first place? Why did we spend so many resources to find a messy solution when the real, small, and simple solution was right in front of us? We aren’t smart enough to do that. No one is.

The real solution is far more simple, small, brief, clear, understandable, manageable, etc. The real solution only comes after we work hard all the way through everything.

There is a trick to this: work all the way through the problem without burning many resources so we find the real solution cheaply.

That, however, is a trick, and I for one don’t know how to do tricks.

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.

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.

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.

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.

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.

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.

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.

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.

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