The Eclectic Technologist

I like cryptograpy. The math is interesting. More importantly, crytography has become easily accessible to the average developer. The devil is in the details, like file formats. Faced with another potentially time consuming challenge, a simple and elegant solution was buried in the docs.

TeslaMotors is developing an impressive electric car. It plays to the strengths of electric drive: high performance and low operating cost. It uses 1000 lbs of Lithium-Ion rechargable batteries to drive a single, 248 horsepower polyphase induction motor. If you read my article on power trains, it’s easy to see how the Tesla Roadster can accelerate from 0 to 60 MPH in 4 seconds. It uses a two speed transmission for higher speeds, but one gear is all you really need for everyday driving. The range is about 250 miles, which is perfectly adequate for local driving.

Of course, it’s not cheap. I’ve heard rumors of prices above $70,000. Hopefully, economies of scale will reduce prices in the near future. With a little luck, larger auto maker might be inspired to develop thier own electric vehicle designs at a lower cost. It’s just a matter of time.

An article in the August 2006 issue of Scientific American titled The Expert Mind offers some interesting data on how to become an expert in any field. In summary, it takes about 10 years of concerted effort. Experts are not born, they are made, or so the research suggests. There are plenty of examples, mostly from study of chess grandmasters. Apparently, grandmasters are not necessarily geniuses in any particular respect. Rather, they just put in their time and become good at it.

Of course, there are no guarantees, but at least it suggests that if you apply yourself, there is a strong possibility of becoming an expert. In my opinion, it’s a lot easier if you enjoy those 10 years. If not, it’s more like work and more likely you will give up too soon. An interesting corollary is that it’s theoretically possible to be an expert in more than one field. I like that.

I finally got around to purchasing Microsoft Flight Simulator. Several months ago, I bought a Thrustmaster Top Gun joystick at a local computer show for a song ($5.00). It was used, but works great! The original sticker price was $70.00, well worth the gamble, IMHO.

Flight simulator out of the box has a few interesting planes, but only two helicopters: Robinson R22 and Bell Jetranger. I downloaded F-16 and Hughes/MD 500D models. Even though, I’m a pure helicopter pilot, I still like the idea of full aerobatic maneuvers with jet power and speed!

My initial attempts at simulated airplane flight were not a problem. I broke many altitude and structural limits, but at least I could keep it in the air without too much trouble. I was able to achieve reasonable forward flight in helicopters also, but hovering was a problem. After quite a bit of twiddling with the realism settings, I was convinced I had something set wrong. Both the R22 and Bell just did not fly like the real thing. The Bell clearly showed it’s sluggishness compared with the R22, but both were far too twitchy.

After some Googling,  I stumbled on Hover Control. They had some good tips on how to configure FS 2004 properly for helicopter flight. The most important appears to be the general adjustment in the realism tab. That should be one click less than hard right. That seemed to do the trick.

Now the R22, JetRanger, and Hughes 500 all seem to work more or less like the real thing. There are clearly some limitations. The engine and rotor tachometers don’t change at all under any flight condition. This is not a big deal under powered flight, but it’s a real problem during autorotation. The JetRanger model at least flares without power, but the R22 just slams into the ground with 100% RPM. Without response from the rotor tach, it’s hard to determine what the collective setting should be.
I haven’t been able to find any information on the Web about simulated autorotation. If you know anything about it, please let me know.

Back in the early 1990’s, I worked at an engineering firm that developed very sophisticated communications receivers for surveillance applications. The projects were managed by electrical engineers, they ran the show. As the receivers became more advanced, the embedded control software within the receivers increased in size and scope. This led to an interesting conflict between engineers designing the hardware and software developers writing the software.

In general, engineering responsibilities for a given project were broken down along physical lines. For one project I worked on, there were four physical circuit boards in the product:

• an RF board that contained the antenna input, mixers, and filters
• a frequency synthesizer board that generated mixing signals and CPU clocks
• an analog board for demodulation and power conditioning
• a digital board with a high performance floating point signal processor, 32 bit microprocessor, and an Ethernet interface

Four engineers were tasked to that project, each working on one board. I was responsible for the digital board and some of the frequency synthesizer. One of the engineers acted as the lead, making sure all the pieces fit together. The software side was a different story. First they started with two software developers, then three, then five, then as many eight. The engineers could not understand why it took so many software developers when only four engineers were needed for the same project. There were claims by the engineers that the software guys were poorly managed, incompetent, or otherwise did not know what they were doing. The animosity was exacerbated by rapid improvements in hardware sophistication and complexity in each new hardware design. Engineers skillfully managed this complexity, whereas the software developers appeared to flounder.

I spent some time with the software guys. I soon came to realize that they were not at all incompetent, in fact they were quite intelligent. Why did the software require so many more resources and take longer to develop? Part of the problem has to do with the maturity of each discipline. Electrical engineering is more than 100 years old, computer science is on the order of a human generation. The engineering development process is well established, following older, but similar traditions such as mechanical and civil engineering. Civil engineering is thousands of years old, and they still slip schedules. Why would a very young discipline, like software development fare any better?

