Tuesday, December 26, 2006

Microsoft Shares Your Pain

1% of bugs caused 50% of all incredible system errors.

Microsoft's error reporting system has reduced about 80% of system –as they say- errors which encouraged them to make a new way of error reporting.

Microsoft has evolved a new way of customer feedback system. The idea is that Microsoft knows how pain customers suffer when a failure happens in any of their systems. So, Microsoft's employees must share pain with customers.

Thus, WSYP project or We Share Your Pain. WSYP was developed by Microsoft team in United Kingdom. This project claims that Microsoft can discover which programmer who wrote the piece of code which is responsible for this failure. Then, cause him a physical pain. This is done by a special Aeron chair. So, instead of seeing a message of Send Error Report Don't Send the user will see a message of Share Pain Don't Share. Then the customer will happily choose one of the 3 options for punishing this programmer. And see a live video of the programmer sharing pain with him.

Option 1: Micro-Stun option

Electric shocks are generated through the chair arm sleeves.

Option 2: Micro-Impact option

The back of the chair releases back and thrusts forward into the person sitting, into the chair.

Option 3: Micro-Jab option

Watch it in the video.

There is also an ejection option to eject the programmers who have commutative serious bugs out of Microsoft.

Share and Don't Share message box.

Live video so that customers see the programmer cause their system to fail being punished with the selected option.

Micro stun in action

Ejection mechanism after serious errors

The video and the presentation can be found at:


A very interesting video

It's interesting to see how Microsoft feels customers' pains.
I have the video it's about 20MB

Microsoft believes that this system will reduce system errors massively.

And I think by know you don't care about being employed at Microsoft.

Friday, December 8, 2006

The first bug

The first bug

Do you what's the first bug or where did the term "Bug" come from?

In 1945 and during the world war II Grace Murray Hopper and a team at the Harvard University were working on Mark II Aiken Relay Calculator.

This primitive computer was facing problems and matters were getting worth till they discovered the problem. It was a moth! A 2-inch moth was trapped at relay #70. The team used ordinary tweezers to remove that moth.

This photo is the log file left by the team.

Last line in this photo: First actual case of bug being found.

They said that they had “debugged” the machine. Thus they used “bug” to describe their problem.

Grace Murray Hopper (1906-1992) was an admiral at the American navy forces. The term “Bug” cannot be related to Grace Hopper because it was used before she used it. She made it popular. So this case didn’t introduce this term. “Bugs” was used during World War II to describe problems in radars. It was also during Thomas Edison's life to mean an industrial defect.

In days of telegraphy tapers need to send dots and dashes of Morse code. And there were the newer, semi-automatic keyers that would send a string of dots automatically. These semi-automatic keyers were called "bugs". These semi-automatic keyers require skilled operators. Or if you are not experienced you would send garbled Morse code.

Bugs and quotes:

  • Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? (Brian Kernighan)

  • When you say: "I wrote a program that crashed Windows", people just stare at you blankly and say: "Hey, I got those with the system -- for free." (Linus Torvalds)

  • Every program starts off with bugs. Many programs end up with bugs as well. There are two corollaries to this: first, you must test all your programs straight away. And second, there's no point in losing your temper every time they don't work.

  • There are no significant bugs in our released software that any significant number of users want fixed. (Bill Gates) have you any comment??

  • The only man who never makes mistakes is the man who never does anything. (Theodore Roosevelt)

  • Of all my programming bugs, 80% are syntax errors. Of the remaining 20%, 80% are trivial logical errors. Of the remaining 4%, 80% are pointer errors. And the remaining 0.8% are hard. (Marc Donner)

  • Sometimes it pays to stay in bed in Monday, rather than spending the rest of the week debugging Monday's code. (Dan Salomon)

So do you know where “Bugs” originated from?
I don’t know.

But it seems that Grace Murray Hopper case is the first actual bug found.

Monday, October 2, 2006

How to hunt an elephant ?

I wasn't planning to make a series of how to do things but it was a nice coincidence to get this interesting article from Byte magazine.

How to place the right person in the right place?

This is done by:

Sending him to Africa hunting for an elephant and observing his behavior.

Computer scientists:

Use the following algorithm:

1. Go to Africa.

2. Start at the Cape of Good Hope.
/* A rocky headland on the Atlantic coast of South Africa */

3. Work northward in an orderly manner, traversing the continent alternately east and west until you get to Cairo,

