Bugs!!

From Three Questions About Each Bug You Find
"..Do you sometimes fix a bug, and then find another bug related to the first or to the way you fixed it? When I fix a bug, I ask myself three questions to make sure I've thought carefully about its significance. You can use these questions to improve productivity and quality every time you think you've found and fixed a bug..."

Figure 1

Figure 1 is "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 introducing the term "debugging a computer program". In 1988, the log, with the moth still taped by the entry, was in the Naval Surface Warfare Center Computer Museum at Dahlgren, Virginia, which erroneously dated it 9 September 1945. The Smithsonian Institute's National Museum of American History and other sources have the correct date of 9 September 1947 (Object ID: 1994.0191.01). The Harvard Mark II computer was not complete until the summer of 1947..." The First "Computer Bug"

A project in C++

My son graduates high school this year. One of the subjects he has opted for is Computer Science. The major focus of this course is to provide an understanding of object oriented programming (OOP) through C++.

As a requirement of this course he needs to submit a project that covers OOP, Data File Handling, and Data Structures. His school mandates that they use Turbo C++ 3.0.

The last few months I have been helping him with his project. Check it out here.

One good outcome is it has whetted my appetite for C++, and I intend to devote a large part of whatever spare time I have to it.

India: my pride, my shame

Today India completes 61 years as a Sovereign, Democratic and Republic state. We have been an independent nation for 64 years.

In this short span of time India has perfected the art of being corrupt. The CWG scam, the 2G scam, the Adarsh scam, $500 billion dollars of the country’s money stashed away in secret accounts abroad, bureaucrats discovered with Rs.300 crore stashed in suitcases at their home - these are the ones that are being talked about now. There are many from the past that we have forgotten. More importantly, we don’t remember anyone of any importance being ever punished.

With such a capacity to indulge in it, it is no surprise that corruption is so pervasive in our society, even soiling venerated institutions like the Armed Forces and the Supreme Court. We don’t need Transparency International’s studies to tell us we are rotten.

As a nation we need stalwarts in public life to look up to. The picture below defines stalwarts. We don’t have people of their vision, stature and influence anymore; however, we are desperate for them, gauging by our admiration for people like Dr. Abdul Kalam and Narayana Murthy. We need more and more people like them; we need their influence over us.


[Photo source: http://en.wikipedia.org/wiki/File:Gandhi_and_Bose.jpg. Don’t know who they are? See here.]

India has many good things going for it. Game-changing activities in the last 6, mostly in the last 3, decades in areas as varied as computerisation of railway reservations, telecom, low cost airlines, software and manufacturing, space research and technology, media, freeing the economy, strengthening the Election Commission, have taken our nation forward. These have been achieved by ordinary citizens doing extraordinary things without funfair, helped by some good thinking by those in government.

We need to do more: in infrastructure, providing quality education, improving agriculture, maintaining the unity without diluting the diversity and, our eternal bug bear, eradicating poverty. And there are many, with insight and zeal, already doing their bit in bringing about these changes. The scale is huge, given India’s diversity, size and population - and this all pervasive corruption makes the work tougher.

To be counted as an advanced nation, a nation truly respected, we must eradicate corruption from our midst.

The privilege and responsibility of software development

From Grady Booch:
".. It is a privilege because -- in spite of some inevitable dark days -- we collectively are given the opportunity to create things that matter: to individuals, to teams, to organizations, to countries, to our civilization. We have the honor of delivering the stuff of pure intellectual effort that can heal, serve, entertain, connect, and liberate, freeing the human spirit to pursue those activities that are purely and uniquely human. At the same time, we have a deep responsibility. Because individuals and organizations depend on the artifacts we create, we have an obligation to deliver systems of quality in a manner that applies scarce human and computing resources intentionally and wisely. This is why we hurt when our projects fail, not only because each failure represents our inability to deliver real value, but also because life is too short to spend precious time on constructing bad software that no one wants, needs, or will ever use. As professionals, we also have a moral responsibility: Do we choose to labor on a system that we know will fail or that may steal from a person their time, their liberty, or their life? These are questions that do not have a technical answer, but rather are ones that must be consciously weighed by our individual belief system as we deploy technology to the world. .." The privilege and responsibility of software development

And from the Software Engineering Code of Ethics and Professional Practice:
".. Computers have a central and growing role in commerce, industry, government, medicine, education, entertainment and society at large. Software engineers are those who contribute by direct participation or by teaching, to the analysis, specification, design, development, certification, maintenance and testing of software systems. Because of their roles in developing software systems, software engineers have significant opportunities to do good or cause harm, to enable others to do good or cause harm, or to influence others to do good or cause harm. To ensure, as much as possible, that their efforts will be used for good, software engineers must commit themselves to making software engineering a beneficial and respected profession. .."

Help...

http://www.saveourtigers.com

Where the mind is without fear ...

"Where the mind is without fear and the head is held high;
Where knowledge is free;
Where the world has not been broken up into fragments by narrow domestic walls;
Where words come out from the depth of truth;
Where tireless striving stretches its arms towards perfection;
Where the clear stream of reason has not lost its way into the dreary desert sand of dead habit;
Where the mind is led forward by thee into ever-widening thought and action…
Into that heaven of freedom, my Father, let my country awake."

- Gurudev Rabindranath Tagore, Noble Laureate, Literature, 1913

Tagore's poem is a prayer of universal appeal. It is also a vision and a mission.

It is a vision, a mission and a prayer not only for my country, but for all mankind, especially in these times of conflict all over the world; replace the 'my country' with 'me' and it is a vision, a mission and a prayer for each one of us.

Design Principles:Don't Repeat Yourself (DRY) - A guide to its implementation

"DRY says that every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation. A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation.

Given all this knowledge, why should you find one way to represent each feature? The obvious answer is, if you have more than one way to express the same thing, at some point the two or three different representations will most likely fall out of step with each other. Even if they don't, you're guaranteeing yourself the headache of maintaining them in parallel whenever a change occurs. And change will occur. DRY is important if you want flexible and maintainable software." From: Orthogonality and the DRY Principle - A Conversation with Andy Hunt and Dave Thomas, Part II (emphasis mine).

How does this apply to code? Read the article here.