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.

Design Principles: Program to interfaces, not implementations - A guide to its implementation

One of the recommended principle of OO design/programming is to ‘program to interfaces, not implementations’.

Consider a password policy defined like this in XML: 

<policy>
 <password>
  <min-length>
   <administrator>18</administrator>
   <end-user>8</end-user>
  </min-length>
  <expires duration="days">
   <administrator>60</administrator>
   <end-user>30</end-user>
  </expires>
 </password>
</policy>

In design, this will look like:

The abstract Policy class exposes 2 abstract methods, which are implemented in its sub-classes. The AdministratorPolicy class implement these methods to return values appropriate to the administrator from the XML file; the EndUserPolicy class implement these methods to return values appropriate to the end user.

And in code we can write:
Policy policy = new AdministratorPolicy();
int pwdMinLength = policy.GetPasswordMinLength();  //returns 18
int pwdExpiresInDays = policy.GetPasswordExpiresInDays();  //returns 60

Or:
Administrator policy = new AdministratorPolicy();
int pwdMinLength = policy.GetPasswordMinLength();  //returns 18
int pwdExpiresInDays = policy.GetPasswordExpiresInDays();  //returns 60

We are programming to an interface when we code Policy policy = new AdministratorPolicy(), because the Policy is an abstract class. We are programming to an implementation when we code Administrator policy = new AdministratorPolicy(), because AdministratorPolicy is an implemented or concrete class.

Notice that no matter how we instantiate it, the policy object is the same, exposing the same methods. This is because the super class and its sub-classes exhibit behavioral equivalence. To implement the design principle ‘program to interfaces, not implementations’ we need to ensure that the super class and its sub-classes are equivalent.

However, this is not always easy because:
1. Behavior in the derived/implemented class may vary.
2. Data in the derived/implemented class may vary.

How do we achieve behavioral equivalence under these circumstances? Read the full article here.

A for Ajax, Part 8: The XMLHttpRequest object (Part 3)

In this post we modify the XHR Library. This is now capabale of:
•  working with GET and POST requests
•  handling JSON formatted text and XML documents returned by the server
•  handling timeouts, and aborting requests

You can read the full article here.

India Leadership Forum 2010

Early in Feb, a colleague and I, sponsored by our company, attended Nasscom’s NILF 2010 at Mumbai. To say the least, it was a wonderful experience. Nasscom has uploaded most of the video recordings of the sessions here. And you can read their blogs, which provide a synopsis of the various sessions, here.

Many industry heavy weights were speakers, but, IMHO, the academicians stole the show at this meet with their very incisive insight into the future. Their presentations were lucid and masterful. I list below some of the sessions I attended. I urge you to go through these presentations.

Building a Learning Organisation by David Garvin, Harvard Business School
synopsis: http://indialeadershipforum.nasscom.in/blog/2010/02/building-a-learning-organisation-workshop-by-prof-garvin/

Expect (and welcome) the unexpected - a new approach to strategy by Lynda Gratton, London Business School
synopsis: http://indialeadershipforum.nasscom.in/blog/2010/02/expect-and-welcome-the-unexpected/
presentation: start with the video labeled Session VI B1 here.

Lynda Gratton also held a work shop titled Get Set Go…Building Organizations With a Vision.

Standing out in the crowd: what’s your differentiator? by Deepak Jain, Kellogg School of Management
synopsis: http://indialeadershipforum.nasscom.in/blog/2010/02/standing-out-in-the-crowd-what%E2%80%99s-your-differentiator/
presentation: start with the video labeled Be a Phoenix 1 here.

Is innovation a priority in challenging times? by MS Krishnan, University of Michigan
presentation: start with the video labeled New Age of Innovation 1 here.

The new rules of marketing and PR by David Meerman Scott, Freshspot LLC
presentation: start with the video labeled New Rules of Maketing and PR 3 here.

Some words that we heard across the sessions - innovation, eco-systems, demographics, culture, value systems, cloud - summed up the focus of this meet.