nerd1951.com

I recently read an article titled: The top ten dead or dying computer skills. Most of the items listed are obviously obsolete or proprietary technologies. A couple of the skills listed prove my opinion that most of the industry pendants can’t see past the walls of their corner offices. The problem with the trade press is that they have the myopic view that the only important computer applications are enterprise applications. In addition they seem to think that no development exists outside of application development. Are we done developing operating systems, compilers, interpreters and networking infrastructure?

My biggest objection to this article is the comment: “C++ and C Sharp are still alive and kicking, but try to find a basic C-only programmer today, and you’ll likely find a guy that’s unemployed and/or training for a new skill.” Oh really? Just do a quick search on dice.com will prove otherwise. C continues to be used in everything from Windows device drivers to language compilers and interpreters. Both Windows and Linux are written in C along with MySQL, the Apache web server and the PHP interpreter. Many of the cute little battery operated gadgets, intelegent automobile gadgets, and nifty home entertainment products contain large amounts of code written in C. But these are not IT or enterprise applications so they are not on the mainstream trade press radar.

The second dying skill that I take exception to is non-IP networks. The discussion again presents the IT centric view of the universe by discussing SNA as the only alternative. I’ve been involved in computer networking for almost thirty years and never touched SNA. Outside of the banking industry, government, and very large corporations SNA was never a very important technology. There is still plenty of non-IP networking technologies that are alive and even growing. As telephony and the Internet become increasingly integrated, SS7 (Signaling System 7) skills continue to be an important part of telephony. Zigbee and IEEE 802.15.4 low power low bit rate networking for industrial, medical and residential applications are just starting to come online and development of new applications for this technology will grow for the foreseeable future.

This is just one article but it is part of a larger trend that I see in the press and our professional organizations such as the IEEE Computer Society and the ACM. More and more the press, educational institutions, and professional societies see IT and enterprise applications as the only opportunities available for software developers. In doing so they are doing a disservice to those of us in the profession and even more so students who are considering a career in software development.

I hate to admit it but I do become set in my ways sometimes. I’ve missed major market trends several times. Voice over IP is one good example. I didn’t take into consideration that high bandwidth Internet connections would become so cheap and widely available so I thought VOIP would always have unacceptable voice quality. Now VOIP is a major industry.

I think I’ve missed a major trend in embedded systems. Most of my career I’ve worked on medium to large systems for telecommunications or networking. In my own studies I have focused on the skills for developing the complex software required by these systems.

I’ve had a good run with this strategy but the climate has changed dramatically in the last ten years or so. The telecom industry has emerged from the chaos that was brought on by the AT&T consent decree that broke up the old Bell System and the telecom equipment industry has matured. The number of telecom equipment manufacturers has dwindled to a few large players and there are very few telecom startups around. The bursting of the tech bubble at the end of the 90s signaled the end of major backbone network innovations. The established carriers were burned by a number of tech startups disappearing. Now the major carriers only buy infrastructure equipment from major equipment manufacturers.

When I think of where the exciting product innovations are happening, it’s all low cost, low power, wireless and portable. Not the complex software systems that I’ve worked on. There isn’t much going on the traditional telecom or networking that is interesting or exciting. The embedded market today is all about cute smart little gadgets. Some examples that I’ve worked on or have seen up close:

• A camera with and integrated motion detector for doing wildlife surveys. Attributes: Cheap (they lose a lot of them). Low power (battery life measured in weeks).
• A wireless mouse that uses accelerometers to detect motion so the mouse doesn’t need to be dragged across a surface to move a cursor.
• A fan controller for servers. Attributes: Cheap (Must cost less than having the server’s main processor do it) and low power (don’t want to add heat to the system).
• Wireless Remote control light switches and dimmers: I actually predicted this one. Attributes: Wireless, Cheap, low power.
• Tilt and pan and position correction platform for Kite Arial Photography. Cheap (things fall off kites and get broken), low power (Batteries are the heaviest component).

The enabling technologies are all maturing: powerful low power processors for under a buck, Zigbee wireless networking, power management techniques in hardware and software, efficient power supply technology and higher power density battery technologies.

The nice thing about these technologies is that there are so many niche markets for them Someone could make a nice living by coming up with several different little niche products and either OEM them or sell them on the web. Someone could also run a nice little boutique design service for these kinds of niche products. Or do a combination of both.