4. During each traverse pass,

      • Catch each animal seen.

      • Compare each animal caught to a known elephant.

      • Stop when a match is detected.

This algorithm is used to describe a test data that is designed to ensure that an algorithm is working properly.

Now I will leave you with other various jobs.

"Taken from Byte magazine September 1989"

Professional programmers: Know that this algorithm may not terminate so; they place an elephant in Cairo first then apply this algorithm.

MS-DOS support people: will not bother to hunt elephants in the first place, because everyone knows that you can’t fit an elephant into 640K -memory barrier-.

Mainframe operating system designers: will all hunt the same elephant, and all claim credit for the kill on the grounds that each was working on a virtual elephant.

Software salespeople: ship the first thing they catch and write up an invoice for an elephant.

Hardware salespeople: catch rabbits, paint them grey, and sell them as desktop “elephants.”

Engineers: hunt elephants by catching grey animals at random and stopping when any one of them weighs within +/- 15 percent of any previously observed elephant.

Economists: don’t hunt elephants, but they believe that if elephants are paid enough then they will hunt themselves.

Statisticians: hunt the first animal they see N times and call it an elephant.

Politicians: don’t hunt elephants; they will share the elephants that you catch with the people who voted for them.

Database administrators do not need to go out and capture elephants when they can retrieve them simply with an ad hoc query: SELECT * FROM AFRICAN_CRITTERS 2 WHERE CRITTER_TYPE = 'TERRESTRIAL' 3 AND SIZE = 'LARGE' 4 AND COLOR = 'GRAY' 5 AND TRUNK = 'YES' 6 AND ODOR IS NOT NULL;

Systems integration engineers are not so concerned with hunting elephants as with creating a seamless interface between the elephants and their environment.

For other jobs:


Saturday, September 16, 2006

How to ask a question?

How to ask a question?

This article describes briefly the steps you must follow to ask a question to a mail group or forum. If you are sending a mail to our groups then we are simpler than these steps, you are using step #5 in before you send a question. Use these steps when you send a question to TAs and other mail groups or forums.

Before you send a question,

Do the following in the same order:

  1. Search archives and FAQs
  2. Use search engines.
  3. Read a manual or book or help for your tool.
  4. Find answer by try or experiment.
  5. Ask a friend.

Prepare your question:

  1. Show that you have done last steps and you failed, this proves that you are not lazy.
  2. Show your steps in trying to solve the question.
  3. Try to surround the problem, i.e. try to get the problem in the smallest block.
  4. Describe your environment, e.g. operating system, compiler, others.
  5. Identify yourself.
  6. Compilers and other tools are trusted or to some extend so; don’t assume a bug in them.

When you ask:

  1. Choose the most relevant community to ask.
  2. Use a meaningful, exciting subject that attracts people to read. Don’t simply use “I need help”, “I got error” as subject.
  3. Try to be clear, write a question in a careful way, free of spelling and grammatical mistakes.
  4. Give all information and only information needed. Don’t waste time by describing your design which will not affect the problem.
  5. Don’t let people ask you again about details.
  6. Don’t send you guess instead try your guess yourself if it doesn’t work wait for a reply and send then your guess.
  7. Send questions in easily accessible format. Use standard fonts. You know problems of character encoding.

After getting an answer:

  1. Tell the replier if his answer fixed your problem or not.
  2. Send a small delicate thanks reply for the person wasted his time for you.
  3. You may send a report of the problem and steps in solving it.
  4. Prevent others from following the same steps in solving that problem, I mean reduce their efforts.

Finally smart question attract repliers to answer. Also, new idea sounds well. If you got no reply then, don’t panic may be repliers have no answer. And remember Ask the right question to get the right answer.




Thursday, August 17, 2006

Common programmers' personality


A computer programmer may have a character different from a normal person. Oh! I am sorry, he is a normal person but, I mean a person at other work.
Note: This article doesn't reflect my personal opinion but some statistics collected on software programmers especially engineers.

Common programmers’ character:

The following personality is common among programmers:
  1. Can concentrate 12-16 hours at a time.
  2. When interrupted responds violently.
  3. Use only his head and hands.
  4. Less adaptive and have small social activities. Even concerned with computer. e.g.: chat, mail groups, forums, etc.
  5. Quiet serious and shy.
  6. Practical and logical.
  7. Low motivation towards management responsibilities.
  8. Loyalty to the profession rather than the employer.
  9. Optimism regarding time estimates.
