Tuesday Feb 12, 2008

Why do they call it turkey?

Last Thanksgiving I was preparing dinner with my four-year-old daughter looking on. She had that look on her face, the one she gets when she's forming a difficult question. Finally she asked, "Why do they call it turkey?"

"Because it's turkey," I answered, matter-of-factly.

"No," she continued, "I mean, why do they call the food 'turkey' the same as the bird 'turkey'?"

It was then I realized that she had not yet come to the realization that the animals on the farm and the food on our plate where one and the same. So I started to explain. At one point I flipped the turkey onto its legs, had it walk across the counter doing a can-can and flapping its wings. Perhaps not my best moment in parenting, but it got the message across. She nodded her head in patronizing agreement, and wandered away.

I was worried how she would handle dinner with her new-found knowledge. Would she eat the bird? Would she become a devout vegetarian on-the-spot? Would she enter the dining room chanting protest songs and holding a sign that reads, "Let my turkeys go!"?

But things went fine. She had no qualms about eating the turkey on her plate. She finished one slice, and asked for seconds. I was somewhat relieved, until I noticed she hadn't touched her vegetables. "Eat your veggies, too," I reminded her.

She took one legume with her spool and rolled it around on her plate, examining it carefully from every side. Finally she paused and got that inquisitive look on her face. "Daddy," she asked, looking up at me, "why do they call it 'pea'?"

American Community Survey: Avoiding A Scam

Since my January 8th post ranting on the way the US Census Bureau has been handling the (in my opinion, high intrusive) American Community Survey and failing to safeguard me from fraud and identify theft, the Census Bureau has rolled out a new home page with a link called Are You in a Survey?

This new web page gives the following information and advice:

  • The address that the American Community Survey response should be sent to, so you can verify that the data you provide is going directly to the Census Bureau.
  • If you have received a telephone call from someone at the Census Bureau, and you have any questions, you may speak directly via telephone or e-mail with an employee of the National Processing Center (at 1-866-226-2864).
  • If a person claiming to be from the Census Bureau comes to your door, ask to see their identification badge and a copy of the letter that was sent to you from the Census Bureau. And if you have any questions about their authenticity, call the National Processing Center.

All of this is good advice, and helps to ensure that your personal information is only going to authenticated, and authorized, individuals. Interestingly, these are all things I suggested in my recent posts. You think maybe someone at the US Census Bureau read my blog?

Sunday Feb 03, 2008

American Community Survey: The scam that keeps on scamming

On January 8th I wrote American Community Survey: Big Brother or Scam? I eventually decided to fill out and submit the ACS; now I regret it.

Two weeks after mailing in the survey, we started to get phone calls from a mysterious 800 number. No name on the caller id, just a number.

After, literally, hundreds of these unanswered calls, we slipped. I was traveling and my wife answered the call, despite the anonymous caller id, thinking it might be from a hotel or calling card. But it was someone claiming to be from the Census Bureau wanting to "verify" our answers to the American Community Scam. If these calls were really from the Census Bureau, why would the caller id name be blocked? Obviously, this is a follow-on scam.

My wife was polite, but cautious. She confirmed the names of the people living in the house (information you can get from a multitude of sources). But when the caller started asking specific questions about our finances, she wisely stopped. "How do I know you're really from the Census Bureau?" she asked. After she refused to answer any more questions, the caller told her she would need to call another 800 number to verify his authenticity.

Yeah, right.

If I were to setup up a scam, I'd do just this. Specifically, I'd call numbers from the phone book at random and ask, "I'm calling about the American Community Survey you recently submitted." If the resident hadn't received the survey, I'd hang up. But if they had received it and returned it, I'd ask them to "verify" their answers, and proceed to ask their names, social security numbers, and financial information. If they refused to answer and demanded some form of authentication, I'd give them an 800 number they could call. When they did, my partner would answer the phone saying, "US Census Bureau, American Community Survey department. How can I help you." OK, we'd want this to sound like the government, so maybe he wouldn't be so polite. But anyway, he'd "confirm" that the previous caller was indeed from the government, and that they had to answer every question asked.

How many people would fall for a scam like that? I'd bet 90% of the US population, based on the number of people that forward me junk emails about Microsoft paying out $100 each time that email was forwarded.