Ok, hardly anyone uses Ethernet bridges anymore. Since almost every application has switched to the Internet protocols and routers have gotten so cheap, MAC layer bridges are an obsolete concept. But it turns out that the data structures and algorithms that I used to manage Ethernet MAC addresses in a remote bridge are useful for number of cache applications, as I found out in an interview today.

This figure shows the application for a remote bridge. The problem is that you don’t want to send traffic over the WAN that doesn’t need to be forwarded to the remote LAN. The solution is a learning bridge. A learning bridge listens to the traffic to determine which MAC addresses are on the local network and which MAC addresses are on the remote network. In addition, you want to throw out any addresses that haven’t been used in a while in case someone moves a computer or maybe just to keep your table of addresses from getting full.

So the first part of the problem is that I need to look up Ethernet MAC addresses quickly so I used a hash table. Hash functions are never perfect and I had to use a relatively small hash table so collisions were likely. I used chaining to resolve collisions. In chaining the hash table is an array of linked lists. I took this approach because I knew that I would have to add and remove entries quickly and using chaining is the simplest way to do this.

Now to handle aging out old MAC addresses: Each entry had a second set of next and previous pointers. So each MAC address was actually on two linked lists. One from it’s position in the hash table and a second linked list was sorted by age. In both cases I used doubly-linked lists so that deletion from either end of a list or from the middle of a list is easy. Here is the data stored in each MAC address entry:

• MAC Address
• Local/Remote Flag
• Time Last Accessed
• Hash List Next Pointer
• Hash List Previous Pointer
• Age List Next Pointer
• Age List Previous Pointer

A final note about the hash algorithm itself, I found a paper that compared several hash algorithms for MAC addresses. Common types of hash algorithms were used such as CRCs. The study found that simply using the low order N bits of the MAC address was nearly as good as the most complex hash algorithm.

The problem with engineers is that they think they know everything or at least everything else is easier than engineering and they can figure out how to do it. I should know. I’m an engineer and I know that I can figure out how to do everything. At least I use to. After being in the tech business for thirty years though I’ve lost my ability to figure out how to do everything else too. Or maybe I’ve learned that the squishy things can be hard to do. It takes talented people to make the other things look easy.

What other things am I talking about? Things like sales, marketing, advertising, operations, and product design. By product design I mean designing the look and feel of a product; not the pieces that make it work. It takes expertise in all these areas to make a business a success.

The “I can do it all because that other stuff is easy” attitude starts in college. The engineering curriculum is so heavily weighted with math and hard science that we start to see all the other stuff as fluff. We start thinking the students in other majors are just skating through college. The other students are convinced that our stuff is hard too because they can’t do math and science as well. But how many engineering students could ace a poetry class or a drawing class? How many engineers can even write well?

Then when we get out into the workplace this attitude is often reinforced. We get into this us vs. them mentality. Companies run by engineers often totally miss the importance of other disciplines. It does not take an engineering degree to be great at sales. It takes a kind of talent that we engineers don’t always understand. I once knew a legendary salesman who was able to sell his company’s first product using a mockup made out of an off-the-shelf plastic package and a cardboard front panel. I know I couldn’t do that.

Then in the ‘90’s it got even worse because so many engineers started companies and sold them for a lot of money. All of these guys had the “success” to prove that they could do anything. But the track record for most of these technology startups isn’t so good. I can think of dozens of tech startups that were sold for millions of dollars that never produced a product that made it to market. The technical innovation was there but the rest was missing. Often the products were hard to use, missed the mark in the market place or were impossible to deploy.

The iPod is a great example of what can happen when all the disciplines work together. MP3 players have been around for years but it wasn’t until the iPod came along that everyone under the age of forty had to have one. MP3 players use to be tucked in a corner somewhere at Best Buy. What made the iPod such a success? It wasn’t outstanding technical innovation. One factor was its ergomatic design. The iPod is an MP3 player for everyone. Another factor was Apple’s legendary advertising and Apple’s marketing. Finally Apple has the production and distribution organization to put a product in every store in the world – great operating management.

Beautiful spring days like today are a big advantage of living car-free. I got off the bus a couple of miles short of my usual stop just to enjoy the walk to work.

Here’s a little story from work that show how some simple optimization can make a big difference. A coworker was working with one of our clients trying to enhance the performance of a network management system. They used a solid engineering approach, using the GNU profiler, gprof, to identify the bottlenecks in the system.

