About 14 months ago I bought a name brand laptop from a well-known retailer.  I declined the extended warranty so I should not have been surprised when the power jack inside the laptop cracked 63 days after the warranty expired.  The damage was disabling as the external plug had to be propped at a severe angle to charge the computer.  Unfortunately it would have to be repaired.

A quick call to the retailer told me I was in trouble.  They said the repair would require replacing the motherboard and that could only be done by the factory service center on the other side of the country.  Undaunted, I called the service center – more bad news.  The process was to send them the laptop and a $99.95 evaluation fee plus $20 shipping.  In a little while they would get back to me and tell me the actual cost of the repair.

Forget them!  I’m an engineer!  I can fix this thing myself!

After a couple of call transfers, pressing 1, 3, 1, 1, #, 3 – getting disconnected – calling more numbers and pressing more keys I was able to order the power connector for only $37 + $8 shipping.  I declined the $24 overnight delivery option, but the connector arrived the next day anyway.

I excitedly opened the package but was horrified to see the connector had an attached Frankenstein of a cable.  It was about 12 inches long with two right angle bends.  I said to myself, “This can’t be good”.

More than 30 screws later my table was covered with a mostly disassembled laptop.  The connector was not mounted on the motherboard but was attached to the frame.  The motherboard was still partially attached but I was able to pry it up enough to remove the old Frankenstein cable and route the new one.  I congratulated myself for being an engineer and began reassembling the computer.  A little while later I plugged in the charger.  As the battery charging light came on I thought, “That wasn’t too bad”.

But wait!  The computer would not turn on when I pressed the power button.  I disassembled the computer again but saw nothing wrong.  The power button worked fine, the battery was being charged, but no power was reaching the motherboard.  I reassembled the laptop hoping against hope that there was some interlock that required full assembly before power-up was allowed.  No such luck.  I walked away from the laptop to watch some late-night TV, but the problem wouldn’t leave my head.  Did I crack the motherboard while lifting it to route the power cable?  Did I somehow damage an interlock?  Was something being shorted?

By the next morning I decided the most likely problem was that I inadvertently broke or disconnected a cable hidden under the motherboard.  The following weekend I again disassembled the laptop – this time completely.  There, underneath the motherboard, was a ribbon cable that had been pulled from its socket.  It was quire short and I had a bear of a time reconnecting it.  Eventually I got everything back together with some fresh thermal paste on the heat sink and fresh Loctite on the screws.  The laptop was finally back together and working.

So, what did I learn from this adventure?  One thing is that being an engineer makes you do stupid things.  No normal person would ever think about disassembling a laptop computer.  After this adventure I’ve become as smart as a normal person.  Working on this was such a pain in the butt that next time I’ll just throw the laptop away.

The other thing I learned was that cheap assembly labor makes for really, really bad designs.  You have got to be kidding me.  This was very much a name brand computer but the inside was a plumber’s nightmare.  Two more weeks with the CAD group would have reduced by half the 70 to 100+ screws that hold everything together.  Another week of CAD improvements and half of the 20 or 30 connectors would be gone.

I think one unexpected benefit of foreign assembly of products is that the design engineers don’t understand the language.  They don’t understand the cruel jokes the assemblers make about their convoluted mess of a product.

Look ashamed boys.  Look ashamed.  I’ve seen inside your product and you have every reason to be very ashamed.

Doctors and Engineers are two of the most respected occupations in our society.  While both are highly educated and highly intelligent, in my opinion there are far more differences between the two careers than similarities.  For example, an engineer may be expected to start with a blank sheet of paper and design a complicated system, but a doctor starts with an incredibly complicated system (the human body) and tries to figure out why it’s not working right.

Both groups can have substantial egos, but the working environment accommodates this very differently.  A doctor’s self-esteem may be regularly bolstered as numerous patients view him as a savior, but in some companies engineers’ self-esteem can be undermined every day by management attitudes and demands.