Ironically, the US Department of Justic, has a web page on Identify Thelft and Fraud. On that page, the DOJ gives some good advice about avoiding identify theft at home, including:

  • Start by adopting a "need to know" approach to your personal data. A person who calls you and says he's from your bank doesn't need to know information if it's already on file with your bank; the only purpose of such a call is to acquire that information for that person's personal benefit.
  • If someone you don't know calls you on the telephone and asks you for personal data -- such as your Social Security number, credit card number or expiration date, or mother's maiden name -- ask them to send you a written application form.
  • If they won't do it, hang up.
  • If they will, review the application carefully when you receive it and make sure it's going to an institution that's well-known and reputable.
Based on the guidance given us by the Department of Justice, it's clear that we should all discard the American Community Survey if we receive it in the mail, and hang up when they call.

Wednesday Jan 09, 2008

COMDEX 1996

A friend of mine makes an annual pilgrimage to CES in Las Vegas each year. The last trade show I went to in Las Vegas was Comdex. OK, it was a while ago, 11+ years I think, but still I went.

Bill Gates was the keynote speaker that year (as usual). He talked about a brave new world where your PC would be your personal slave, and something called Bob(tm) would do your every bidding. The example was something like... you ask Bob to get you tickets to the opera, and while you're off living your life, Bob finds the best priced tickets, in your preferred section of the Opera Hall, and while he's there, he also books dinner reservations at your favorite restaurant in the Theater District. I recall walking out of the auditorium and wondering if I, a Bob myself, had to worry about paying Microsoft royalties whenever I signed my name. Thanks goodness Bob never took off; as it is, I hate that stupid little paperclip person who tells me I'm using Microsoft Word all wrong -- what an annoying little pest he is!

One of the hot technologies that year was the DVD. It promised to provide 2.5 hours of video, in multiple languages, all in the form factor of a CD. Of course, back then, DVD players cost hundreds, if not thousands of dollars. But after watching a demo of a DVD on a big-screen TV, I was sold. I ran right out and got a DVD player within five years, when they cost $200. Last year I bought a DVD player for my mother-in-law for 35 bucks. Of course, now the video technology is Blu-Ray vs HD-DVD, and the future isn't as clear.

Another new technology being promoted that year was digital cameras. Why in the world would anyone want a digital camera, I wondered. They were huge -- bigger than my old Fujica ST605N SLR (which I still have and use), low resolution (2 megapixels was the norm, not enough for a crisp 8x10 color glossy with circles and arrows and a paragraph on the back of each one), and expensive, easily costing over $1000 for most models. I think it was another 6 or 7 years before I went digital myself.

At the time, I went to the show representing PictureTel, a major high-end videoconferencing vendor at the time. We were telling everyone how video would change the world, business travel would be a thing of the past, and life would be better. Life is better, for me at least -- I quit PictureTel before they went bankrupt and their hollow husk was bought by Polycom. Of course, maybe the people at PictureTel were right, video is changing the world. It's just being done using commodity webcams on laptops and PCs. Seeing the future, and capitalizing on your vision are clearly two different things.

Tuesday Jan 08, 2008

American Community Survey: Big Brother or Scam?

A couple of months ago, we received a mailing, purportedly from the US Census Bureau, called "The American Community Survey." It's more than a census; it asks detailed personal and financial questions which, quite frankly, include things I wouldn't tell my own mother, let alone the US Census Bureau.