This personality traits was applied to programmers despite their particular work(system analysis, design testers ,etc..).

MBTI Results for Software Developers

A common mean of categorizing personality was developed by Katherine Briggs and Isabel Briggs Meyers and is called the Meyers-Briggs.
Table -1- Personality Type of MBTI test

  1. Expressive, Process by talking
  2. Speak before they think
  3. Need contact


  1. Can’t process while anyone is talking
  2. Think before they speak
  3. Need time alone
  1. Observant
  2. Experiment
  3. Attention to detail


  1. Imaginative
  2. Theory
  3. Bored by detail

  1. Practical
  2. Objective
  3. Being right


  1. Personal
  2. Sympathetic
  3. Values and feelings


  1. Scheduling
  2. Love to make plans and stick to them
  3. Hate to change them
  1. Probing
  2. Can’t stand plans
  3. More flexible

Two large studies have found that the most common personality type for software developers is ISTJ (introversion, sensing, thinking, and judging)
  • Introverts are more interested in the inner world of ideas. Not oriented towards people.(54%)
  • The sensing person focuses on known facts, concrete data, and experience. Not concepts and theories.(57%)
  • The thinker makes decisions based on objective analysis and logic and never relies on his emotions.(81%)
  • The judging person prefers order and control, not possibilities and flexibility.(54%)

A try to analyze these results

May be reasons to this character is education. Programmers are highly educated and almost got pressured.

Software programming career

About 60% of software developers have a Bachelor's degree or more.

Programming job is highly rated in terms of salary, working conditions (air conditioned well lighted offices) job security (almost no risk).

A study at IBM found that the average programmer spends only about 30 percent of the time working alone. The rest is spent working with teammates, with customers, and on interactive activities.

Challenging projects extend programmer’s capabilities, test his limits and apply practices. A challenging project may take from 2 weeks to years. Challenging projects generally done lonely.

A programmer can sacrifice his life to programming challenge especially during 20s. This fact bec0mes harder to justify when he marries and gets children move into their 30s, 40s, and 50s.
As he grows older. He relies more on working smart than on working hard. Software developers will become increasingly interested in the practices that allow them to complete their projects as promised and still be home in time for dinner(only dinner). They become interested more in software engineering professionalism.
Table -2- Percent of Software Developers Education in U.S

High school graduate or equivalent or less10
Some college, no degree21
Associate's degree10
Bachelor's degree45
Graduate degree14

Table -3- Worldwide Software developers grow

Table -2- shows education of software developers’ ratios in U.S.
While Table -3- shows population of software developers from 1960 to 2020


Do you think this article applies to you??



A research done by Ian Barnes from The Australian National University on personality type and software development


A comparison between the personalities of software engineers students and engineers in general. Above statistics were done on software engineers not students.

Monday, July 17, 2006

A computer scientist

An English mathematician ,mechanical engineer and computer scientist who designed the first true digital computer. He spent most of his life building his mechanical computer. He built his computer to overcome the problems of high human calculations and slow rate.

How can a mechanical computer be a digital one? You may think that wheels and gears can represent and manage digits.

This machine -Difference engine- has a fantastic architecture that is similar to modern computers. Data and program memories were separated. And operations were instruction based. It had a control unit and can make conditional jumps. It has time signals and separate I/O unit.

He also designed a printer with variable column and row length and programmable output formatting.

After that he designed a more complex machine -Analytical engine- that can be programed by punched cards. This machine was also intended to have several operations such as branching, and looping.

A young lady Ada Lovelance the daughter of the famed British poet Lord Byron was hired to write software for this computer. She was of few people who knew lot about the Analytical engine. Ada is regarded as the world's first programmer. The programming language Ada® in 1979 is named after her.

This scientist is Charles Babbage 1791 - 1871 who a crater on moon -Babbage crater- and Charles Babbage Institute in United State were named after him. The science fiction novel The Difference Engine refers to him. He was elected as the fellow of royal society at 1816.

References and farther reading:


Saturday, June 3, 2006

Making of BMW e46 3 Series

This video is of my favorite car.

It isn't about exciting features of this car nor racing or driving comfort ability.

It's about manufacturing of this car or simply making of BMW.

