You also have, deep inside, a "never-say-die attitude".

In 1883, a creative engineer named John Roebling was inspired by an idea to build a spectacular bridge connecting New York with the Long Island. However bridge building experts throughout the world thought that this was an impossible feat and told Roebling to forget the idea. It just could not be done. It was not practical. It had never been done before.

Roebling could not ignore the vision he had in his mind of this bridge. He thought about it all the time and he knew deep in his heart that it could be done. He just had to share the dream with someone else. After much discussion and persuasion he managed to convince his son Washington, an up and coming engineer, that the bridge in fact could be built.

Working together for the first time, the father and son developed concepts of how it could be accomplished and how the obstacles could be overcome. With great excitement and inspiration, and the headiness of a wild challenge before them, they hired their crew and began to build their dream bridge.

The project started well, but when it was only a few months underway a tragic accident on the site took the life of John Roebling. Washington was injured and left with a certain amount of brain damage, which resulted in him not being able to walk or talk or even move.

"We told them so."

"Crazy men and their crazy dreams."

"It`s foolish to chase wild visions."

Everyone had a negative comment to make and felt that the project should be scrapped since the Roeblings were the only ones who knew how the bridge could be built. In spite of his handicap, Washington was never discouraged and still had a burning desire to complete the bridge and his mind was still as sharp as ever.

He tried to inspire and pass on his enthusiasm to some of his friends, but they were too daunted by the task. As he lay on his bed in his hospital room, with the sunlight streaming through the windows, a gentle breeze blew the flimsy white curtains apart and he was able to see the sky and the tops of the trees outside for just a moment.

It seemed that there was a message for him not to give up. Suddenly an idea hit him. All he could do was move one finger and he decided to make the best use of it. By moving this, he slowly developed a code of communication with his wife.

He touched his wife's arm with that finger, indicating to her that he wanted her to call the engineers again. Then he used the same method of tapping her arm to tell the engineers what to do. It seemed foolish but the project was under way again.

For 13 years Washington tapped out his instructions with his finger on his wife's arm, until the bridge was finally completed. Today the spectacular Brooklyn Bridge stands in all its glory as a tribute to the triumph of one man's indomitable spirit and his determination not to be defeated by circumstances. It is also a tribute to the engineers and their team work, and to their faith in a man who was considered mad by half the world. It stands too as a tangible monument to the love and devotion of his wife who for 13 long years patiently decoded the messages of her husband and told the engineers what to do.

Perhaps this is one of the best examples of a never-say-die attitude that overcomes a terrible physical handicap and achieves an impossible goal.

It’s Not About the Bugs

Scene 1
You are picnicking by a river. You notice someone in distress in the water. You jump in and pull the person out. The mayor is nearby and pins a medal on you. You return to your picnic. A few minutes later, you spy a second person in the water. You perform a second rescue and receive a second medal. A few minutes later, a third person, a third rescue, and a third medal. This continues throughout the day.

By sunset, you are weighed down with medals and honors. You are a hero. Of course, somewhere in the back of your mind there is a sneaking suspicion that you should have walked upriver to find out why people were falling in all day. But, then again, that wouldn't have earned you as many awards

Scene 2
You are sitting at your computer. You find a bug. Your manager is nearby and rewards you. A few minutes later you find a second bug. And so on. By the end of the day, you are weighed down with accolades and stock options. If the thought pops up in your mind that maybe you should help prevent those bugs from getting into the system, you squash it—bug prevention doesn't have as much personal payoff as bug hunting.

What You Measure Is What You Get
B.F. Skinner told us fifty years ago that rats and people tend to perform those actions for which they are rewarded. It is still true today. In our world, as soon as testers find out that a metric is being used to evaluate them, they strive mightily to improve their performance relative to that metric—even if the resulting actions don't actually help the project. If your testers find out that you value finding bugs, you will end up with a team of bug-finders. If prevention is not valued, prevention will not be practiced.

For instance, I once knew a team where testers were rewarded solely for the number of bugs they found and not for delivering good products to the customer. As a result, if testers saw a possible ambiguity in the spec, they wouldn't point it out to the development team. They would quietly sit on that information until the code was delivered to test, and then they would pounce on the code and file bugs galore. The testers were rewarded for finding lots of bugs, but the project suffered deeply from all the late churn and bug-fixing.

That example sounds crazy, but it happened because the bug count metric supported it. On the flip side, I know of a similar project where testers worked collaboratively to deliver a high-quality product. They reviewed the spec and pointed out ambiguities, they helped prevent defects by performing code reviews, and they worked closely with development. As a result, very few bugs were found in the code that was officially delivered to test, and high-quality software was delivered to the customer.

Unfortunately, management was fixated on the bug count metrics found in the testing phase. Because the testers found few bugs during the official test phase, management decided that the developers must have done a great job, and they gave the developers a big bonus. The testing team didn't get a bonus. How many of those testers do you think supported prevention on the next project?