It turned out that there was a list of agents numbering in the tens of thousands that was being searched using a simple linear search. I suggested that they use a C++ Library map to contain the agent list. According to the C++ Standard the map is guaranteed to provide O(log(n)) performance. The map is usually implemented as a self-balancing binary search tree but sine the map is a standard component you don’t even need to think about this.

In about a day and a half the agent list in the network management system was re-implemented using the C++ Standard map. Search times improved about three orders of magnitude, which is what you would expect going from O(n) performance to O(log(n)) with tens of thousands of elements to search.

There are two lessons in this story. First my coworker was able to focus on a major performance bottleneck because the team used a profiling tool to find it. Second, since the system was implemented in C++, not C, using the map to perform the search was trivial because a tested, documented map object was available as part of the standard library.

I haven’t made much progress on Cannonball lately. One of the primary reasons is that I’ve been doing a little web applications work for friends.

It seems like you can’t discuss web applications these days without starting a language flame-war. I think that this is because there are many programmers that have just discovered Ruby on Rails. Ruby on Rails may be great but I’m sure there’s some warts there somewhere.

Being primarily a real-time embedded systems programmer has made me a pragmatist. Usually you have to make do with the tools you are given. If it’s a simple system with an 8 bit or 16 bit processor you are most likely going to use C or actually some non-ANSI compliant subset of C. If you’re working with a 32 bit system you may have the luxury of using C++. But it may not be a complete standard C++ implementation depending on your vendor. Java isn’t really an option for high performance real-time programming like the networking applications that I’m use to. But Java can be a fine tool for writing the GUI and control and monitoring portions of an otherwise real-time system.

In web development, the situation is different especially if you are running your own web host. You can use Java with any one of several frameworks, Perl, PHP, or Ruby; to name a few options. I’ve even developed web applications in C in the early days of “CGI” programming. Many of these options look great while you are playing with examples out of a book or reading about them in a trade magazine. When you actually put together a decent sized application every approach has its unique set of warts.

So, what do I use for web applications? If it’s something small and simple I use PHP because it is widely available and well supported by most web host services. If it’s a large complex web application, I’ll use Java with Struts and Spring because that’s what I’ve used before and I know where the warts are.

What about C#, VB and .NET? Well, if you’re running a web server on Windows, I think you’re wasting a bunch of money.

Things have been very quiet here at nerd1951.com lately. I’ve been without Internet service at home for over a week. I could have written the posts at home and then posted them to the site from work but somehow I just don’t feel inspired when I’m not actually online.

The story of my Internet outage is sadly typical. I came home Friday night to find just one blinking LED on the front of my cable modem, indicating that the cable connection was lost. I called the cable company and they sent out technician #1 in a few days. He arrive nearly an hour after the three hour window that they gave me. He hooked a test set up to my cable and mumbled. I told him that the cables are mislabeled and I had been disconnected once before when my neighbor moved out. He just ignored me. The he went outside to look at the cable distribution box. His assessment was that the drop was bad and that another technician would have to come out to replace the cable.

Today technician #2 showed up to replace the cable. After moving half of my computers and networking stuff away from the wall to give him access to the cable, I told him the same story about the cables being mislabeled. Then I added “But what do I know? I’ve only been working in networking for thirty years.” Well, technician #2 took me more seriously. I don’t think he was looking forward to replacing the drop cable. He hooked a device that we use to call a sounder to the cable. This device generates a signal that you can then pick up with a probe all along the cable. He then went outside and returned in about ten minutes. “You should be back in business.” He told me.

As I said, this is pretty typical but not just for the cable company. Years ago I had an ISDN line before cable Internet or DSL were available. The phone company must have screwed this connection up at least a dozen times, usually disconnecting my line to use for another subscriber. I’ve worked with phone companies a lot in my career and I can tell you from experience that their cable records are a mess too. Actually the DSL service where I work has a lot more outages than my cable Internet does at home.

Scott Adams, author of Dilbert once remarked, “Just remember, the guys working for the cable company are the guys who couldn’t get jobs with the phone company.” Being a former Baby Bell employee, I think Scott over-estimated the phone companies. They are all the same guys doing the maintenance.  The real problem is that they are over-scheduled and over-worked.  They never have the time to do more than the minimum required to close a trouble ticket.