So, you can take a tour inside BMW factories starting with metal-sheets cutting and shaping till last performance testing.

My notice is how workers are cheerful doing their work. Will we enjoy our work?

Now I will leave you with the video. Hope you enjoy it.

If you have any difficulties in buffering this video just wait for few minutes.

I may send it to you. It’s about 22 minutes. Or you can have instructions on how to download it.

Friday, May 19, 2006

The Third Culture

Science and Art and "The Third Culture"

Computers -since invented- have been an interesting tool for all. We mean now artists and scientists. This gave great opportunity for both to interact with each other. Artists are interested in great technologies and discoveries made by their mates (scientists). While Scientists are inspires by humanities and great meaning given by artists. So we have two cultures Science and Art. This will evolve the third culture.

We now will define the word science as the study of physical and experimental issues. So a scientist is a person who studies or teaches science.

While art is defined as beautiful things or a skill acquired to a person. It may also be the meanings of words, colors, pictures, nature, many things.

So the third culture tries to tie both Art and science.

Science fiction is an example of this third culture. Here the writer or the poet knows much abut science and art. But, he can use some words outside their context such as "black hole". This is never wrong. It never bothers scientists.

If Science and Art share the same problem, the main difference between them will disappear and will be only the style or the way of solving the problem.



Wednesday, May 10, 2006

Hackers' folklore ”Story of Mel”

Hackers' folklore

This piece of folklore ”Story of Mel” was written by Ed Nather in 1980 for his friend Mel Kaye a true programmer credited with doing "the bulk of the programming" for the Royal McBee LGP-30 drum-memory computer in the 1950s.

Real Programmers write in FORTRAN

Maybe they do now,
in this decadent era of
Lite beer, hand calculators, and "user-friendly" software
but back in the Good Old Days,
when the term "software" sounded funny
and Real Computers were made out of drums and vacuum tubes,
Real Programmers wrote in machine code.
Not FORTRAN. Not RATFOR. Not, even, assembly language.
Machine Code.
Raw, unadorned, inscrutable hexadecimal numbers.

Lest a whole new generation of programmers
grow up in ignorance of this glorious past,
I feel duty-bound to describe,
as best I can through the generation gap,
how a Real Programmer wrote code.
I'll call him Mel,
because that was his name.

As you see the author was fascinated by the old beautiful difficult days of programming where no compilers even assemblers. All programmers had to write their programs in machine language doing computations manually.

Then he starts to introduce his friend Mel a real programmer who he met in Royal McBee Computer Corp. Well the author Ed Nather was hired to write a FORTRAN compiler and Mel didn’t approve this as he said: "If a program can't rewrite its own code", he asked, "what good is it?"

This story is now regarded as one of the most famous pieces of hacker folklore.

Read the complete story:


Monday, May 1, 2006

Find out the Blind Spot

Find out the Blind Spot

Each of your eyes receives a different picture from the other. And the brain collects each of the pictures received by the 2 eyes and merges them into single 3 dimension picture which you see.

What happens if you receive only one picture?

Try this: I think you are in front of the computer about 50 cm. Close your right eye and concentrate on the cross mark in the picture below you see it and the black ball.
Now move slowly towards the screen and observe.

You will notice that at about 30 cm the black ball disappears.

Now what happens?

Each eye has a blind spot in the retina (The retina is a thin layer of cells at the back of the eyeball). This blind spot contains no photoreceptors (cells which receive the light).Thus, preventing the complete picture from getting to the brain.

So, Why is the Blind spot ?

This design allows a good blood supply close to the retina to both nourish the photoreceptors and help metabolize debris that accumulates there.

The other eye fill this black spot in most cases and even if the other eye doesn’t provide useful information the brain has mechanisms to fill in the hole. This filling in is why you see the white background.

Thanks god for great creation.

Read more:





Monday, April 24, 2006

Errors & Bugs

Errors & Bugs

Absolutely all of us face errors in writing programs (Compilation and runtime and others). Some give up some make massive changes while others try to follow errors and never change code or idea.really I don't know what is the best choice but I think it depends on the project itself and on the programmer.

Well I will tell you about some errors I faced.