It's Not About the Bugs
Software testing is not about finding bugs. It's about delivering great software. No customer ever said with a straight face, "Wow! You found and fixed 65,000 bugs—that must be really great software!" So, why do many currently use bug counts as a measurement tool? The answer is simple: Bugs are just so darn countable that they are practically irresistible.

They can be counted, tracked, and used for forecasting. And it is tempting to do numerical gymnastics with them, such as dividing them by KLOC (thousand lines of code), plotting their rate over time, or predicting their future rates. But all this ignores the complexities that underlie the bug count. Bugs are a useful barometer of your process, but they can't tell the whole story. They merely help you ask useful questions.

So What Should We Measure?
Here are some thoughts:

How many staff hours are devoted to a project? This is a real cost that we care about. How effectively did your whole team (project managers, developers, and testers) go from concept to delivery? Instead of treating these groups as independent teams with clear-cut deliverables to each other, evaluate them as a unit that is moving from concept to code. Encourage the different specialties to work together. Have program management make the spec more crisp. Have development provide testability hooks. Have the test team supply early feedback and testing.

How many bugs did your customer find? What are customers saying about your product? Have you looked through the support calls on your product? What is customer feedback saying to you about your software's behavior in the field?

How many bugs did you prevent? Are you using code analysis tools to clean up code before it ever gets past compilation? Are you tracking the results?

How effectively did your tests cover the requirements and the code? Coverage metrics can be a useful, though not comprehensive, indicator of how your testing is proceeding.

Finally, a squishy but revealing metric: How many of your own people feel confident about the quality of the product? In some aircraft companies, after the engineers sign off on the project, they all get on the plane for a quick test flight. Assuming that none of your fellow engineers have a death wish, that's a metric you have to respect! It not only says that you found lots of bugs along the way, but that you are satisfied with the resulting deliverable.

Recently saw an email signature that sums it up: We are what we measure. It's time we measure what we want to be.

Ref: stickyminds.com

Investigating Memory shortages.

Your system can develop a memory shortage if multiple processes are demanding much more memory than is available or you are running applications that leak memory. Monitor the following counters to track memory shortages and to begin to identify their causes.

· Memory\Available Bytes indicates how much physical memory is remaining after the working sets of running processes and the cache have been served.
· Process (All_processes )\Working Set indicates the number of pages that are currently assigned to processes. When there is ample memory, the working set structures can fill with pages that are not currently needed to do work but that were needed in the past and might be needed in the future. Because there is no memory shortage, the working set structures are not trimmed. As a result the working set approximates pages that have been referenced in a longer period of time. However, when memory is in short supply, the working set might be trimmed. As a result, the working set in that case approximates the number of pages referenced in a much shorter period of time.
·Memory\Pages/sec indicates the number of requested pages that were not immediately available in RAM and had to be read from the disk or had to be written to the disk to make room in RAM for other pages. If your system experiences a high rate of hard page faults, the value for Memory\Pages/sec can be high.

To maintain a minimum number of available bytes for the operating system and processes, the Virtual Memory Manager continually adjusts the space used in physical memory and on disk. In general, if memory is ample, working set sizes can increase as needed. If the memory supply is barely adequate or very close to the amount required, you might see the operating system trim some working-set sizes when another process needs more memory—at startup.

If the value for Memory \ Available Bytes is consistently below the system-defined threshold (<=20% )and the value for Memory \ Pages/sec spikes continuously, it is likely that your memory configuration is insufficient for your needs. To confirm that a high rate of paging is related to low memory.

To identify processes associated with low-memory conditions, examine memory usage by specific processes, and determine whether a process is leaking memory as described in Investigating User-Mode Memory Leaks and Investigating Kernel-Mode Memory Leaks later in this chapter.
If available memory is consistently low (2 MB or less), the computer becomes unresponsive because it is occupied exclusively with disk I/O operations. During paging due to low memory, the processor is idle while waiting for the disk to finish. Therefore, it is important to investigate and correct the cause of a low-memory condition. Notice which processes are running as well as the sizes of their working sets as you monitor memory counters. The processes might need to be updated or replaced if they are contributing to memory shortages and you do not want to acquire additional memory.

Ref: Microsoft Tech Centre

Software Quality and Reliability

The quality and reliability of software is often seen as the weak link in industry's attempts to develop new products and services. The last decade has seen the issue of software quality and reliability addressed through a growing adoption of design methodologies and supporting CASE tools, to the extent that most software designers have had some training and experience in the use of formalised software design methods.

Unfortunately, the same cannot be said of software testing. Many developments applying such design methodologies are still failing to bring the quality and reliability of software under ontrol. It is not unusual for 50% of software maintenance costs to be attributed to fixing bugs left by the initial software development; bugs which should have been eliminated by thorough and effective software testing.