Besides asking the address, the names of everyone who lives here, and their birthdays (ideal information for identify theft), it asks questions like:

  • Race of each person in the home. (I didn't even think that was legal to ask!).
  • How many bedrooms are in this house. (What, are they planning on moving in?)
  • Does the house have running water? Hot water? A flush toilet? (Obviously they plan on staying for a while!)
  • How many vehicles are kept at the home? (They must be bringing their own car.)
  • Last month, what was the cost of electricity for this home? (I hope they plan on splitting the cost of utilities while they're staying with us.)
  • Is this a house, apartment or mobile home? (Beggars can't be choosers, I say!)
  • Does the monthly rent include meals? (It's a house, not a B&B!)
  • What were your wages, salary, commisions, bonuses or tops from all jobs, interest, dividends and rental income, accurate to the nearest dollar. (Do they promise not to compare with the IRS?)

The instructions state "The law requires that you provide the information asked in this survey to the best of your knowledge." (emphasis not added by me). On the other hand, I got an email recently that required me to provide my name, credit card number and mother's maiden name to some eBay-look-alike web site; I didn't fall for that one either. So I read the survey carefully, then tossed it in the recycling bin.

Then I started to get the phone calls.

Of course, I get phone calls all the time, from people claiming to be with the government, with the UK National Lottery Commission, a Swiss probate lawyer for my late, apparently estranged great uncle Harold Steinman who recently died and named me as his sole heir, and even representatives from God himself (why they need to use a phone, I'll never understand). This is what caller ID is for.

After two more postcards, and another copy of the survey, I started thinking, hey, even if this does look phony and smell of a scam, maybe this really is legit. So I went to the US Census Bureau web site to see if there was anything about an "American Community Survey" for 2007. Nope, nothing. There was a survey in 2006, but no mention of a survey in 2007. No way to confirm that this survey is legit.

I checked the address on the postage-paid envelop:

    DIRECTOR
    U.S. CENSUS BUREAU
    PO BOX 5240
    JEFFERSONVILLE, IN 47199-5240
Clearly, these spoofers don't know that the US Census Bureau is in Washington, DC! Plus the all-caps style is a dead giveaway of spammers. I also checked the Census Bureau web site, and they don't even list an office in Indiana; the midwest regional office is:
    U.S. Census Bureau
    Chicago Regional Office
    1111 W. 22nd Street, Suite 400
    Oak Brook, IL. 60523-1918
Even if the survey is real, maybe some scammer repackaged it with their own self-addressed envelop? Maybe all of the questions are real, but I'm sending the information to some theif in Indiana.

The instructions include an 800 phone number. But I learned long ago that if you call an 800 number, your phone number is transmitted to the callee, even if you have caller id blocking set up. Telemarketers use this to capture your phone number, and map street addresses to phone numbers. (I know; I had a friend, a software engineer, who worked for a company that did just that. Her specific software project was designed to call people at all times of the day, just to find out when you answer your phone. That way, they could sell your phone number and the times you're most likely to answer to other telemarketers. She eventually quit her job out of guilt.) And if I did call the 800 number and the guy on the other end said, "Ah, yeah, sure, this is the government. Please send us all your info stuff.", should I really believe them?

At this point, I'm starting to think that maybe, just maybe, this survey thing is legit, but the goverment is entirely inept and clueless about authentication and identify theft. If they really want me to fill out this survey, or the 2010 census in two years, they really should:

  • Provide a way I can authenticate that the survey came from the US government. Giving me a phone number is useless; anyone can get a phone number these days. Instead, the instructinos should provide something more authentic, like the URL of a web page, based off of census.gov, that confirms the survey is authentic.
  • Provide a way I can ensure that my data is really going to the right authorities, for example, on the web site list the address that should be on the return envelop.
  • Encourage, no mandate that everyone visit the web site, and verify the address on the envelop before they mail their response! Anything less is just encouraging people to believe whatever they get in the mail with an official-looking seal; it's tantamount to abetting identity theft.
  • Allow people to fill out the survey on the web. Personally, I trust ssl encryption far more than I trust my local mail carrier. On the other hand, I don't really trust the government to secure their servers, so maybe that's a bad idea, too.

Finally, I thought to google '"po box 5240" jeffersonville', and got a hit. Looks like this is a real survey from the Census Bureau, albeit conducted in one of the most shady, disreputable, and hard-to-authenticate manners possible.

In an age where identify theft is a serious business, the US Census Bureau should be keenly aware that the information they process is highly confidential, and a ripe area for theives to exploit. Clearly, based on my personal experience, they haven't gotten that message yet.

Wednesday Nov 14, 2007

Panambic

I'm trying to invent a new word: panambic [puh-nam-bik].

Its origin is the phrase "PAy No Attention to the Man BehInd that Curtain", a quote from The Wizard of Oz (1939). When Dorothy and her chums return to see the Wizard, they are faced with the image of a giant head surrounded by flames. But Toto the dog notices a curtain and pulls it open, revealing the man behind the Wizard. "Pay no attention to the man behind that curtain," says the Wizard, trying to draw attention away from his exposed true self. You also may have seen it spelled PNAMBC.

Panambic is such a useful term, and can be applied in many ways to emphasize that the underlying mechanism is irrelevant to the outward behavior; in other words, what matters is what you see, not how it works. I prefer to use it as an adverb, as in, "The underlying mechanism is panambic."

I first heard the term "panambic" back in 1994. I was working for a large videoconferencing company at the time. They made systems the size of large microwave ovens that cost $20K each, but realized that the market was moving toward lower-cost set-top boxes. They knew they could reduce their system to fit in a small form factor, but wanted to start getting a feel for customer interest. So a small team set off to build up a mock-up: It was a standard cart with doors on the bottom and a TV on top. Atop the TV was a small box the size of a VCR with a movable camera on top. One of the developers plugged the cart into an AC outlet and an ISDN jack, and the videoconferencing system came alive. They placed calls and demonstrated the high-quality audio and video. Everyone was amazed. I asked the designer how they built a functioning prototype so quickly, and his answer was simply, "Panambic!" Then he opened the doors of the cart to reveal one of our large videoconferencing systems concealed in the base. The set-top box was nothing more than a hollow plastic mock-up. The camera was real, but the wires all led down the back to the expensive videoconferencing system. Of course, panambicism can back-fire; once executives saw the working mock-up, they expected a real, shipping product in short order!

(Years later I saw a similar situation depicted in a Dilbert comic strip. I wondered if this sort of thing happened often. Or did one of my videoconferencing colleagues contact Scott Adams.)

I once had a field service engineer file a bug (a bug!) that complained that the software accomplished something he thought was impossible and couldn't understand how the software did it correctly. I simply closed the bug with an evaluation saying, "It's panambic." I suspect that poor field service engineer is still wondering what that meant.

Thursday Nov 08, 2007

People are Like Op Amps

A reader of my blog had a question about punishment and reward and how it relates to professionals. The quote he referenced from Sun Tzu's The Art of War was, "Punishment and reward should be handed out without delay." I agree whole heartedly with Sun Tzu, but my response used an op amp analogy...

Op Amps

Electrical Engineers learn early in college about op amps: The output Vout is equal to the difference of the two inputs (V+ and V-) times a gain G (in an ideal op amp, the gain is infinite). The behavior of an op amp is sometimes written in the form of an equation:
Vout = G (V+ - V-)

Almost all practical op amp designs work on a feedback loop. The most basic op amp design simply takes the output Vout and feeds it back to the negative input V-: a unity gain amplifier with negative feedback. If the output of the op amp is higher than V+, the negative feedback means V- will be higher than V+, and the op amp output will be drive to a lower voltage. If the output is too low, the negative feedback will cause the output voltage to increase. Very quickly, the op amp will drive its output so that Vout exactly equals V+, and tracks V+ as it changes over time. A very nice, simple, and stable design.

Without negative feedback, if the op amp output is drifting high, it will continue to drift higher and higher. Eventually, the output will bare no relationship to the output, and will probably saturate at one rail or the other.

Care must be taken to avoid delay in the feedback loop. Take for example the case where the output is high, so the negative feedback drives the output lower, but the negative feedback doesn't arrive until later. When the negative feedback arrives, the world has changed and the output is now too low. The delayed negative feedback will drive it further in the wrong direction. If this continues, the op amp output may oscillate out of control, swinging from one rail to the other. I think 90% of my Introduction to Circuits course centered around designing stable feedback loops.

Another thing I learned about as a young electrical engineer was noise. Noise in the feedback loop can be fatal. I once tried to design an adjustable gain amplifier using a potentiometer mounted on the front panel to set the resistor divider in the feedback loop. The potentiometer itself is very noisy as you turn the dial and the wiper contact skips along the surface of the resistor. And the wires from the circuit board to the panel are like an antenna picking up every AM radio station in the area. This noise in the feedback loop really screws up the circuit because the op amp misinterprets the noisy feedback, and changes its output, amplifying the noise instead of the signal.

People

People are a lot like op amps.

A person who is allowed to work without any negative feedback will probably go off and do whatever they want, without regard to the goals of the organization.

A person who receives delayed negative feedback may end up getting confused. Why are they getting negative feedback now when they've been doing the same thing for the last 12 months? Or the negative feedback may arrive when they're doing the right thing, causing them to oscillate in their behavior.

And noisy feedback is the worse. I've encountered a number of engineering managers who don't know how to give clear, noiseless, feedback. I've seen managers deal with "problem" employees by giving them satisfactory ratings, but then assigning them boring tasks. Or allowing them to finish a task, and then assigning the same task to someone else to re-do. Nothing screws up a person, or an op amp, more than noisy, confusing feedback.

By negative feedback I mean, of course, any constructive feedback on a person's performance. Goodr feedback can come from anyone, in almost any form, as long as it's clear and immediate. As an example, peer code reviews are a great form of negative feedback -- a software developer quickly and clearly gets feedback on the mistakes they have made in their code, hopefully they learn from the mistake and adjust their behavior accordingly.

An Example

The most clear form of negative feedback in my own career happened when I was about two years out of college. I was working for an aerospace company on a proposal for a major customer. My engineering team and I came up with a good proposed design that met all of the customer's requirements, and we prepared a presentation to give to representatives from the rest of the company -- engineers from manufacturing, sales, quality assurance, etc. I got up to present our design to a room filled with engineers twice my age, full of pride and self confidence. After I presented the design, I was peppered with questions from one particular quality assurance engineer: Why did you pick that processor chip? Did you consider using epoxy instead of paint for the chassis finish? What was the cost trade-off using an extrusion versus a machined chassis? Project X used those connectors and had problems; did you investigate the root cause of their problems to ensure it won't be a factor on this project? And on and on he went. The only answers I had were "ers" and "uhs". I was utterly and completely humiliated. I wanted to just crawl in a hole and die.

After that presentation I realized that in the real world, it wasn't good enough to have a solution, you had to be able to show that it was the best solution. You had to show that you gave every possible alternative it's due diligence to ensure that you didn't miss an opportunity. And you didn't just have to be right, you had to prove you were right. I learned more about proposals and presentations in 15 minutes from that annoying reviewer than I had learned in my career to that point (and probably since, too). It was negative feedback that changed by behavior in a very positive way, and for the rest of my life.

A few years later I was working on another proposal, and it just so happened that the same quality assurance engineer was a reviewer. I don't think he even remembered me from the last time, but I certainly remembered him. This time I was prepared, I showed that my team had done a thorough job, and convinced the reviewers that we had come up with the best possible solution. There were few questions (none hard), and after my presentation the quality assurance engineer said in passing, "Good presentation." His simple comment meant more to me than anything.

Summary

People can learn from mistakes, but only if those mistakes are painful; only if there's negative feedback. If there's no pain, the lesson goes unlearned. Consider the dog that pees on the carpet, and as a result gets a treat. They're not going to learn it's a mistake. But the dog that gets swatted on the nose will remember the pain, and avoid making the same mistake.

During war, mistakes mean death. So in order to train recruits to not make mistakes, the military use slightly less-negative feedback by inducing pain -- more push-ups, running longer with rifles over your head, or sitting in the brig. Punishment and reward meant far more to Sun Tzu than to the ordinary engineer. But it's still important.

Of course, with engineers you don't need to induce pain. Peer review, gentle criticism, performance reviews and even public humiliation can be quite effective. And of course the feedback must be immediate, and free of noise.

Monday Nov 05, 2007

Plan Analysis Revisited: The Power of Laziness

On my blog Plan Analysis: Smart Deliverables, someone posted the comment:
    Bob, great article, and I agree with most of it, but I have one comment. It seems to me that working your team to one date while promising externally another date could cause your team to be somewhat lax about the early date since they have some built in slip time. So how do you motivate your team in this sort of situation? In my experience human nature is to procrastinate right up until the drop dead date.
I was going to reply in a comment, but found my reply was big enough for a post.

The author of the comment notes that "human nature is to procrastinate right up until the drop dead date". This underscores a fundamental principle which I believe drives all human (and more specifically, engineering) action: people are lazy. To take it one step further, in another blog I pointed out that every engineer I've ever met falls into one of two categories: smart and lazy, or just plain lazy.

The key to successful leadership is harnessing that laziness, and using it for good. Or at the very least, using it for your own profit. But how?

Well, consider that every day we engineers get up, some of us shower, and we all go off to work. Work seems to be the antithesis of laziness, but it really isn't. We know that if we don't go to work, life would be harder. Harder? What could be harder than sitting in an air-conditioned office, in a comfy swivel chair, surfing the web and drinking Diet Coke all day? Lots of things. If we don't go to work as engineers, we'd have to get a real job, where they make you work and sweat and get callouses. Laziness motivates us to work.

And laziness drivers us to exhert a minimal of effort, which, when you think about it, is good for business. The less effort we spend at each task, the more efficient we are.

Back to the original question... How do you motivate a team to deliver earlier than the absolute latest minute? Appeal to their laziness; show them that if they fail to deliver on time, it will mean more (and harder) work for them in the long run. Let's take an example...

Some years back I was leading a project that included a significant change to a Solaris device driver to support new hardware. The plan was to include the driver rewrite in Solaris 9 since the new hardware would be ready to ship about three months after Solaris 9 is first released. The schedule was tight -- Solaris 9 locks down about three months before it ships, so we had to have the driver done six months before the hardware was product-ready. The responsible engineer was in a panic, and couldn't understand why I wasn't. I explained to him...

If we fail to make the Solaris 9 cutoff, we could include the driver in the first quarterly update of Solaris 9 which will ship at about the same time the hardware is ready. New features are allowed at the early part of an update release, so moving to an update release meant we'd have an extra two to three more months for development and testing. But with that option comes a lot more work: in order to ship in an update release you have to do more testing on your own, fill out more forms, write more reports, do presentations to committees, and request approvals from review boards. Releasing the software in an update release would give him more time, but would take a lot more work.

And if for some reason we couldn't make the quarterly update, we could always release an unbundled patch. But releasing patches outside of the quarterly release process means even more work: more committees and review boards, and you become responsible for doing regression testing on every platform that could possibly be affected by the patch. It's a huge amount of work, but it would buy as an extra month or two.

So, I wasn't worried at all about shipping the software in time to support the hardware; the only question was how much work we'd have to do. The longer we took meant more and more work. The easiest thing to do would be to get the software done early, in time for Solaris 9. The laziest thing to do would be to work fast and hard.

Obviously, every person is motivated slightly differently, and every person responds to pressure differently. One key skill in a project leader is knowing the people, and understanding how they tick. From there you can find the way to motivate them. I think it was Don Rumsfeld who said, "Leadership is by consent, not command," and Eisenhower said, "Leadership is the art of getting someone else to do something you want done because he wants to do it." In the end, you have to find the best way to motivate each person, that is, the best way to appeal to their sense of laziness. Show them that working hard and meeting your early deadlines is the laziest thing they can possibly do.

Wednesday Jul 25, 2007

Where have I been?

It's been about 3 months since I put some serious work into this book. I haven't been slacking; I've actually been spending my free time writing in my other blog, The Secrets of Olympus.

For the last three years, I've worked on the SPARC Enterprise M-class server line, a joint development project between Sun and Fujitsu. It was a lot of work, and a lot of new and interesting challenges. So I wanted to document some of the neat little things that are special about the SPARC Enterprise products.

Now that SPARC Enterprise is shipping and new development is ramping down, I promise to get back to the book. I've already started the last chapter ("Know What's Going On") of the second section ("The Art of Software Project Leadership"). After that, one more section to go!

Wednesday Jul 11, 2007

Tape Sculptures

A friend forwarded me an email with pictures of tape people -- sculptures of people made from ordinary packing tape. Here are a couple of my favorites:

After some googling, I found the web site tapesculpture.org dedicated to tape sculture, with some more interesting photos, and a how-to guide to making your own sculptures.

Wednesday Feb 07, 2007

Evolutionism

I was reading an article in a (several months old) magazine yesterday which compared Evolution to Creationism. After reading the article I went back and re-read it -- no where in the text did it refer to the Theory of Evolution. Creationism was rightly presented as an "ism," that is, as an ideology, but Evolution was presented as a fact.

When we stop treating Evolution as a theory, we stop being scientists.

While we scientists must staunchly defend scientific theory from religious ideology, we also must not err on the other extreme of defending scientific theories ideologically. It is an absolute failure of science when scientists start believing their theories are infallible, that they are fact. But Evolution seems to have achieved that dubious state. It is no longer the Theory of Evolution; it has become Evolutionism, and there are people who will fight against anyone and anything that contradicts Evolution. They are afraid to call Evolution a theory because they fear it will encourage people to try to find data that contradicts it. And after all, one key role of science is gathering observational data to either support or contradict existing theories.

This is, of course, not the first time in history that a scientific theory has evolved into an ideology. In circa 100 AD, Ptolemy came up with a theory that the Earth was the center of the universe: the "Geocentric Model." Initially a theory, it too entered the realm of ideology. The strict adherence to a once-scientific theory turned the Geocentric Model into Geocentricism, and new scientific theories that contradicted Geocentricism were considered heresy. More than fourteen-hundred years later, Copernicus and Galileo faced stern opposition to the Theory of a Heliocentric Solar System. Despite a new theory which better explained the universe, ideologues refused to waiver.

In a more recent example, Newton's theory of gravity grew into Newton's Law of Gravity. While no one denies that they feel the effects of gravity, Einstein's Theory of Relativity contradicted Newton, and was met with staunch opposition. (While Einstein received the Nobel Prize in Physics, it was for his work on photoelectric and not for the Theory of Relativity.). The Theory of Relativity proved that Newton's "Law" was not a law at all; it was simply a theory which could no longer hold up to scientific scrutiny. This did not mean objects suddenly started falling up; it simply meant that Newton's Theory was wrong, incomplete.

In science, there are no laws: there are observational data, and theories. Theories explain what we have observed in the past and predict what we will observe in the future. No theory is infallible. If we treat a theory as an ideology, we close the door on other scientific theories that might better explain the world around us.

Saturday Dec 30, 2006

Blogging: Harder than it looks

When I started blogging, my goal was to create a series of blogs based on my outline of a book, and in the end, have the book. Turns out it's not quite that easy.

In my outline, there are serveral complex topics that I envisioned would take a chapter -- pages and pages -- to explain.

In my blog, I feel that I need to provide a meaningful (and hopefully sometimes entertaining) point in a short article, rarely more than 4 or 5 paragraphs -- a page or so to summarize what others could write tomes about. I've become my own best (and worst) editor. I've drafted blog entries that were more than a dozen paragraphs, and after carefully removing everything that was not essential, boiled it down to what was valueable: a small nugget of insight in a page of text. I understand that in blogging, time is of the essence, and people are not willing to sit by the fire with a good blog entry.

So who would want a book that was so short and to the point? I investigated a few self-publishing houses, and it seems pretty clear that they set the list price for a book based on the number of pages. Clearly there is no incentive to be concise when writing a book; in fact, it's the opposite, to be verbose, if for no other reason than to push up the page count in order to drive up the price, and indirectly, the author's royalty.

Then again, maybe a book that made a point on every page would be valueable, maybe even preferred. I think about all the books I've read, and I rarely take aware more than two or three key points from each one. Perhaps what my book lacks in volume of pages, it will make up in volume of sales.

Wednesday Dec 13, 2006

Who am I

I graduated from Rensselaer Polytechnic Institute with a Bachelors in Computer Systems Engineer. At the time, there was no such thing as software engineering, and computer engineer was just emerging as its own discipline. The Computer Systems Engineering degree was intended as a bridge between Computer Science and Electrical Engineering -- it included programming languages, compiler design, and operating systems, as well as analog and digital circuit design.

Edison Engineering Program

At graduation I took a position in the Edison Engineering Program at GE Aerospace. That was a great experience! It was a three-year program of rotating job assignments and part-time study, culminating in a Masters of Science degree. During the EEP I worked in jobs in Syracuse and Boston, in Radar Systems and Aircraft Electronics, in CAD and Engineering support, simulation and modeling of ICs and boards, hardware test development for operations, hardware design, and software development, giving me broad exposure to various areas within engineering, and allowing me to work with different people with varying leadership styles.

But I think I learned the most about leadership in my first year of the Edison Engineer Program. Each week we would have a presentation by a person highly skilled in a specific technology (from radar design to writing software for attack submarines). Then the EEP class would split up into groups of 4 or 5 to solve a problem. There was no "group leader", but no group functions without a leader, and every week someone emerged as the leader. Interestingly, the leadership role changed from week to week, depending on the problem to be solved, and who had the motivation that week. After spending some 10 to 20 hours (of unpaid time) working in a group, we would agree on a solution and each person would do their own write-up of the solution. The write-ups were typically 20 pages of text, and were maticulously graded on technical accuracy as well as spelling and grammar. As a result, you learned to write a 20 page technical document which was extremely well written, in a very short period of time.

Grading was done by peers from other teams, and everyone know that every nit you could find on someone else's paper pushed their grade down and pushed your rank up, so the grading was fierce. The graders had one week to review the papers, and they were responsible for presenting the results the following week. The presentations had to cover the technical aspect of the solution as well as the statistical analysis of the grades, and the presentations were graded by the other EEP students in the audience. The audience would often pepper the presenter with questions, hoping to make the presenter look bad, to drive down their grade, and drive up their own rank.

With the number of people in the class, you ended up being a grader/presenter once a month, and since your presentations were graded for technical accuracy and quality of presentation, you learned to prepare and execute presentations in a highly professional, technically accurate manner and were prepared for almost any questions that migh arise.

In a few short years, the Edison Engineer Program turned me from a wide-eyed, naive college grad into an experienced engineer with skills in:

  • Working in, and leading, small groups of engineers,
  • Negotiation skills,
  • Technical problem solving,
  • Writing high-quality technical documents, quickly, and
  • Presentation skills.

I am surprised that every company doesn't have a similar training program.

Early Project Leadership Experience

While working in Aerospace, I led a number of hardware development projects, mostly small projects, with two to four designers. I learned about hardware planning, design, construction, design assurance testing, hardware qualification, and the manufacturing and release process, not to mention learning about product costs versus pricing, union relations, and dealing with a supplier chain and lead times.

The last project I led in aerospace was a new microprocessor-based aircraft monitoring system. The project team consisted of four electrical engineers two mechanical engineers, and four software engineers for a two-year development cycle . This was a large project for a small company, and very large for a twenty-five year old. The hardware development went well enough; although, EMI problems caused a redesign late in the development cycle. But the software side of things went miserably. The software development schedule was created by the software manager, and quickly prooved to be inaccurate. In the end, it took eight software engineers and three and a half years to produce a functioning product -- costing more than three times the original software estimates.

How could hardware estimates and plans be wrong by 10%, while software estimates and plans could be off by two or three times?

Hardware vs Software

In the process of leading both hardware and software projects, I realized that hardware was treated as an engineering discipline, with analysis and documented rationale for costs and estimates; software was treated as an art, with maybe a high-level bubble diagram and some hand waving. When it came right down to it, even the software managers coming up with schedules and estimates had no clue what the real costs would be; they typically divided the amount of time before the product shipped into three three phases -- design, code and test -- then sat back and watched what happened. Even after the design phase took twice as long as planned, the software leaders would say, "Don't worry! We spent more time in the design phase coming up with a detailed design so the coding and test phases should be shorter." In fact, if the design phase was twice the original plan, the code and test phases were usually also twice their original plans.

I decided that what software needed was to apply engineering discipline like hardware engineering; but software isn't hardware, and a new set of "equivalent" engineering processes needed to be developed. When I moved into the commercial sector, I moved completely into the software area for the rest of my career.

How I Came To Sun

After aerospace, I worked for PictureTel, leading software projects to enhance videoconferencing products, including new support for T.120, H.221 HSD and other protocols. Then I worked for a short time at Fujitsu Network Communications on the microcode for an ASIC in an ATM switch, plus the high-level software for controlling the ASIC (which is sort of funny since now I'm working on a project with Fujitsu). When it was time to leave Fujitsu, a former co-worker at PicturelTel asked me to interview at her new company, Sun.

I was skeptical about Sun -- a big company with proprietary hardware and a proprietary Unix OS. But after a couple of interviews, and a peak at the products Sun was developing, I was convinced this was the place for me. During the last eight years at Sun I've led a wide range of software projects: IO drivers, Java applications, embedded real-time software, Solaris and Linux, on a wide range of hardware: SPARC, x86, and PPC, off-the-shelf and custom-built hardware. Working for a large company like Sun has allowed me to tackle a range of projects that no small company could ever offer.

Software as an Engineering Discipline

Since making the switch from hardware engineering to software engineer, I've been a champion of appling engineering principles to software estimation, planning, execution and testing. The use of analytical estimation tools (such as CoCoMo), formal processes for plan develpoment and execution, and the use of automated test harness (e.g., TETware) and analytical test devleopment methodologies (such as Equivalence Class Partitioning (ECP) and Boundary Value Analysis (BVA)) in unit testing are all hallmarks of my projects.

Over the last couple of decades, software as an engineering discipline has evolved quite a bit. But there is still a long way to go.

About

Bob Hueston

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today