First error: When I compiled a project (signal flow graph) a nice error appeared.The error was multiple declaration for class List see earlier declaration actually they were more than one error. I compiled the program more than once but the same error List was a template class so I thought that was because of template errors or due to multiple inclusions from several files. All didn’t work. Finally I decided to trace the earlier declarations. I found that the earlier declaration was in other project (Sorting techniques) although the project file was not included. WOW! Yet I was very pleased that I closed the computer. Never work in 2 projects in the same time simply, delete one of them to be far from errors.
No comment.

Other error was in sorting techniques project the project compiled normally with 0 errors and some warnings but when I removed the checkbox of Build with runtime packages the following error appeared fatal linker error cannot find the file “perfgrap.obj”!! What is that file and who included it I don’t know? When I removed the checkbook the project compiled normally I made a new project added all files to that and compiled it with the same error so, what to do now?? I had a small idea I brought any object file from any project and copied it to the project directory then renamed it to “perfgrap.obj” then compiled the project. It compiled successfully and ran normally!
Past errors were all compilation errors what about run time errors?
One of the strangest errors I saw was privileged instruction error! I think it was the responsibility of the compiler to fix that error. other was Paging file error when I see this types of errors I do nothing more than compiling the project more than once.

What’s an error?

(Compilation) Not following the language rules.
(Runtime) The condition of preventing the program from continuing running normally.

What’s a bug?
A bug is a mistake or failure that prevents it from working normally or produces incorrect or false result.
Linus Travold "Given enough eyeballs, all bugs are shallow".
Advices for programmers:

1-Write smart compressed small code : e.g. to copy a string: while (*s++ = *t++) ;
2-Go back and enhance your old code.
3-Learn from your IDE.( Language features IDE features help…)
4-Development on a fast-super computer.
5-Write lots of comments.
6-Use accessors or properties rather than public data.
7-Be aware with input and organized with output.
8-All special cases must be handled immediately; you'll never go back and fix them.
9-Design first (on paper in mind) then code.

Monday, April 17, 2006

China president at Gates house, not White House

China president at Gates house, not White House


Where do you think the first dinner of the historic visit of China’s president Hu Jintao to United States?

The White House? No.

It won't be in Washington D.C., but Seattle,The capital of Microsoft, and the Tuesday dinner will be held at the $100 million lakeside mansion of Microsoft founder and the world's richest man, Bill Gates.

The approximately 100-person guest list is a who's who of the U.S. Pacific Northwest power elite, including Starbucks Chairman Howard Schultz and Washington State Gov. Christine Gregoire.

Gates and Gregoire are expected to introduce and welcome Hu, who will then offer a toast in front of the gathering.

Like any good dinner guest, President Hu will not come empty handed. The Chinese government issued a decree two weeks ago that all PCs will need to have licensed operating system software installed before leaving the factory gates in an effort to crack down on piracy.
As a result, three Chinese PC manufacturers announced plans to buy a total of over $400 million worth of Microsoft Windows operating system software over the next three years and Lenovo Group, China's largest PC maker, is expected to announce a similar deal on Monday, organizers said.

This event is not so good for Linux lovers as it closes the door for Linux poularity in China(one of the greatest hosts for Linux).

Gates' lodge-style, 66,000-square-foot home overlooking Lake Washington with a reported seven bedrooms, six kitchens, 24 bathrooms, a domed library, a reception hall and an artificial estuary stocked with salmon and trout.

Gates lodge

The dining room overlooks the river!


Friday, April 7, 2006

Why People Don’t Work Like Elevators?

Why People Don’t Work Like Elevators?

Your reaction to intensive signals is faster than less intensive ones.

Do you know why?
Do you understand?

Consider the following 2 examples:

You are in a hurry and waiting for the elevator what will you do?
You will push the elevator button strongly and repeatedly, but do you think that this will bring the elevator faster? In other words do you think that the elevator will respond to you faster in that way?
You may imagine that but absolutely that is never true.

Now if you shout at your friend then (s)he will respond to you faster than simply calling him so, why people don't work like elevators?

People respond to brighter light, louder sound faster than other this known as Pieron’s Law

Reaction Time is the time between the action and your response.

I is the physical intensity of the signal.
R0 is the minimum time for any response
K and b are constants that vary depending on the exact setup and the particular person involved.

A graphical representation showing last relation can be shown:

In fact, Pieron’s Law holds for the brightness of light, the loudness of sound, and even the strength of taste.

To see why, think of it like this: Pieron’s Law is a way of saying that the response time increases but at a decreasing rate, as the intensity.

Tom Stafford &
Matt Webb