Engineering disciplines have had time to develop effective processes and standards. Wheels are reinvented, but the sizes are standardized. In software, the few widely adopted standards that exist are often poorly implemented and suffer from fragile interoperability. Automated testing is only now becoming a recommended practice, but still largely overlooked.

Another key difference is the disparity in formal education. You cannot hold the title of engineer in most firms unless you have at least a four year degree in engineering. As a physics major, I was permitted to enter the ranks, but with some explaining. In software, computer science degrees are often a rare commodity. Some even believe that a computer science degree is not practical or even necessary. Formal education takes a back seat to practical experience. In engineering firms, if you didn’t have a degree, the best you could do is be a technician.

Recently, I’ve been working on applications for PocketPC and Palm handheld devices. In both cases, new devices are available in the market every month, but the software and development tools just don’t keep up. On several occasions, a particular device we were planning to deploy on a large scale reached end of life and was discontinued by the time the necessary support software and our applications were ready.

A colleague recently told me that one engineer can keep several software developers busy. Our demand for greater functionality and interoperability will probably continue to fuel that maxim. Software is like the wild west, anything goes and the best shooters win. Unfortunately, it’s hard to achieve high productivity when you don’t have electricity or running water.

There has a been a raging debate lately about static vs. dynamic typing. This is due in large part to the increase in webshare for Ruby and Ruby on Rails, and increase in criticism against J2EE. For the past several months, I have been trying to get to the bottom of the value proposition of each, and determine if one or the other is clearly superior.

One of the first salvos was fired by Bruce Tate, who I interviewed back in October of 2005. A former Java proponent, Bruce moved firmly into the dynamically typed, Ruby camp. I pressed him for specific, objective reasons why he felt dynamic typing was superior. He made some points in terms of expressiveness, but it wasn’t clear to me that static typing was dead.

James Gosling in his blog was flamed relentlessly by dynamic typists for his opinions on the value proposition of static typing. Much of the criticism came when he presented some of the weaknesses of dynamically typed languages. His most compelling argument lay in what he termed the inevitability of scale, meaning that dynamically typed languages ultimately suffer from performance limitations at some point. The comments on his blog became almost religious and partisan. They did little to advance the art or even expand the dialog. Some arm chair computer scientists even questioned Goslings competence. It devolved into a rediculous spectacle.

In my recent interview with Smalltalk enthusiast Ward Cunningham, I asked his opinion. Ward admitted that he once believed that dynamic typing was the only way to go, but with the availability of high quality IDEs like Eclipse, the burden of declaring types is not as great as it once was. After a long conversation, Ward made an even more interesting observation: the question is not whether static or dynamic typing is better, it is more about who you are writing code for. If you are writing code for yourself, it really doesn’t matter what you do or how you do it. If you are writing code for someone else or with a large group, it’s a different story.

Wards observation is another dimension of scale, not of computational performance, but of the audience for code. Based on my research, dynamic typing is far from a perfect solution for all problems. Tragically, little has changed since the introduction of Smalltalk 80. In the end, I have come to the conclusion that static typing won’t go away any time soon.

Have you noticed that modern cars and trucks have complicated transmissions, but 100 year old steam locomotives don’t? Why do we need transmissions anyway? Isn’t there a better way to drive wheels? A short introduction to drive trains addresses these questions and suggests ideas for more efficient vehicles of the future.

In 1989, Pons and Fleischmann announced controversial research results called Cold fusion. During that time, I was finishing my physics degree at the University of Maryland. I was also working part time at the Institute for Research in Electronics and Applied Physics, formerly the Laboratory for Plasma and Fusion Energy Studies. Needless to say, the faculty and staff at LPFE and the physics department were very interested. What followed next was one of the most provocative experiences I have had the fortune to witness.

I returned from EclipseCon 2006 with renewed respect for the many developers all over the world that are contributing to the Eclipse platform. Sure, there’s a lot of open source software out there, but Eclipse stands alone in terms of quality and imagination.

I chatted briefly with Todd Nielson, CEO of Borland. He had some interesting comments on the direction of software and the role of open source. Todd was with Microsoft for many years and confirmed that Microsoft has only two profitable products: Office and Windows. All others lose money or break even. SQL server might make a little money, though. This curious fact explains a lot of Microsofts business strategy.

I also interviewed Ward Cunningham, which was a lot of fun. The complete podcast of the interview is available on SQLSummit.com. After the interview, we chatted for an hour or more. We talked about all kinds of things, much of which revolved around novel applications for Atmel AVR microcontrollers. The most interesting thing I learned was the idea of trying many ideas quickly. This seems to be central to Wards thinking.

Over the weekend, I happened to run across the guts of a turbine from an Auxilliary Power Unit (APU). Upon closer inspection, I noticed chipped blades on the output wheel. The owner admitted that when he first started it up, he introduced fuel at low RPM. It ran, but several hot chips flew out of the exhaust. He shut it down and then learned of the catastrophic damage. “It was an expensive lesson” went the apology.

I’ve flown turbine helicopters on several occastions, but I never started them myself. The owner/operators were very concerned about hot starts. After seeing the potential damage first hand, I don’t blame them.