There are other significant differences in the working environment.  In the office of a private practitioner the word and will of the doctor is final.  Even in a large hospital doctors are rarely contradicted or overruled.  Doctors are mutually supportive and hesitate to criticize each other in public – perhaps for the purely practical reason of avoiding lawsuits.

In contrast, engineers rarely get to make visible decisions.  They can make dozens or hundreds of decision on which components to use and how to compose software.  However, the business and marketing groups make the decisions on visible issues like which bugs to fix, which features to implement, and when the product works well enough to ship.  In this sense, engineers are more like assembly line workers than doctors.  They are told what to do and often reminded to work harder.

With respect to safety and security, a rogue doctor can sicken or kill a few people by misdiagnosis or administration of inappropriate drugs.  Major damage is greatly limited by many safeguards and checks from insurance companies, federal and state authorities, and highly trained pharmacists who distribute the drugs.  In fact, there is an entire industry focused on, and making a great deal of money from, ensuring doctors act properly – or suing them if they don’t.

One bad or malicious programmer, on the other hand, can endanger hundreds, thousands, or more.  They can take down a power grid, disrupt stop lights, or simply do a bad job implementing automotive anti-lock brakes.

It is interesting that engineers have so little comparative power and authority yet can cause so much harm and damage.  Indeed, inappropriate or malicious use of a compiler can be far more dangerous to a much larger portion of society than could ever be endangered by any doctor not working on germ warfare.  One doesn’t even have to be a technical professional to acquire a compiler or similar tool.  Such tools give ANYONE the ability to hack into credit card records, banks, or the national defense network.  There are no checks and no safeguards on the usage of these tools.  The man on the street has unrestricted access to compilers and other highly dangerous software tools without demonstration of any need and without an authorization or “prescription” from a well-trained professional.

We have created a society that requires a doctor’s prescription for a great amount of the truly effective medicine (see my blog “Saving REAL Money on Healthcare“) but allows any untrained and unsupervised clown – perhaps with a criminal record – to acquire potentially far more dangerous computer equipment and tools.

Why is it, in general, doctors are the kings and queens of their domain but engineers simply follow orders handed down by the business group?  Why is it that medical students must serve an apprenticeship (internship) before they are allowed to practice medicine but most young engineers receive ad hoc on-the-job training from the (perhaps qualified) guy in the next cubicle?  Why is it that we are so well conditioned by our culture that the social structure I described seems normal and acceptable?

Perhaps when we can answer these questions we, the engineers, will finally be worthy of being as highly regarded as medical doctors.  Until then our masters will continue to tell us the bugs to fix and when we will finish.

The other day I went to the gas station and encountered a shiny new pump.  It had a liquid crystal display to interact with me and on top of the pump was a medium sized monitor.  My first thought was “wow – nice”, but that first impression didn’t last very long.  I was a little disappointed with the responsiveness of the display and authorization of my credit card seemed to take longer than usual.  I began thinking the company had not gotten their money’s worth from the engineering department.

My thinking soon degenerated into unkind thoughts as it took FOREVER to fill my car.  It was not just the electronics that was sluggish.  The gasoline was being dispensed at an intolerably slow rate.

Finally, my car was full.  As I removed the nozzle from the car I half-noticed that the advertisements that were droning on the monitor had started over.  I don’t go to gas stations to be entertained or be educated and I sure don’t go there to watch advertisements.  As I was hanging up the pump the conspiracy theory part of my brain became active.  Could it be that the slowness of the pump was not the result of bad engineering but of the engineering team adhering to marketing requirements to delay the customer?  Was I purposefully held captive at the pump so they could show me more advertisements?

My feelings of pity for the company turned to dismay.  I no longer thought the company spent good money to get an engineering piece of junk.  Rather, the engineers did a fine job on this pump and built it just like the marketing department wanted it.

Am I being more paranoid and delusional than normal?  I don’t think so.  We are fortunate to live in a time when the raw power of economical hardware and the sophistication of software can produce miracles.  Unfortunately, too few products and services get to flex their technological muscles without being crippled in some fashion.  We are certainly on the verge of a “Brave New World”, but I can’t tell if this new world will be wonderful or horrible.  Will we have unbelievable health and convenience?  Will we have knowledge and facts at our finger tips, or will facts cease to exist as our every interaction with the world is flavored and colored by the whims of those who control the information outlets and connections?

