Untitled

Win32 API IsTextUnicode() is not foolproof - a simple demonstration

From the Aftermarket Pipes blog (http://apipes.blogspot.com/2006/06/this-api-can-break.html)

Over at WinCustomize, someone thought they'd found an Easter Egg in the Windows Notepad application. If you:

1. Open Notepad
2. Type the text "this app can break" (without quotes)
3. Save the file
4. Re-open the file in Notepad

Notepad displays seemingly-random Chinese characters, or boxes if your default Notepad font doesn't support those characters.

It's not an Easter egg (even though it seems like a funny one), and as it turns out, Notepad writes the file correctly. It's only when Notepad reads the file back in that it seems to lose its mind.

But we can't even blame Notepad: it's a limitation of Windows itself, specifically the Windows function that Notepad uses to figure out if a text file is Unicode or not.

You see, text files containing Unicode (more correctly, UTF-16-encoded Unicode) are supposed to start with a "Byte-Order Mark" (BOM), which is a two-byte flag that tells a reader how the following UTF-16 data is encoded. Given that these two bytes are exceedingly unlikely to occur at the beginning of an ASCII text file, it's commonly used to tell whether a text file is encoded in UTF-16.

But plenty of applications don't bother writing this marker at the beginning of a UTF-16-encoded file. So what's an app like Notepad to do?

Windows helpfully provides a function called IsTextUnicode()--you pass it some data, and it tells you whether it's UTF-16-encoded or not.

Sorta.

It actually runs a couple of heuristics over the first 256 bytes of the data and provides its best guess. As it turns out, these tests aren't terribly reliable for very short ASCII strings that contain an even number of lower-case letters, like "this app can break", or more appropriately, "this api can break".

The documentation for IsTextUnicode says:

These tests are not foolproof. The statistical tests assume certain amounts of variation between low and high bytes in a string, and some ASCII strings can slip through. For example, if lpBuffer points to the ASCII string 0x41, 0x0A, 0x0D, 0x1D (A ^Z), the string passes the IS_TEXT_UNICODE_STATISTICS test, though failure would be preferable.

Indeed.

As a wise man once said, "In the face of ambiguity, refuse the temptation to guess."

Some Strings for Pasting

Often, I want to enter strings into input fields of particular lengths or contents.

I use handy strings like these to copy to the clipboard and paste into the fields:

10 Characters
1234567890

123456789+

1234567.89

12345.6789

$123456.78

$12,345.67

12,345,678

123,456.78

abcdefghi+

abcdefghiX

ABCDEFGHI+

ABCDEFGHIx

WWWWWWWWWZ

---------+

~!@#$%^&*X

100 Characters
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789+

1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890

123456789+123456789+123456789+123456789+123456789+123456789+123456789+123456789+123456789+123456789+

abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstu+

abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuZ

ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTU+

ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUz

WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWZ

---------------------------------------------------------------------------------------------------+

~!@#$%^&*()_+{}|:"<>?`-=[];',./~!@#$%^&*()_+{}|:"<>?`-=[];',./~!@#$%^&*()_+{}|:"<>?`-=[];',./~!@#$%X

All Alpha Characters

abcdefghijklmnopqrstuvwxyz

ABCDEFGHIJKLMNOPQRSTUVWXYZ

All Special Characters

~!@#$%^&*()_+{}|:"<>?`-=[];',./

Dennis Hopper Pitches a New Movie Concept

An oldie, but goodie!

PITCH MEETING
LOS ANGELES - 9:17 AM

[Dennis Hopper]
Now hear me out guy,
I'm talkin' Oscar here,
classic, classic Cinderella Stuff.

Ok?

A football team...
Somewhere in New England...
Forty-two years, no championship, man.
Bupkus!

New season...
Home opener...
Guess what happens?

SWAM-O! Their franchise quarterback is gone!

So they got a decision to make... huh?

Sure it's too soon...
but they bring in "The Kid"!
And with the thing, and a thing,
and a BOOM!  and a BOOM!
He's got 'em into the playoffs!

Divisional finals...
We got a blizzard! Bah-ha-ha!

The Kid... is driving his boys down the field (phtt)
for a final touchdown (phtt)...
When... (phtt)...
He fumbles!
He fumbles!

(tweet)

Ok. So dig this...

It's not a fumble, alright?
The refs cite some obscure rule,
so it's a fumble...
but it ain't no fumble!

Cut...
To New Orleans.
Why?
Because I love that city like a brother.
Super Bowl!

Tie score...
Timex running dry...

And the Kid, huh...
Marches his boys right into field goal range!

They kick!

...Will it?
...Won't it?

It does!
They win!
They win!
Ah ha ha ha!
They're champions of the freakin' world, man.

And it could really happen.

[Movie Executive]
Next.

[Dennis Hopper]
Ah come on, not the goons, man!
Come on!

I haven't even told you about the sequel!
The sequel, man!

Every year, man!
Every year!

http://www.youtube.com/watch?v=vciGQGTS9WM&search=new%20england%20patriots

Perhaps They Should Have Tested More - Cox Communications

Thursday, June 08, 2006

The Flood of 2006

Massachusetts has had a lot of rain during May and June, 2006, with a lot of property damage.  Some called the end of May, the "Flood of 2006" (http://www.boston.com/news/weather/flood/)

Here are a few pictures my friend Dan Bourret took in Lowell.

Magic 8-Ball Answers

When the answer "42" isn't appropriate, it's time to break out the Magic 8-Ball for answers to foolish questions:

Perhaps They Should Have Tested More - All Binary Searches???

Nearly all binary searches are broken?

Guess I had better add "Search a billion-element-array" to my Test Cases...

(From: http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html)

Extra, Extra - Read All About It: Nearly All Binary Searches and Mergesorts are Broken

6/02/2006 08:34:00 AM

Posted by Joshua Bloch, Software Engineer

I remember vividly Jon Bentley's first Algorithms lecture at CMU, where he asked all of us incoming Ph.D. students to write a binary search, and then dissected one of our implementations in front of the class. Of course it was broken, as were most of our implementations. This made a real impression on me, as did the treatment of this material in his wonderful Programming Pearls (Addison-Wesley, 1986; Second Edition, 2000). The key lesson was to carefully consider the invariants in your programs.

Fast forward to 2006. I was shocked to learn that the binary search program that Bentley proved correct and subsequently tested in Chapter 5 of Programming Pearls contains a bug. Once I tell you what the it is, you will understand why it escaped detection for two decades. Lest you think I'm picking on Bentley, let me tell you how I discovered the bug: The version of binary search that I wrote for the JDK contained the same bug. It was reported to Sun recently when it broke someone's program, after lying in wait for nine years or so.

So what's the bug? Here's a standard binary search, in Java. (It's one that I wrote for the java.util.Arrays):

1:     public static int binarySearch(int[] a, int key) {
2:         int low = 0;
3:         int high = a.length - 1;
4: 
5:         while (low <= high) {
6:             int mid = (low + high) / 2;
7:             int midVal = a[mid];
8:
9:             if (midVal < key)
10:                 low = mid + 1;
11:             else if (midVal > key)
12:                 high = mid - 1;
13:             else
14:                 return mid; // key found
15:         }
16:         return -(low + 1);  // key not found.
17:     }

The bug is in this line:

 6:             int mid =(low + high) / 2;

In Programming Pearls Bentley says that the analogous line "sets m to the average of l and u, truncated down to the nearest integer." On the face of it, this assertion might appear correct, but it fails for large values of the int variables low and high. Specifically, it fails if the sum of low and high is greater than the maximum positive int value (2³¹ - 1). The sum overflows to a negative value, and the value stays negative when divided by two. In C this causes an array index out of bounds with unpredictable results. In Java, it throws ArrayIndexOutOfBoundsException.

This bug can manifest itself for arrays whose length (in elements) is 2³⁰ or greater (roughly a billion elements). This was inconceivable back in the '80s, when Programming Pearls was written, but it is common these days at Google and other places. In Programming Pearls, Bentley says "While the first binary search was published in 1946, the first binary search that works correctly for all values of n did not appear until 1962." The truth is, very few correct versions have ever been published, at least in mainstream programming languages.

So what's the best way to fix the bug? Here's one way:

 6:             int mid = low + ((high - low) / 2);

Probably faster, and arguably as clear is:

 6:             int mid = (low + high) >>> 1;

In C and C++ (where you don't have the >>> operator), you can do this:

 6:             mid = ((unsigned) (low + high)) >> 1;

And now we know the binary search is bug-free, right? Well, we strongly suspect so, but we don't know. It is not sufficient merely to prove a program correct; you have to test it too. Moreover, to be really certain that a program is correct, you have to test it for all possible input values, but this is seldom feasible. With concurrent programs, it's even worse: You have to test for all internal states, which is, for all practical purposes, impossible.

The binary-search bug applies equally to mergesort, and to other divide-and-conquer algorithms. If you have any code that implements one of these algorithms, fix it now before it blows up. The general lesson that I take away from this bug is humility: It is hard to write even the smallest piece of code correctly, and our whole world runs on big, complex pieces of code.

We programmers need all the help we can get, and we should never assume otherwise. Careful design is great. Testing is great. Formal methods are great. Code reviews are great. Static analysis is great. But none of these things alone are sufficient to eliminate bugs: They will always be with us. A bug can exist for half a century despite our best efforts to exterminate it. We must program carefully, defensively, and remain ever vigilant.

Resources

• Programming Pearls - Highly recommended. Get a copy today!
• The Sun bug report describing this bug in the JDK
• A 2003 paper by Salvatore Ruggieri discussing a related problem - The problem is a bit more general but perhaps less interesting: the average of two numbers of arbitrary sign. The paper does not discuss performance, and its solution is not fast enough for use in the inner loop of a mergesort.

A Bug By Any Other Name

So what do we call Software Bugs?

Here are a few terms I've seen or heard:

• Abend
• Anomaly 
• Blemish
• Bug
• Complaint
• Defect
• Deficiency
• Deviation 
• Err 
• Erratum
• Erroneousness
• Error
• Failing
• Failure
• Fault
• Flaw
• Glitch
• Imperfection
• Inaccuracy 
• Inadequacy
• Incident
• Incorrectness
• Irregularity
• Issue
• Lapse
• Miscue
• Misplay
• Misstep
• Mistake
• Mixup 
• Noncompliance 
• Oops
• Problem
• Shortcoming 
• Slip
• Slipup
• Stumble
• Tripup 
• Typo
• Weakness
• Wrongdoing

Can you add to the list?

Perhaps They Should Have Tested More - AOL Mail Outage

AOL Suffers E-Mail Outage

Users trying to send and receive e-mail were prevented from doing so starting around 11 a.m. EDT on Thursday. The service was back up about 4 p.m., a spokesman said.

By Barbara Darrow,  CRN
June 1, 2006
URL: http://www.informationweek.com/story/showArticle.jhtml?articleID=188700949

America Online's e-mail experienced a major glitch Thursday.

Users trying to send and receive e-mail were impacted starting at around 11 a.m. EDT. The service was back up about 4 p.m., a spokesman for the Dulles, Va. based Time Warner subsidiary said Thursday afternoon.

He attributed the problem to a software glitch. Users with aol.com and AIM.com addresses were affected as were netscape.com and compuserve.com users.

America Online says it has some 25 million e-mail users.

CRN learned of the outage from an AOL customer who was informed earlier today by the service provider that it had experienced a "massive internal system failure" and was asked to suspend bulk mailings immediately.

Problems started surfacing yesterday and became a major problem on Thursday, this source said.

"What this means for you is that e-mail delivered into AOL will likely not be received by your subscribers," the source said.

The AOL spokesman contested the use of the term "massive internal system failure" and instead referred to the root cause as a software glitch. "We have recovered. E-mail has stabilized. There is no current impact on users," he said.

Make Vendors Liable for Bugs - Wired News

Not the first time we've heard a similar argument.

I understand the sentiment, but I'm not sure how practical this might be.

(And I'm not sure the headline actually matches the gist of the article)

http://www.wired.com/news/columns/0,71032-0.html?tw=wn_index_16

Make Vendors Liable for Bugs

By Bruce Schneier
02:00 AM Jun, 01, 2006

Security Matters

Have you ever been to a retail store and seen this sign on the register: "Your purchase free if you don't get a receipt"? You almost certainly didn't see it in an expensive or high-end store. You saw it in a convenience store, or a fast-food restaurant. Or maybe a liquor store. That sign is a security device, and a clever one at that. And it illustrates a very important rule about security: It works best when you align interests with capability.

If you're a store owner, one of your security worries is employee theft. Your employees handle cash all day, and dishonest ones will pocket some of it for themselves. The history of the cash register is mostly a history of preventing this kind of theft. Early cash registers were just boxes with a bell attached. The bell rang when an employee opened the box, alerting the store owner -- who was presumably elsewhere in the store -- that an employee was handling money.

The register tape was an important development in security against employee theft. Every transaction is recorded in write-only media, in such a way that it's impossible to insert or delete transactions. It's an audit trail. Using that audit trail, the store owner can count the cash in the drawer, and compare the amount with what the register tape says. Any discrepancies can be docked from the employee's paycheck.

If you're a dishonest employee, you have to keep transactions off the register. If someone hands you money for an item and walks out, you can pocket that money without anyone being the wiser. And, in fact, that's how employees steal cash in retail stores.

What can the store owner do? He can stand there and watch the employee, of course. But that's not very efficient; the whole point of having employees is so that the store owner can do other things. The customer is standing there anyway, but the customer doesn't care one way or another about a receipt.

So here's what the employer does: He hires the customer. By putting up a sign saying "Your purchase free if you don't get a receipt," the employer is getting the customer to guard the employee. The customer makes sure the employee gives him a receipt, and employee theft is reduced accordingly.

There is a general rule in security to align interest with capability. The customer has the capability of watching the employee; the sign gives him the interest.

In Beyond Fear I wrote about ATM fraud; you can see the same mechanism at work:

"When ATM cardholders in the U.S. complained about phantom withdrawals from their accounts, the courts generally held that the banks had to prove fraud. Hence, the banks' agenda was to improve security and keep fraud low, because they paid the costs of any fraud. In the U.K., the reverse was true: The courts generally sided with the banks and assumed that any attempts to repudiate withdrawals were cardholder fraud, and the cardholder had to prove otherwise. This caused the banks to have the opposite agenda; they didn't care about improving security, because they were content to blame the problems on the customers and send them to jail for complaining. The result was that in the U.S., the banks improved ATM security to forestall additional losses -- most of the fraud actually was not the cardholder's fault -- while in the U.K., the banks did nothing."

The banks had the capability to improve security. In the U.S., they also had the interest. But in Britain, only the customer had the interest. It wasn't until the British courts reversed themselves and aligned interest with capability that ATM security improved.

Computer security is no different. For years I have argued in favor of software liabilities. Software vendors are in the best position to improve software security; they have the capability. But, unfortunately, they don't have much interest. Features, schedule and profitability are far more important. Software liabilities will change that. They'll align interest with capability, and they'll improve software security.

One last story... In Italy, tax fraud used to be a national hobby. (It may still be; I don't know.) The government was tired of retail stores not reporting sales and not paying taxes, so a law was passed regulating the customers. Any customer having just purchased an item and stopped within a certain distance of a retail store, has to produce a receipt or face a fine. Just as in the "Your purchase free if you don't get a receipt" story, the law turned the customers into tax inspectors. They demanded receipts from merchants, which in turn forced the merchants to create a paper audit trail for the purchase and pay the required tax.

This was a great idea, but it didn't work very well. Customers, especially tourists, didn't like to be stopped by police. People started demanding that the police prove they just purchased the item. Threatening people with fines if they didn't guard merchants wasn't as effective an enticement as offering people a reward if they didn't get a receipt.

Interest must be aligned with capability, but you need to be careful how you generate interest.

From NASA: 100 Lessons Learned for Project Managers

I stumbled across this list while browsing around.  To me, a lot of these lessons apply well to Software QA.  (And yes, I know there are more than 100 lessons here)

Jerry Madden, Associate Director of the Flight Projects Directorate at NASA's Goddard Space Flight Center, collected these gems of wisdom over a number of years from various unidentified sources. Rod Stewart of Mobile Data Services in Huntsville, Alabama edited and updated them. I found and kept a copy of these during the early nineties. Over time, the NASA link disappeared, so this version of the rules was posted to make sure that it stayed available.

Jerry was apparently well respected at NASA, and his list continued to circulate. One NASA site includes these comments: "Madden retired from NASA in 1995 as Associate Director of Flight Projects at Goddard Space Flight Center. Considered by many of his peers to be one of NASA's premiere project managers, Madden's reputation for frank, on-target observations of project management continues to be celebrated today, as his list of lessons is handed down to a new generation of project managers. Naturally, not all of Madden's wisdom made it into his '100 Lessons Learned for Project Managers.' Marty Davis, who worked under Madden at Goddard, recalls one of the unwritten lessons: 'Show up early for all meetings; they may be serving doughnuts.'"

1. There is no such thing as previously flown hardware, i.e., the people who build the next unit probably never saw the previous unit; there are probably minor changes; the operational environment has probably changed; and the people who check the unit out will in most cases not understand the unit or the test equipment.
2. Most equipment works "as built," i.e., not as the designer planned. This is due to layout of the design, poor understanding on the designer's part, or poor understanding of component specifications.
3. The source of most problems is people but damned if they will admit it. Know the people working on your project, so you know what the real weak spots are.
4. Most managers succeed on the strength and skill of their staff.
5. A manager who is his own systems engineer or financial manager is one who will probably try to do open heart surgery on himself.
6. One must pay attention to workaholics -- if they get going in the wrong direction, they can do a lot of damage in a short time -- it is possible to overload them, causing premature burnout, but hard to determine if the load is too much, since much of it is self-generated. It is important to make sure such people take enough time off and that the workload does not exceed 1-1/4 to 1-1/2 times what is normal.
7. NASA programs compete for budget funds -- they do not compete with each other, i.e., you never attack any other program or NASA work with the idea you should get their funding. Sell what you have on its own merit.
8. Contractors respond well to the customer who pays attention to what they are doing, but not too well to the customer that continually second-guesses their activity. The basic rule is: a customer is always right, but the cost will escalate if a customer always has things done his way, instead of the way the contractor had planned. The ground rule is never change a contractor's plans unless they are flawed or too costly, i.e., the old saying, "better is the enemy of good."
9. Never undercut your staff in public, i.e. don't make decisions on work that you have given them to do in public meetings. Even if you direct a change, never take the responsibility for implementing away from your staff.
10. The project has many resources within itself. There probably are five-to-ten system engineers considering all the contractors and instrument developers. This is a powerful resource that can be used to attack problems.
11. Know who the decision makers on the program are. It may be someone on the outside who has the ear of Congress, or the Administrator, or the Associate Administrator, or one of the scientists -- or someone in the chain of command -- whoever they are, try to get a line of communication to them on a formal or informal basis.
12. You and the program manager should work as a team. The program manager is your advocate at NASA HQ and must be tied in to the decision-making and should aid your efforts to be tied in too.
13. A project manager should visit everyone who is building anything for his project at least once, should know all the managers on his project (both government and contractor), and know the integration team members. People like to know that the project manager is interested in their work, and the best proof is for the manager to visit them and see first hand what they are doing.
14. Never ask management to make a decision that you can make. Assume you have the authority to make decisions unless you know there is a document that states unequivocally that you cannot.
15. Wrong decisions made early can be salvaged, but "right" decisions made late cannot.
16. Never make excuses; instead, present plans of actions to be taken.
17. Never try to get even for some slight by another project. It is not good form -- it puts you on the same level as the other person--and often ends up hindering the project getting done.
18. If you cultivate too much egotism, you may find it difficult to change your position -- especially if your personnel tell you that you are wrong. You should instill an attitude on the project whereby your personnel know they can tell you of wrong decisions.
19. One of the advantages of NASA in the early days was the fact that everyone knew that the facts that we were absolutely sure of could be wrong.
20. Managers who rely on the paperwork to do the reporting of activities are known failures.
21. Not all successful managers are competent and not all failed managers are incompetent. Luck still plays a part in success or failure, but luck favors the competent, hard-working manager.
22. If you have a problem that requires the addition of people to solve, you should approach recruiting people like a cook who has under-salted, i.e., a little at a time.
23. A project manager must know what motivates the project contractors, i.e., their award system, their fiscal system, their policies, and their company culture.
24. Other than original budget information prior to the President's submittal to Congress, there is probably no secret information on the project -- so don't treat anything like it is secret. Everyone does better if they can see the whole picture, so don't hide any of it from anyone.
25. Know the resources of your center and if possible other centers. Other centers, if they have the resources, are normally happy to help. It is always surprising how much good help one can get by just asking.
26. Contractors tend to size up their government counterparts, and staff their part of the project accordingly. If they think yours are clunkers, they will take their poorer people to put on your project.
27. Documentation does not take the place of knowledge. There is a great difference in what is supposed to be, what is thought to have been, and what the reality is. Documents are normally a static picture in time which is outdated rapidly.
28. Remember who the customer is and what his objectives are, i.e., check with him when you go to change anything of significance.
29. In case of a failure:
    • Make a timeline of events and include everything that is known;
    • Put down known facts -- check every theory against them;
    • Don't beat the data until it confesses, i.e., know when to stop trying to force-fit a scenario;
    • Do not arrive at a conclusion too rapidly. Make sure any deviation from the norm is explained--remember the wrong conclusion is prologue to the next failure;
    • Know when to stop.
30. Remember the boss has the right to make decisions, even if you think they are wrong. Tell the boss what you think but, if he still wants it done his way, do your best to make sure the outcome is successful.
31. Redundancy in hardware can be a fiction. We are adept at building things to be identical so that if one fails, the other will also fail. Make sure all hardware is treated in a build as if it were one of a kind and needed for mission success.
32. Don't be afraid to fail or you will not succeed, but always work at your skill to recover. Part of that skill is knowing who can help.
33. Experience may be fine but testing is better. Knowing something will work never takes the place of proving that it will.
34. People have reasons for doing things the way they do them. Most people want to do a good job, and if they don't, the problem is they probably don't know how or exactly what is expected.
35. The boss may not know how to do the work, but he has to know what he wants. The boss had better find out what he expects and wants, if he doesn't know. A blind leader tends to go in circles.
36. A puzzle is hard to discern from just one piece, so don't be surprised if team members deprived of information reach the wrong conclusion.
37. Reviews are for the reviewed and not the reviewer. The review is a failure if the reviewed learn nothing from it.
38. The amount of reviews and reports are proportional to management's understanding, i.e., the less management knows or understands the activities, the more it requires reviews and reports. It is necessary in this type of environment to make sure the data is presented so that the average person, slightly familiar with activities, can understand it. Keeping the data simple and clear never insults anyone's intelligence.
39. In olden times, engineers had hands-on experience, technicians understood how the electronics worked and what it was supposed to do, and layout technicians knew too-but today only the computer knows for sure, and it's not talking.
40. Not using modern techniques like computer systems is a great mistake, but forgetting the computer simulates thinking is still greater.
41. Management principles are still the same. It is just the tools that have changed. You still should find the right people to do the work and get out of the way so they can do it.
42. It is mainly the incompetent that don't like to show off their work.
43. Whoever you deal with, deal fairly. Space is not a big playing field. You may be surprised how often you have to work with the same people. Better they respect you than carry a grudge.
44. Mistakes are all right, but failure is not. Failure is just a mistake you can't recover from; therefore, try to create contingency plans and alternate approaches for the items or plans that have high risk.
45. You cannot be ignorant of the language of the area you manage or with that of areas with which you interface. Education is a must for the modern manager. There are simple courses available to learn computerese, communicationese, and all the rest of the modern ese's of the world. You can't manage if you don't understand what is being said or written.
46. Most international meetings are held in English. This is a foreign language to most participants such as Americans, Germans, Italians, etc. It is important to have adequate discussions so that there are no misinterpretations of what is said.
47. NASA Management Instructions (NMIs) are written by another NASA employee like yourself; therefore, challenge them if they don't make sense. It is possible another NASA employee will rewrite them or waive them for you.
48. A working meeting has about six people attending. Meetings larger than this are for information transfer.
49. Being friendly with a contractor is fine -- being a friend of a contractor is dangerous to your objectivity.
50. The old NASA pushed the limits of technology and science; therefore, it did not worry about "requirements creep" or over-runs. The new NASA has to work as if all are fixed price; therefore, "requirements creep" has become a deadly sin.
51. Many managers, just because they have the scientists under contract on their project, forget that the scientists are their customers and many times have easier access to top management than the managers do.
52. Most scientists are rational unless you endanger their chance to do their experiment. They will work with you if they believe you are telling them the truth. This includes reducing their own plans.
53. Cooperative efforts require good communications and early warning systems. A project manager should try to keep his partners aware of what is going on and should be the one who tells them first of any rumor or actual changes in plan. The partners should be consulted before things are put in final form, even if they only have a small piece of the action. A project manager who blindsides his partners will be treated in kind and will be considered a person of no integrity.
54. All problems are solvable in time, so make sure you have enough schedule contingency -- if you don't, the next project manager that takes your place will.
55. The number of reviews is increasing but the knowledge transfer remains the same; therefore, all your charts and presentation material should be constructed with this fact in mind. This means you should be able to construct a set of slides that only needs to be shuffled from presentation to presentation.
56. Just because you give monthly reports, don't think that you can abbreviate anything in a yearly report. If management understood the monthlies, they wouldn't need a yearly.
57. Abbreviations are getting to be a pain. Each project now has a few thousand. This calls on senior management to know a couple hundred thousand. Use them sparingly in presentations unless your objective is to confuse.
58. Occasionally things go right--the lesson learned here is: Try to duplicate that which works.
59. Running does not take the place of thinking. For yourself, you must take time to smell the roses. For your work, you must take time to understand the consequences of your actions.
60. Sometimes the best thing to do is nothing. It is also occasionally the best help you can give. Just listening is all that is needed on many occasions. You may be the boss but, if you constantly have to solve someone's problems, you are working for him.
61. We have developed a set of people whose self interest is more paramount than the work or at least it appears so to older managers. It appears to the older managers that the newer ones are more interested in form than in substance. The question is are old managers right or just old.
62. One problem new managers face is that everyone wants to solve their problems. Old managers were told by senior management -- "solve your damn problems; that is what we hired you to do."
63. Remember, it is often easier to do foolish paperwork than to fight the need for it. Fight only if it is a global issue which will save much future work.
64. Know your management -- some like a good joke; others only like a joke if they tell it.
65. Integrity means your subordinates trust you.
66. You cannot watch everything. What you can watch is the people. They have to know you will not accept a poor job.
67. Next year is always the year with adequate funding and schedule -- next year arrives on the 50th year of your career.
68. The first sign of trouble comes from the schedule or the cost curve. Engineers are the last to know they are in trouble. Engineers are born optimists.
69. External reviews are scheduled at the worst possible time: therefore, keep an up-to-date set of technical data so that you can rapidly respond. Having to update business data should be cause for dismissal.
70. Hide nothing from the reviewers. Their reputation and yours is on the line. Expose all the warts and pimples. Don't offer excuses -- just state facts.
71. NASA is establishing a set of reviewers and a set of reviews. Once firmly established, the system will fight to stay alive, so make the most of it. Try to find a way for the reviews to work for you.
72. Knowledge is often confounded by test. Computer models have hidden flaws, not the least of which is poor input data.
73. Today one must push the state of the art: be within budget, take risks, not fail, and be on time. Strangely, all these are consistent as long, as the ground rules, such as funding profile and schedule, are established up front and maintained.
74. Most of yesteryear's projects overran because of poor estimates and not because of mistakes. Getting better estimates may not lower cost but will improve NASA's business reputation. Actually, there is a high probability that the cost of getting better estimates will increase cost and assure a higher profit to industry, unless the fee is reduced to reflect lower risk on the part of industry. A better reputation is necessary in the present environment.
75. A scientific proposal takes about 9 months to put together. It takes NASA HQ about 9 months to a year to select the winning proposals. Then, it takes 3 to 4 years to sell the program. This means 5 to 6 years after the initial thoughts, the real work starts. Managers, for some strange reason, do not understand why a scientist wants to build something different than proposed. Managers are strange people.
76. There are rare times when only one man can do the job. These are in technical areas that are more art and skill than normal. Cherish these people and employ their services when necessary as soon as possible. Getting the work done by someone else takes two to three times longer, and the product is normally below standard.
77. Software now has taken on all the parameters of hardware, i.e., requirement creep, high percent-age of flight mission cost, need for quality control, need for validation procedures, etc. It has the added feature that it is hard as hell to determine it is not flawed. Get the basic system working and then add the bells and whistles. Never throw away a version that works even if you have all the confidence in the world the newer version works. It is necessary to have contingency plans for software.
78. History is prologue. There has not been a project yet that has not had a parts problem despite all the qualification and testing done on parts. Time and being prepared to react are the only safeguards.
79. Award fee is a good tool that puts discipline both on the contractor and the government. The score given represents the status of the project as well as the management skills of both parties. The Performance Measurement System (PMS) should be used to verify the scores. Consistent poor scores require senior management intervention to determine the reason. Consistent good scores, which are consistent with PMS, reflect a well-run project, but if these scores are not consistent with the PMS, senior management must take action to find out why.
80. A project manager is not the monitor of the work but is to be the driver. In award fee situations, the government personnel should be making every effort possible to make sure the contractor gets a high score, i.e., be on schedule and produce good work. Contractors don't fail, NASA does, and that is why one must be proactive in support. This is also why a low score damages the government project manager as much as the contractor's manager because it means he is not doing his job.
81. There is no greater motivation than giving a-good person his piece of the puzzle to control but a pat on the back or an award helps.
82. Morale of the contractor's personnel is important to a government manager. Just as you don't want to buy a car built by disgruntled employees, you don't want to buy flight hardware built by them. You should take an active role in motivating all personnel on the project.
83. People who monitor work and don't help get it done, never seem to know exactly what is going on.
84. Never assume someone knows something or has done something unless you have asked them. Even the obvious is overlooked or ignored on occasion -- especially in a high-stress activity.
85. Don't assume you know why senior management has done something. If you feel you need to know, ask. You get some amazing answers that will dumbfound you.
86. If you have someone who doesn't look, ask, and analyze, ask them to transfer.
87. Bastards, gentlemen, and ladies can be project manager. Lost souls, procrastinators, and wishy-washers cannot.
88. A person's time is very important. You must be careful as a manager that you realize the value of other people's time, i.e., work you hand out and meetings should be necessary. You must, where possible, shield your staff from unnecessary work, i.e., some requests should be ignored or a refusal sent to the requester.
89. A good technician, quality inspector, and straw boss are more important in obtaining a good product than all the paper and reviews.
90. The seeds of problems are laid down early. Initial planning is the most vital part of a project. Review of most failed projects or of project problems indicates that the disasters were well planned to happen from the start.
91. A comfortable project manager is one waiting for his next assignment or one on the verge of failure. Security is not normal to project management.
92. Remember, the President, Congress, OMB, NASA HQ, senior center management, and your customers all have jobs to do. All you have to do is keep them all happy.
93. Always try to negotiate your internal support at the lowest level. What you want is the support of the person doing the work, and the closer you can get to him in negotiations the better.
94. Whoever said beggars can't be choosers doesn't understand project management. Many times it is better to trust to luck than to get known poor support.
95. Remember your contractor has a tendency to have a one-to-one interface with your staff; so every member of your staff costs you at least one person (about a 1/4 of million) on the contract per year.
96. There is only one solution to a weak project manager in industry -- get rid of him fast. The main job of a project manager in industry is to keep the customer happy. Make sure the one working with you knows that "on schedule, on cost, and a good product" -- not flattery -- is all that makes you happy.
97. Talk is not cheap. The best way to understand a personnel or technical problem is to talk to the right people. Lack of talk at the right levels is deadly.
98. Projects require teamwork to succeed. Remember most teams have a coach and not a boss, but the coach still has to call some of the plays.
99. In the rush to get things done, it is always important to remember who you work for. Blindsiding the boss will not be to your benefit in the long run. Over-engineering is common. Engineers like puzzles and mazes -- try to make them keep their designs simple.
100. Never make a decision from a cartoon. Look at the actual hardware or what real information is available, such as layouts. Too much time is wasted by people trying to cure a cartoon whose function is to explain the principle.
101. An Agency's age can be estimated by the number of reports and meetings it has. The older it gets, the more the paperwork increases and the less product is delivered per dollar. Many people have suggested that an Agency self-destruct every 25 years and be reborn starting from scratch.
102. False starts are normal in today's environment. More than ever, in this type of environment, one must keep an ear open for the starting gun and be prepared to move out in quick and orderly fashion once it is sounded. In the past, too many false starts have resulted in the project not hearing the real starting gun or jumping off and falling on its face.
103. The pioneering phase of NASA is mostly done, if not actually by fiat. This means the difficult and more important work has started. This work requires more discipline, but there should still be room for innovation.
104. There are still some individuals who think important decisions are made in meetings. This is rarely the case. Normally, the decision-makers meet over lunch or have a brief meeting to decide the issue and than (at a meeting called to discuss the issue) make it appear that the decision is made as a result of this discussion.
105. In political decisions, do not look for logic -- look for politics.
106. Interagency agreements are hard to make even if there is no conflict in the responsibilities and the requirements do satisfy both parties. Conflict in these areas normally leads to failure no matter how hard the people involved try to make an agreement.
107. In dealing with international partners, the usual strategy is to go 1 day early, meet with your counterpart, discuss all issues to be brought up at a meeting, arrive at an agreeable response (or a decision to table the issue for later discussion), and agree not to take any firm positions on any new issues brought up at the meeting. This makes it appear to the rest of the world that you and your counterpart are of one mind and that the work is in good hands. All disputes are held behind closed doors with the minimum number of participants.
108. Gentlemen and ladies can get things done just as well as bastards. What is needed is a strong will and respect -- not "strong arm" tactics. It must be admitted that the latter does work but leaves a residue that has to be cleaned up.
109. Though most of us in our youth have heard the poem that states "for want of a nail the race was lost," few of us realize that most space failures have a similar origin. It is the commonplace items that tend to be overlooked and thus do us in. The tough and difficult tasks are normally done well. The simple and easy tasks seem to be the ones done sloppily.
110. In the "old NASA," a job done within schedule and cost was deemed to be simple. The present NASA wants to push the start of the art, be innovative, and be a risk taker but stay on schedule and cost. One gets the feeling that either the new jobs will be simple or that the reign of saints has finally occurred.
111. Meetings, meetings -- A Projects Manager's staff meeting should last 5 minutes minimum -- 1 hour max -- less than 5 minutes and you probably didn't need the meeting -- longer than 1 hour, it becomes a bull session.
112. Taking too many people to visit a contractor or other government agency puts them in the entertainment business -- not the space hardware or software business.
113. Too many engineers get in the habit of supporting support contractors and of using them as a crutch. In many cases it is getting to the point where one has to wonder who is who.
114. Reviews, meetings, and reality have little in common.
115. You should always check to see how long a change or action takes to get to the implementer -- this time should be measured in hours and not days.
116. Let your staff argue you into doing something even if you intended to do it anyway. It gives them the feeling that they won one! There are a lot of advantages to gamesmanship as long as no one detects the game.
117. Some contractors are good, some are bad, but they seem to change places over time, making the past no guarantee of the future; thus, constant vigilance is a project requirement.
118. It is rare that a contractor or instrumentor does not know your budget and does not intend to get every bit of it from you. This is why you have to constantly pay attention to the manpower they use and to judge their activities in order to assure that they are not overloading the system.
119. People tend to ask for what they think they can get and not what they need. On GRO the specs for photomultiplier tubes were based on the engineering units performance on all parameters. One parameter, though made in the engineering tubes, was difficult to obtain in the flight tubes.
120. It was a meaningless parameter put in only because the engineering tubes met it. Finally, after about 9 months of sweat and tears, this was recognized and deleted so we could get the flight tubes.
121. Today one must get an honest bid -- one which is accurate to 15 percent. On GRO, with TRW the only bidder and with them knowing it, we all got what we believed to be an honest bid that was off by about 18 to 20 percent at the finish. The main area of overrun was the structure. TRW had never built one this large or heavy before. We estimated that the structure would require 600 drawings, multiplied this by 1.25 to get 750 and rounded to 800 to estimate the cost. It took 1,186 drawings. It is normally not the complex systems that get you, so beware when you estimate the cost -- especially if there is no experience base.
122. Too much cost data on a proposal can blind you to the real risks or forgotten items. On a project we thoroughly knew, we spent 6 months of government and contractor time validating the cost, had rooms full of data, and presented our findings to Headquarters. Two weeks later, the contractor found an "Oh I forgot" that costs $30 million. One should look at how past programs spent their money to try to avoid these traps.
123. On GRO we sort of estimated we needed about 20 percent contingency on previously flown subsystems and about 40 percent to 50 percent on new ones. The ratio was about right except the order was reversed.
124. There are some small companies that make the same subsystem correctly every time because the same people do it. There are some large companies that can never make the same unit correctly every time because different people do the work each time. Heritage should be questioned when the people doing the work all have peach fuzz on their faces.
125. Too many project managers think a spoken agreement carries the same weight as one put in writing. It doesn't. People vanish and change positions. Important decisions must be documented.
126. Make sure everyone knows what the requirements are and understands them. Much easier to say than do. On GRO we stated quite clearly that the scientific instruments had to take 18g in a specific axis. Everyone understood the requirement but until the mechanical test on EGRET no one stood up and said it was impossible to meet it. The thermal specification for the momentum wheels required that they run 5 degrees colder than normal limits to make the spacecraft thermal engineers life easier. No one stood up until after 9 months of failure in the test program to say that the grease used changes state if taken that cold, and would not recover when brought back to higher temperature. You have to have the right people look at requirements. A bunch of managers and salesmen nodding agreement to requirements should not make you feel safe.
127. Too many people at Headquarters believe the myth that you can reduce the food to the horse every day till you get a horse that requires no food. They try to do the same with projects, which eventually end up as dead as the horse.
128. The project manager who is the smartest man on his project has done a lousy job of recruitment.

Perhaps They Should Have Tested More - Telus Voice Mail

Telus blames software for message service shutdown 

Last updated May 24 2006 08:32 AM PDT
CBC News

Faulty computer software was responsible for the six-hour loss of message service for about 25 per cent of Telus phone customers in B.C. and Alberta on Tuesday, the company says.

"Two pieces of equipment that need to communicate with each other failed to communicate with each other effectively," Telus spokesman Shawn said, "and our technicians needed to get in there and solve that."

Hall said callers were able to leave messages normally, but mailbox owners ran into delays and busy signals when they tried to retrieve their messages. He said it took 20 technicians to fix the problem.

No messages were actually lost to the technical glitch, the company said, just delayed.

The company said the malfunction started at about 3:30 p.m. The system was restored at about 10 p.m.

Some customers are demanding financial compensation for the problem, Hall said, and those complaints are being dealt with on a case-by-case basis. 

Perhaps They Should Have Tested More - Puyallup, WA Lahar Warning

False alarm: Radio broadcasts mistaken mudflow warning

The Associated Press

TACOMA – An emergency radio station mistakenly warned that a massive, volcanic-caused mudflow was headed from the flanks of Mount Rainier and that listeners in the valley below should rush to higher ground.

The emergency lahar warning was broadcast Wednesday for nearly an hour on the 1580 AM frequency in the suburban Pierce County town of Puyallup. Some listeners said they were horrified.

Authorities had no estimate how many people heard the broadcast on the weak frequency, or how many evacuated. Fewer than a dozen called Pierce County Emergency Management, the city of Orting or the Puyallup Fire Department.

Nancy Eldred heard it while driving in the Puyallup Valley and called her daughter, Renee Hutchinson, in Tacoma shortly after noon.

"I was in tears," Hutchinson told The News Tribune newspaper. "I was shaking."

Her 17-month-old son, Ethan, was in the car with his grandmother.

After Hutchinson warned co-workers, about 30 people started frantically calling loved ones. Some called their children at schools in the Puyallup Valley and told them to leave immediately, said LaNell Hoppe, the office manager.

"It was so scary," Hoppe said.

Tracy Frye, Eldred's daughter, also heard the warning as she surfed channels for traffic information.

"It kept repeating, 'This is not a test,"' she said.

The family went to schools to collect their children.

Someone called Orting City Hall, and officials there contacted federal authorities. They all confirmed that no lahar was coming.

The prerecorded radio message apparently was triggered by an error in software operated by Puyallup.

Emergency officials in communities around Mount Rainier routinely test the system that would, in the event of a real lahar from the volcano, activate 24 sirens around the valley and broadcast a radio alert. But on Wednesday, 1580 AM picked up the test signal as real and said the lahar was coming.

Officials said a software glitch apparently has caused similar false warnings in the past, according to scattered calls they received. Puyallup Fire Chief Merle Frank said the problem should be taken care of in the next few days.

Geologists have warned that a huge mudflow could break loose from Rainier's west flank with little warning and that a wall of mud and debris could swallow everything in its path and bury the Puyallup Valley floor where 60,000 people live.

In 2001, Seattle television stations falsely reported a major lahar based on unconfirmed police scanner chatter about a minor mudflow within Mount Rainier National Park. The region has had a number of lahar sirens mistakenly activated.

Copyright © 2006 The Seattle Times Company

Quality is in the doing

From "Verbing the Noun" - Dave Thomas and Andy Hunt - The Pragmatic Programmers:

Quality is another important word.  We plan it, measure it, hire folks to manage it, and buy big posters about it (“Consolidated Widgets Inc., where Quality is a Word on the Wall”).  But again, you shouldn’t use quality as a noun: you can’t measure, draw, or describe it.  All you can measure are its effects, the things that result from doing things a certain way.  People mistakenly equate (say) bug rates with quality.  But in reality, bug rates simply correlate with the way the software was written.  If we do things a certain way, the bug rates will be lower and we can claim to have higher quality.  Quality is part of the process; it’s in the doing.  Quality isn’t a set of rules or a set of metrics; it’s in the spirit of the smallest of our daily activities.  Again, quality is a verb trapped in a noun’s body.

http://www.pragmaticprogrammer.com/articles/may_03_verbnoun.pdf

It Works on My Machine - An Interesting Bug

An interesting bug today...

I was testing the Admin tool of a product.

For this particular release, when the Administrator logs in to the Admin tool for the first time, he is warned that the database is out of date and will automatically be upgraded.  When he clicks "Yes", the upgrade is supposed to start.

When I tried it, I got the expected warning and clicked "Yes".  But the upgrade didn't happen.  Instead, I got an error message indicating that the database could not be upgraded, and to check that the user had permission to upgrade the database. 

Very odd!

I made sure everything was set up correctly.

I uninstalled, installed the prior version, installed the current version, and tried again.

Still, it didn't work.

After a few more attempts, I collected the error message and log files, and wrote an Issue Report.

The Issue Report came back as "Not Reproducible".

I brought the developer over and showed him the bug.  It was clearly easily reproducible.

I attached a pre-upgrade version of the database I was using to the Issue Report and sent it back to the developer.

Again he tried, and again the upgrade worked fine on his machine.

I tried a few more things on my machine - still it failed each time.

I asked the developer to try a clean install, rather than the debug version he normally used - still it worked each time for him.

The developer and I tried it together on my machine, and we stumbled on the answer.

Normally the User field of the Admin tool login is case-insensitive.

It doesn't matter if I login as "administrator" or "Administrator".

In this case, I could still correctly login either way.

But, if I logged in as "administrator" (which I usually do) - the upgrade failed.

If I logged in as "Administrator" (which the developer usually does) - the upgrade worked.

It turns out that the User field was being validated during login and again just before the upgrade.  For login, the field was validated in a case-insensitive manner.  For upgrade the field was validated in a case-sensitive manner.

While it was a bit frustrating to have to circle around so many times before we determined the cause, I'm very glad that this one didn't get out to the customers!

Quotes on Quality

"Quality means doing it right when no one is looking."

Henry Ford

"It is easier to do a job right than to explain why you didn't."

Martin Van Buren

"One of the rarest things that a man ever does, is to do the best he can."

Josh Billings

"Quality begins on the inside... and then works its way out."

Bob Moawad

"Quality is everyone's responsibility."

W. Edwards Deming

"Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives."

William A. Foster

"The bitterness of poor quality remains long after low pricing is forgotten."

Leon M. Cautillo

"The trouble with the public is that there is too much of it; what we need in public is less quantity and more quality."

Don Marquis

"Quality is a proud and soaring thing."

Jessica Julian

"The best ad is a good product."

Alan H. Meyer

"It is easier to confess a defect than to claim a quality."

Max Beerbohm

"There is hardly anything in the world that some man cannot make a little worse and sell a little cheaper."

John Ruskin

" Almost all quality improvement comes via simplification of design, manufacturing,, layout, processes, and procedures."

Tom Peters

"The bitterness of poor quality lingers long after the sweetness of meeting schedules is forgotten."

Kathleen Byle, Sandia National Laboratories

"When one find's oneself in a hole of one's own making, it is a good time to examine the quality of the workmanship."

John Renmerde

"Quality is not an act. It is a habit."

Aristotle

"Everything can be improved."

C. W. Barron

"Quality in a product or service is not what the supplier puts in. It is what the customer gets out and is willing to pay for."

Peter F. Drucker

"I consider a bad bottle of Heineken to be a personal insult to me."

Freddy Heineken, founder of Dutch beer giant

"It is a funny thing about life: if you refuse to accept anything but the best you very often get it."

W. Somerset Maugham

"Quality is free, but only to those who are willing to pay heavily for it."

Philip Crosby

"The quality of a person's life is in direct proportion to their commitment excellence, regardless of their chosen field of endeavor."

Vince Lombardi

"Good is not good where better is expected."

Thomas Fuller

"We are what we repeatedly do. Excellence, then, is not an act, but a habit."

Aristotle

"People wish to produce quality; they wish to have pride in workmanship."

W. Edwards Deming

"Quality also marks the search for an ideal after necessity has been satisfied and mere usefulness achieved."

William A. Foster

"You can't fake quality any more than you can fake a good meal."

William S Burroughs

"Be a yardstick of quality.  Some people aren't used to an environment where excellence is expected."

Steve Jobs

New England Patriots - 3 Time Super Bowl Champions

3-Time Super Bowl Champions!

Software Manager Basics

I really liked this article by Mark I. Himelstein.  Vitually everything here applies to QA Managers as well.

Read more from Mark in Dr. Dobb's Journal, and in his blog: http://heavenstone.typepad.com/

Most software managers didn't start out as managers, but began their careers as developers.

By Mark I. Himelstein,  Dr. Dobb's Journal
May 16, 2006
URL:http://www.ddj.com/dept/architect/187203587

Mark is a management consultant with 25 years experience in the software industry. You can check out Mark's blog at www.heavenstone.us.

Most software managers began their careers as software developers. They either had some ambition, some skill recognized as good management material, or were in the right place at the right time. No one I know who manages software was trained to be a manager.

Managers serve multiple masters: The customer, the company, their own manager, their employees, and themselves—and each will tell you what they mean by a good manager. You are stuck with balancing those efforts.

For instance, when I was interviewing for the job of running Solaris Engineering at Sun Microsystems, I asked my interviewers what they would consider success. The (somewhat strange) answer I got was that if they were better managed, it would be a success.

So here's what we have so far: You haven't been, and probably won't be, trained for a job that has too many bosses who either don't know what they want or want everything! What do you do? For starters, you go back to basics—execution, communication, and empowerment.

Execution

In the end, you, your team, and your organization will be rewarded if you develop and release software that customers need in a timely fashion. This is what I label as "execution."

Here are 10 questions involving execution that let you grade yourself:

1. Do you have your customer's requirements?
2. Do you have an approved budget?
3. Do you have an approved roadmap?
4. Do you have an approved schedule?
5. Are you delivering the product on time?
6. Do you hire developers in a timely fashion?
7. Is your team capable of dealing with change?
8. Are you capable of keeping your team focused and resisting change?
9. Do your customers encounter a lot of quality issues with released products?
10. Do you and your team measure how well you do your work on a regular basis to find ways to improve?

Someone once asked me what they should do when management wants something that is unreasonable or impossible. My answer had two parts: First you must ensure that management is informed and understands that this is unreasonable or impossible, and second, you must decide if you can disagree and commit. If you can't, then you need to examine your own career options.

While the second and more dramatic answer may have caught your attention, it is the first answer that leads us to the next basic skill—communication.

Communication

As a manager, you must communicate with each master you serve. For each action or event that affects you or your team, you should be thinking about to whom and how you communicate it. It doesn't matter whether the item is positive or negative.

You must also learn to communicate in different ways with different constituents. For example, you might do formal presentations for your boss's boss, but be more casual with your direct reports. Or you might use e-mail for officially documenting agreements between you and your peers, but need face-to-face meetings to explain that agreement with its rationale and implications to your developers.

Here is a second set of 10 questions with which you can grade yourself on communication:

1. Does your team understand your company's strategy?
2. Does your team understand engineering's roadmap?
3. Does your team understand why the roadmap meets the goals of the strategy?
4. Do you have regular communication meetings and e-mail with your team?
5. Are people on your team willing to tell you bad news?
6. Do you hear information about your team from your team before you hear it from others?
7. Do members of your team communicate with each other and the rest of the company in a respectful manner?
8. Do you provide information to your boss before he or she has to ask for it?
9. Do other people in the company know what your team is doing and accomplishing?
10. Do you communicate in a positive fashion?

How you communicate is as important as communicating itself. The attitude of your words, the respect for those with whom you communicate, the body language or inflection of voice, or choice of words all contribute to whether you communicate well. Cynicism, sarcasm, and negativity could remove all of the advantage you might otherwise realize by communication.

Unlike being a developer, a large part of your job is interacting with people. Just as my final words on communication reflect a care you must have in communication, you must also show care in how you treat your team and peers. I searched for the word that represents this skill, and "empowerment" came to mind.

Empowerment

You can't do it all yourself. You must develop an organization that breeds the next managers and leaders, and an organization that can focus, innovate, and succeed.

You should communicate requirements, work with your teams to develop plans, and then let them execute those plans. If you dictate plans or micromanage the execution, your teams will not succeed. They must feel ownership. Only you can make them feel ownership.

With this in mind, here are 10 questions on empowerment:

1. Does your team develop and buy into their schedules?
2. Do you avoid micromanagement?
3. Do you delegate tasks and let your reports proceed without interference?
4. Do you make it clear what your employees are accountable for?
5. Do you provide leadership opportunities for your employees?
6. Does your team have a sense of urgency in addressing issues?
7. Do you set clear roles and responsibilities for your employees?
8. Do all the members in your team know what they need to accomplish each week before they can go home for the weekend?
9. Do your developers understand the difference between accountability and micromanagement?
10. Do your developers consider your organization a positive work environment?

Empowerment also requires accountability. If you delegate without some checks and balances, you and your team may never accomplish your goals. Do not misconstrue accountability with micromanagement. Many developers take any accountability as micromanagement and you must disabuse them of that notion.

Here are some signs you are micromanaging:

• Ignoring previously agreed upon reporting points and asking for status more frequently.
• Getting angry with people for missing deliverables.
• Constantly changing working assignments.
• Dictating implementation instead of requirements.

You have to give people a chance to do their jobs in a positive environment. You need to look at problems as just things to be solved. You need to engender trust so you can get the truth when you ask for status. Empowerment also means letting your employees help develop their own schedules. While you can set a goal for a release, you must rectify any mismatches between the goals for the content of the release, the goals for the timeframe for the release, and the resources at hand.

You always have the same four things you can adjust in making a schedule—resources, features, dates, and quality. If you go back to the same thing each time you are planning a release in order to make your dates, your company can get out of balance. For example:

• If you remove too many features, you won't have a competitive product.
• If you add too many features, you won't make your dates.
• If you scrimp on quality, you'll get a bad reputation.
• If you wait until the product is perfect, you'll miss the market window.
• If you make your engineers work extra hours all the time, they'll burn out.
• If you add too many resources, you can run out of money.
• If you slip the schedule, you make it hard for the sales team to sell and you might miss a market window.

When you define your product or release correctly and develop aggressive but accomplishable schedules, you may find resistance. The industry is so used to unreasonable schedules and unreasonable goals that many people will think your team is not working hard enough because there is no crisis!

Companies and their customers are best served by creating teams and products that can serve them over a long period of time. The sky is always falling somewhere. You should be aggressive and demand the best from your developers, but you should not abuse them as a resource.

Final Words

Obviously, each question posed here may spawn many more questions, and they may also have responses somewhere between yes and no. Take the time to answer them—and manage wisely.

Perhaps They Should Have Tested More - History's Worst Software Bugs

History's Worst Software Bugs
By Simson Garfinkel Simson Garfinkel
02:00 AM Nov, 08, 2005 EST

Last month automaker Toyota announced a recall of 160,000 of its Prius hybrid vehicles following reports of vehicle warning lights illuminating for no reason, and cars' gasoline engines stalling unexpectedly. But unlike the large-scale auto recalls of years past, the root of the Prius issue wasn't a hardware problem -- it was a programming error in the smart car's embedded code. The Prius had a software bug.

With that recall, the Prius joined the ranks of the buggy computer -- a club that began in 1945 when engineers found a moth in Panel F, Relay #70 of the Harvard Mark II system.The computer was running a test of its multiplier and adder when the engineers noticed something was wrong. The moth was trapped, removed and taped into the computer's logbook with the words: "first actual case of a bug being found."

Sixty years later, computer bugs are still with us, and show no sign of going extinct. As the line between software and hardware blurs, coding errors are increasingly playing tricks on our daily lives. Bugs don't just inhabit our operating systems and applications -- today they lurk within our cell phones and our pacemakers, our power plants and medical equipment. And now, in our cars.

But which are the worst?

It's all too easy to come up with a list of bugs that have wreaked havoc. It's harder to rate their severity. Which is worse -- a security vulnerability that's exploited by a computer worm to shut down the internet for a few days or a typo that triggers a day-long crash of the nation's phone system? The answer depends on whether you want to make a phone call or check your e-mail.

Many people believe the worst bugs are those that cause fatalities. To be sure, there haven't been many, but cases like the Therac-25 are widely seen as warnings against the widespread deployment of software in safety critical applications. Experts who study such systems, though, warn that even though the software might kill a few people, focusing on these fatalities risks inhibiting the migration of technology into areas where smarter processing is sorely needed. In the end, they say, the lack of software might kill more people than the inevitable bugs.

What seems certain is that bugs are here to stay. Here, in chronological order, is the Wired News list of the 10 worst software bugs of all time … so far.

July 28, 1962 -- Mariner I space probe.

A bug in the flight software for the Mariner 1 causes the rocket to divert from its intended path on launch. Mission control destroys the rocket over the Atlantic Ocean. The investigation into the accident discovers that a formula written on paper in pencil was improperly transcribed into computer code, causing the computer to miscalculate the rocket's trajectory.

1982 -- Soviet gas pipeline.

Operatives working for the Central Intelligence Agency allegedly plant a bug in a Canadian computer system purchased to control the trans-Siberian gas pipeline. The Soviets had obtained the system as part of a wide-ranging effort to covertly purchase or steal sensitive U.S. technology. The CIA reportedly found out about the program and decided to make it backfire with equipment that would pass Soviet inspection and then fail once in operation. The resulting event is reportedly the largest non-nuclear explosion in the planet's history.

1985-1987 -- Therac-25 medical accelerator.

A radiation therapy device malfunctions and delivers lethal radiation doses at several medical facilities. Based upon a previous design, the Therac-25 was an "improved" therapy system that could deliver two different kinds of radiation: either a low-power electron beam (beta particles) or X-rays. The Therac-25's X-rays were generated by smashing high-power electrons into a metal target positioned between the electron gun and the patient. A second "improvement" was the replacement of the older Therac-20's electromechanical safety interlocks with software control, a decision made because software was perceived to be more reliable.

What engineers didn't know was that both the 20 and the 25 were built upon an operating system that had been kludged together by a programmer with no formal training. Because of a subtle bug called a "race condition," a quick-fingered typist could accidentally configure the Therac-25 so the electron beam would fire in high-power mode but with the metal X-ray target out of position. At least five patients die; others are seriously injured.

1988 -- Buffer overflow in Berkeley Unix finger daemon.

The first internet worm (the so-called Morris Worm) infects between 2,000 and 6,000 computers in less than a day by taking advantage of a buffer overflow. The specific code is a function in the standard input/output library routine called gets() designed to get a line of text over the network. Unfortunately, gets() has no provision to limit its input, and an overly large input allows the worm to take over any machine to which it can connect.

Programmers respond by attempting to stamp out the gets() function in working code, but they refuse to remove it from the C programming language's standard input/output library, where it remains to this day.

1988-1996 -- Kerberos Random Number Generator.

The authors of the Kerberos security system neglect to properly "seed" the program's random number generator with a truly random seed. As a result, for eight years it is possible to trivially break into any computer that relies on Kerberos for authentication. It is unknown if this bug was ever actually exploited.

January 15, 1990 -- AT&T Network Outage.

A bug in a new release of the software that controls AT&T's #4ESS long distance switches causes these mammoth computers to crash when they receive a specific message from one of their neighboring machines -- a message that the neighbors send out when they recover from a crash.

One day a switch in New York crashes and reboots, causing its neighboring switches to crash, then their neighbors' neighbors, and so on. Soon, 114 switches are crashing and rebooting every six seconds, leaving an estimated 60 thousand people without long distance service for nine hours. The fix: engineers load the previous software release.

1993 -- Intel Pentium floating point divide.

A silicon error causes Intel's highly promoted Pentium chip to make mistakes when dividing floating-point numbers that occur within a specific range. For example, dividing 4195835.0/3145727.0 yields 1.33374 instead of 1.33382, an error of 0.006 percent.

Although the bug affects few users, it becomes a public relations nightmare. With an estimated 3 million to 5 million defective chips in circulation, at first Intel only offers to replace Pentium chips for consumers who can prove that they need high accuracy; eventually the company relents and agrees to replace the chips for anyone who complains. The bug ultimately costs Intel $475 million.

1995/1996 -- The Ping of Death.

A lack of sanity checks and error handling in the IP fragmentation reassembly code makes it possible to crash a wide variety of operating systems by sending a malformed "ping" packet from anywhere on the internet. Most obviously affected are computers running Windows, which lock up and display the so-called "blue screen of death" when they receive these packets. But the attack also affects many Macintosh and Unix systems as well.

June 4, 1996 -- Ariane 5 Flight 501.

Working code for the Ariane 4 rocket is reused in the Ariane 5, but the Ariane 5's faster engines trigger a bug in an arithmetic routine inside the rocket's flight computer. The error is in the code that converts a 64-bit floating-point number to a 16-bit signed integer. The faster engines cause the 64-bit numbers to be larger in the Ariane 5 than in the Ariane 4, triggering an overflow condition that results in the flight computer crashing.

First Flight 501's backup computer crashes, followed 0.05 seconds later by a crash of the primary computer. As a result of these crashed computers, the rocket's primary processor overpowers the rocket's engines and causes the rocket to disintegrate 40 seconds after launch.

November 2000 -- National Cancer Institute, Panama City.

In a series of accidents, therapy planning software created by Multidata Systems International, a U.S. firm, miscalculates the proper dosage of radiation for patients undergoing radiation therapy.

Multidata's software allows a radiation therapist to draw on a computer screen the placement of metal shields called "blocks" designed to protect healthy tissue from the radiation. But the software will only allow technicians to use four shielding blocks, and the Panamanian doctors wish to use five.

The doctors discover that they can trick the software by drawing all five blocks as a single large block with a hole in the middle. What the doctors don't realize is that the Multidata software gives different answers in this configuration depending on how the hole is drawn: draw it in one direction and the correct dose is calculated, draw in another direction and the software recommends twice the necessary exposure.

At least eight patients die, while another 20 receive overdoses likely to cause significant health problems. The physicians, who were legally required to double-check the computer's calculations by hand, are indicted for murder.

http://www.wired.com/news/technology/bugs/0,2924,69355,00.html

The First Bug Report - September 9, 1947

While it doesn't depict a software bug, I ran across this photo and article in Wikipedia, and thought it was interesting:

The First "Computer Bug"

Moth found trapped between points at Relay # 70, Panel F, of the Mark II Aiken Relay Calculator while it was being tested at Harvard University, 9 September 1947.

The operators affixed the moth to the computer log, with the entry: "First actual case of bug being found". They put out the word that they had "debugged" the machine, thus popularizing the term "debugging a computer program" (although the term "bug" had been in use for many years previously by engineers to indicate an indefinite problem).

In 1988, the log, with the moth still taped by the entry, was in the Naval Surface Warfare Center Computer Museum at Dahlgren, Virginia. In 1994 the logbook (with moth still attached) was acquired by the Smithsonian Institution, and is in the collection of the National Museum of American History (where more photos can be seen online under "Object ID 1994.0191.01".

(Admiral Grace Hopper received an honorary Doctorate during my college graduation.  She loved to tell this story.)