Category: Uncategorized

When I first started out in software engineering during the ’80s, I had a talk with an older McDonnell Douglas engineer. Among his various amusing anecdotes from the Apollo moonshot era was his recounting of the Persian Rug Theory. Being wide-eyed and curious, I asked him what the heck the Persian Rug Theory was and how it pertained to software engineering.

Here’s his story: Hundreds of years ago, when Persian rugs were au courant with the social set, rug buyers were careful negotiators and would look for any reason — say, the use of two different wools– to undercut the price on a rug they were considering.

What the rug makers might learn to do — say, when making other such rugs, elegantly weaving together two different sets of raw wool whose coloring wasn’t a perfect match — would be to put in a tiny defect. It’d be off to the side and wouldn’t detract at all from the gorgeousness of the rug, but an expert eye would be sure to notice it. As the rug maker expected, the rug buyer would become fixated on this unimportant imperfection in the effort to get the best price and would thus miss completely that the coloring across the rug was just a tad off. Both maker and merchant would be happy with the final selling price, and the eventual owner at home would be happy with their Persian rug.

The Douglas gent told me that in software, when you are passionate and really believe in what you are doing, there can be times when you know the right things to do, but the powers-that-be might not have the vision. When you want to get functionality included that you know is crucial but management doesn’t understand, it’s much easier to get the functionality approved if you purposely put in a small but obvious problem. It might be a spelling error, a wrong copyright date, or an incorrect address.

Does the Persian Rug Theory actually work? Well, all I’ll say is that the theory is part of software lore, and what I build always includes all the necessary functionality. The rest I leave to you.

The Kobayashi Maru simulation is from the original Star Trek television series, and later showed up in the movies in Star Trek II: The Wrath of Khan (which is still the best Star Trek film ever).  The Kobayashi Maru is a no-win training scenario used at Starfleet Academy to test a starship trainee’s resolve and examine their decision-making process. Do you save the people on a doomed ship or risk intergalactic war and maybe the death of every one of your crew? Either choice you make is a doomed choice, but the choice reveals your character. The only person to ever beat the Kobayashi Maru simulation was James T. Kirk, who went on to command the starship Enterprise. To beat this test, he changed the rules; he hacked into the main program and changed its parameters. The logic was that he didn’t believe in a no-win situation.

When I talk to other programmers and engineers at computer shows, I realize that I am in a unique position of working for a hardware manufacturer and also making software that talks to the same devices. If something comes up and doesn’t quite work within the rules, I can change the rules within the firmware of the box. It gets a little frustrating when I talk to people about interfacing our devices to open source or commercial projects and they dismiss us because we don’t have a certain feature. I do take comfort that most people don’t realize that I can change our boxes’ firmware, the actual API in the box AND the software that talks to it. There is no such thing as a no-win scenario when you have these tools at your disposal.

I first became aware of this power many years ago when the company I worked for made serial/parallel-based printer-sharing boxes. You could change the target printer by sending a string of characters (I believe it was [:]P<cr><lf> for parallel and [:]S<cr><lf> for the serial printer). We made a DOS TSR program to help issue these commands and also a Windows-based program. In the Windows-based program, we used the “generic text” printer driver, which sent exactly the characters you wanted to send without any of the printer’s native page markup language commands. A problem arose when Microsoft went from Windows 2.11 to Windows 3.0; the generic printer driver now ended all output with a <formfeed> character instead of <cr><lf>, so when a customer tried to change printer output on our device an extra sheet of paper came out of the printer. Instead of trying to contact Microsoft and complaining about this change (which we knew would go nowhere), we just changed the rules. We modified the firmware in our printer-sharing box to accept both <cr><lf> AND <ff> characters at the end of any command.

More recently with our “Out of Band” serial console and “Power Distribution” units, controlling them with automation packages was daunting at best—you could use a package’s generic shell control modules to issue cryptic commands to our devices. So, again, we changed the rules: We have added a growing set of APIs to all of our devices, which interacted with our modules we created and have been adding to the Ansible project.

My long-drawn-out point: Try to change how you look at a problem when you encounter a roadblock. Think outside the box. If there is an open source project or a type of a device that doesn’t do what you want it to do, get involved and add the functionality to make it work. For open source, download the source from GitHub, play with it and add the things you need to make your life easier. If a device you are using would be perfect if only there were one more feature, contact the manufacturer; most of the time they will be thrilled to get a phone call from customers who want new features (especially if you reach the engineer who helped make the device).

When you change your way of thinking from a programmer to an engineer, that opens up unlimited combinations of possibilities. Be a Kirk.

What does Made in the U.S.A mean to you?

You may see products stamped with carefully crafted terms such as “Engineered in the USA”, “Designed in the U.S.A.” or the “Inspected in the U.S.A”.

Personally I don’t see it as a marketing spin or even a nationalistic moniker. When I buy something critical for my infrastructure, Made in the U.S.A. means that Engineering, Manufacturing, Service and yes, even Sales are all in close communication with each other. When the operation is in multiple countries, across four time-zones separated by six thousand miles, things don’t get done quickly or efficiently. The first person a customer talks to should not be an apathetic person who is just trying to fill the quota mandated on them by upper management who they have never met and never will because of the tremendous turnover rate.

When I put something on my network and a problem arises or a vulnerability shows up, I want the piece of mind that it wont be months before i get a resolution to my concern.

In the company I work at, Western Telematic Inc., we make Out of Band console and Power Distribution Units and is located in Southern California, in fact we have been located in Southern California for fifty years. When I say WE, I mean every piece of the process, Engineering, Manufacturing, Service and Sales.

When you call in for service you will either get Mario or Andy, if they cant solve your issue, they will walk down the hall to Engineering, if something needs to be checked with production, we go downstairs to the manufacturing floor. Right across the hall from them is sales so you can be contacted right away.

The Engineering group has been together for a long time, long enough so that if we look at a piece of code you know who wrote it by the style of the code written.

There is a reason WTI has a five year warranty on our devices, along with free firmware /software upgrades.