I fear it is possible that some of the scenes of Steven Spielberg’s Minority Report will be proven uncomfortably prescient and we will be fed a non-stop deluge of individualized advertisements, polls, and surveys.  Out time will be subtly consumed as customer service lines force us to wait as they are ALWAYS experiencing “unusually high call volume”.  While we are waiting we will be told of their latest sales and how much they value our business.

The machines that do all of this, like the Skynet Terminators, will feel no remorse and no sympathy.  They will simply do what we, the engineers, designed them to do.

… OH!  The Shame!!

Engineers and engineering managers generally agree that the first step of a project is to define requirements. They also agree that a design should be done before implementation starts. But is this commonly known and widely observed practice correct? Haven’t we all encountered a design that, well into the project, was found to be a poor fit for the platform? It’s not that the design was bad – it was just inappropriate for the specific technology being used. Can it be there are times when the design first approach makes no sense?

BLASPHEME!!

How dare I suggest there are times when engineers should start implementation before there is a design? Well, actually I’m saying something even worse. I claim there are times when the engineers should simply play with the technology to learn about it and see what it can do – BEFORE they do a design. I’m not saying they should do this at home in their free time. This is corporate work and they should charge the project while they explore the technology with no preconceived design.

BLASPHEME!! – again.

How dare I claim there are times when a technical expert can be behaving in a professional fashion by “playing” with a technology on company time when the schedule clock is ticking? Well, because it’s true. Sometimes, especially with new or unfamiliar technology, the team can produce a design that is completely inappropriate for the mysterious new (to them) technology. Worse, the team may produce a design that is a near miss that “sort of” works. That design must be shoehorned into the platform and beaten into submission with months of tweaking and hard work. If you have not seen this on a project, you are in denial or have not been an engineer long enough. Asking an engineer ignorant of the nuances of a technology to do a design is like asking Picasso to do a gothic painting of the Last Supper. You might get something, but the genius, subject matter, and style are just not in sync. Such a design will likely be ugly and inefficient or worse.

I recently completed an iPhone application called “Treadmill Controller”. I started it in the universally accepted right way. I started with full and complete requirements, a design, and even an implementation on a Windows PC platform. My initial concept was to simply port this implementation to the iPhone. However, the two platforms (PC and iPhone) have very different capabilities and user interface concepts.

· The PC application was intended to generate a “chirp” audio file that could be played back later with Media Player to control the treadmill speed and incline. With the iPhone app, however, it seemed more appropriate to stream the controlling audio “chirps” out the earphone jack.

· The PC has much, much more screen real-estate.

· The PC application was mouse oriented and made extensive use of drop-down menus. This approach just didn’t translate well to the touch-screen iPhone.

In just a couple of days I was able to generate “chirp” audio on the iPhone and stream it out the earphone jack to control a treadmill. However, generating specific audio chirps is pretty much an algorithmic exercise and somewhat independent of whether it is implemented in C, C++, or Objective C. Specifying a workout segment, on the other hand, requires extensive interaction with the iPhone user interface. One must provide its time, speed, and incline.

To build a suitable user interface on the iPhone I had to learn how to create and manipulate a number of user interface elements. To appropriately use this iPhone technology I also had to learn what looked and “felt” right. While there was learning “how to” there was far more learning “how to in situ”.

I invested over a month “playing” with different approaches and implementation concepts to learn what was useable, comfortable, and efficient. In many companies the cost of this investment would have been prohibitive and the first generation product would not have been very good.

There can be many unknowns in the real world of engineering design. Resolving issues and implementing a good product requires teamwork between management and staff and between the various corporate groups. Great products cannot be made from a superficial understanding of a new technology. One must master the technological nuances, speak the proper incantations, and lay the magic sticks in the right orientation. This will only happen when management supports pre-design “playing” to become expert with the new and unknown technology.