Sunday, June 19, 2011

Swaha - idam n mama – The meaning I believe

Let’s think about our for father traditions. During rituals known as Shraadh, Hindus worship the ancestors or the Pitr(forefathers / grandparents ) . This is a specific process, reverence is reserved for three or more generations of ancestors – the father, the grandfather and the great grand fathers etc. Generations before this are referred to as “the others”. It is almost as if, after three generations, the family is expected to forget even the name of that ancestor. It is the final letting go.

The notion of swaha (letting go) is central to Indian thought and plays a key role not only in Hinduism but also Buddhism and Jainism. One is constantly asked to move on. That is why, traditionally in India, no tombs were built. The body of the deceased was cremated and the ashes thrown in rivers as one hoped for a quick journey across the river Vaitarni to the land of death followed by a quick rebirth.

Tombs were reserved for those who lived exceptional lives that liberated them from the cycle of rebirths. These tombs were known as “Samadhi” and often contained the relics of holy men, such as the Buddha and various Vedic teachers who had attained liberation or moksha.

The ordinary man was encouraged to move on after death and not cling to memories. Memories were seen as fetters to intellectual and emotional evolution. They conditioned the mind and created impressions that trapped the soul in the cycle of rebirths. For a culture that valued the soul over the flesh, memories were seen as something temporal, something limited to space and time that one had to transcend. This is why history, or at least what is conventionally understood as history, played a very poor role in Hindu thought. More important than kings and events were ideas. And ideas were recurring. Which is why itihasa meant not just history but ‘what was, what is, what will be’ aligning itself to the concept of sanatan, the eternal truth, which forms the core of Indian thought.

What mattered more to Hindus, Buddhists and Jains were eternal principles, not time-bound details. What matters more than the particular is the universal. More important than an Alexander who conquered most of the known world or Ashoka or Aurangazeb who ruled most of the Indian subcontinent, was the mythic idea of the Chakra-varti who ruled the universe, only to realize its futility.

This disdain or indifference for history perhaps stems from faith in rebirth. If this life is but one of infinite lives, then how do events of this life matter. What matters is reflection, introspection of how eternal principles keep manifesting and recurring in each lifetime.

Contrast these with the worldview of the Greeks and the Chinese and the Arabs and the Mongols and the British. Each of them believed in one life. And so this life mattered. The events of this life mattered. And so had to be recorded carefully. History was thus born. And so were tombs. Monuments to the dead had to be raised. In the Mahabharata, there is a derisive reference to ‘worship of a collection of bones’ in the Kali Yuga. Clearly, this celebration of the past was not appreciated in Vedic thought.

Indian disdain for history is most evident when one watches historical films and teleserials. Even a slight deviation in a mythological serial can shut the country down but no one cares when historical characters are subjected to flights of fancy. History plays second fiddle to legend. What matters more is entertainment and romance. Nobody cares what actually happened when Alexander came to India, what matters more is how he reacted to the royal nobility of Porus. Nobody cares what really happened to Prithviraj Chauhan but everyone cares about how he married Sanyogita and killed Muhammad Ghori. It must be remembered that it took a British film maker to make the first Indian film on Gandhi. Later Indians did make films on Babasaheb Ambedkar and Sardar Vallabhai Patel but their poor show at the box office is testimony to the value Indians place on history.

This is why, in India, when one goes to the village, people will know less about people who resided in the village a few generations ago but more about the land’s relationship to Ramayana and Mahabharata. Thus, there are ponds across India where Ram bathed and caves where the Pandavas lived. The same awe is rarely reserved for structures built by parents before great grand parents.

The practice of recording family trees does exist in a few communities, especially in Rajasthan and has been seen as a practice brought down by Huns and Scythians who settled in this region post the Greeks. Another place where family trees are recorded are in pilgrim spots where the local priests known as Pandas claim hereditary rights to serve members of a particular clan, such as kula or gotra. But by far, history is treated with indifference. In fact, had the Greeks and Arabs and Chinese not recorded their interactions with India, much of Indian history would have gone unnoticed.

When one reads sacred literature, one finds long genealogies of kings that trace their origin right up to the gods. There are as many genealogies as there are scriptures and there are widespread variations between them. Scholars have tried hard to put together a history of India based on data found in the Puranas and have failed. The purpose in these lists is not so much as being accurate as it is about connecting the patron of the scripture to one of the two line of kings that ruled India since mythic times, the Surya-vamsis or the sun dynasty or the Chandra-vamsis or the moon dynasty. Even today, most Rajput royal families claim descent from the sun, while many royal families in the East and South claim descent from the moon. The genealogies thus supported the ‘divine right of kings’.

But the British put us on the defensive, forced Indians to construct history. They made Indians feel inferior because they had no sense of history. They went about writing the history of India. And what they wrote, divided Indians forever.

Today, we have a Left-wing view of history that ignores, even mocks the faith of Indians. And then there is the Right-wing view of history that rejects all ideas that came from the British and insists that everything in India is much older than any historian can ever imagine.

With the British came a chronology of India: the Indus Valley civilization followed by a Vedic age followed by Buddhism then the Greeks, then the Huns and Gujjars, then the rise of temples followed by the arrival of Arabs and Mongols and finally the Europeans. In this scheme of things, holy epics like Ramayana and Mahabharata are recorded in the post-Buddhist period, while the more abstract Vedas come from the pre-Buddhist period. In the British view of things, Vedic thought is not indigenous, it came from elsewhere. This becomes a double whammy for the traditional mind. It suggests that the most revered Indian ideas are not only rather recent but worse, foreign!

All these findings upset many Indians as they seemed to be strategically motivated to make Indians feel inferior. So there has been over the past 100 years of retaliation. The baby was thrown out with the bathwater. All datings were rejected. Everything has to be older to be genuinely valued. So everything from Ramayana to Mahabharata to Bhagavad Gita is taken to come down from a time long before Alexander, and long before the Indus valley, and all from the Gangetic plains.

In the din of arguments we will never know the truth. Epigraphic and archeological evidence can never give the full picture whereas faith will always be inflated by imagination. If one follows the ancient Vedic route of not focusing on details of events and seeking the underlying idea, one discovers something very interesting in this debate over Indian history. One discovers that the past is a powerful way to intellectually dominate a people. The British did it by insisting that what Indians believed to be history is actually myth and by myth they meant ‘falsehood’, not ‘subjective truth’. Indians have retaliated by insisting that ‘subjective truth’ is ‘objective truth’. And hence all holy books in India, as far as the devotee is concerned, came together at least 5000 years ago. Today the fight between faith and history has affected school curriculum and court judgments. While many assume this is a fight for truth, it is, in all probability, simply a fight for self-esteem. And this is more than five thousand year old as mentioned in various granths in our culture.

Would love to receive your thoughts on this at Ravindrapande@gmail.com

Sunday, June 12, 2011

iPhone development part 1

Let’s take a detailed took at the landscape for iPhone development, enumerating the different ways to build iPhone Apps and also the tools available to help in the same. iPhone is the biggest thing to happen to the mobile world in real times. The amazing screen and other browsing features has made the Apple iPhone the most popular web browsing mobile device. The same features have also resulted in developers salivating over an opportunity to create iPhone Apps. We first discuss the two fundamental ways to build iPhone Apps and point you to important resources which will help you get started on them as soon as possible.

Basically there can be two different ways that you can write applications for the iPhone:
1. Web Applications (work via browser & networks)
2. Applications (phone based can be network independent for our current understanding)

Web Applications are applications that run of the Safari browser on the iPhone. These applications are typically web applications with their interface and layout customized to suit the browsing communications that have emerged for the iPhone.

I use the word “communication” s specifically to emphasize the fact that web applications need to not only change the layout and appearance to suit the iPhone, but also at the same time rethink usability (not design) to suit the new browsing patterns that have come with the iPhone.

Let’s discuss more on these “Web Applications”

As previously mentioned iPhone Web applications are essentially web applications which run of the Safari browser on the iPhone. The major difference from native web applications is that they cannot access the hardware features like accelerometer, file system etc. They are constrained to run in the sandbox of the browser which is similar to other web applications.

The easiest way to build iPhone web applications is to take your existing web applications and fix the layout so that they match the layout guidelines on the iPhone. The biggest change that this would require is to reduce your real estate to match the size of the iPhone. Also the navigation and usability needs to be changed to better suit the iPhone usability idioms.

The biggest usability change that can be seen in iPhone web applications is the streamlining and extreme focus that it has bought to existing web applications. Instead of the typical web pages which are crammed with content, navigation, lists, advertisements, promotions in every nook and corner, iPhone web applications need to be extremely streamlined and focussed in their approach.

This streamlining and focus is achieved with categorizing every page into only two different kind of layouts. These layouts are firstly a list based layout and secondly an action based layout. What this means that any existing web application need to be broken down into independent screens, each of which need to be either a list based screen or a single action based screen. This is apart from the additional navigation which can be provided in the form of a Next/Previous buttons in the top bar or a tab based navigation.

There are already a lot of tools which help you convert your existing web applications into iPhone applications. Below we mention two of them which probably might be the only thing you need to build iPhone web applications.

Applications are applications that are run on the iPhone itself. These applications are developed largely in Objective-C (a variant of the popular C language) and use the iPhone specific features which are exposed using the Cocoa API on the iPhone.

Obviously, as native applications run directly on the iPhone they have much better access to the iPhone hardware and can use them effectively. And exclusively the iPhone hardware dependant.

Phone applications are applications which run directly on the iPhone hardware. These applications can take advantage of the wide range of hardware innovations that come with the iPhone. These include support for multi-touch, hand gestures, iPhone camera, accelerometer and the built in GPS.

However phone applications are much harder to build as compared the web applications. And if you are not too much into programming the complex syntax of Objective-C will present to you a very steep learning curve. On the plus side, those who have scaled this curve can use their programming chops to cook up some of the most innovative applications that are getting enabled by the iPhone. Add to that the instant recognition and money that a lot of developers have earned by listing on the iPhone App store, and that should be motivation enough for you to start hacking right now.

Native applications unfortunately require you to invest in Apple hardware if you don't already have some. At the minimum you would need a Mac because the iPhone SDK currently only runs on one. Secondly, you would need an actual iPhone. Even though the SDK comes built in with an iPhone simulator this is not enough because a lot of features don't run the same as on an actual iPhone. Case in point is the accelerometer and multi-touch support both of which are not supported on the emulator.

There essentially two big pieces of technology you need to master to build iPhone native applications: Cocoa and Objective-C.

Cocoa is the platform and the API that iPhone exposes for you to access the low level iPhone functionality. Apart from this Cocoa also provides the infrastructure to build simple form based applications for the iPhone. As Apple provides exhaustive documentation on the Cocoa API it is pretty straightforward to get started on.

Objective-C is the variant of the popular C language which is used for the iPhone development. Objective-C is pretty much the same as C/C++ apart from the way it structure functions and message passing. Message Passing, or the way Objective-C structures functions calls are a much more object oriented way of programming, however the syntax takes some time to getting used to. Apart from Cocoa and Objective-C in case your native application is graphics heavy (for example games) it might need to use Open GL to build the graphics part. Open GL is an open source graphics library and is supported on the iPhone.

I believe this is more than required for theory now lets dwell more on how to implement this. So next step we will understand about creating a simple iPhone / iOS application.

Tuesday, April 12, 2011

Estimation Basic Order of magnitude estimate and WBS

This is what most of us face when starting off a new project. New technology, teams unfamiliar with the technology or domain, or unclear requirements ensure that this will probably be the fast & optimal estimate as per time & information availability we can provide.

Break the project down into the different tasks needed. Try to get as many tasks as possible. A useful way to break down tasks is to consider typical software activities such as analysis, design, build, demo, test, fix, document, deploy, and support and see if they are required for each task and whether they need to be broken out into new tasks. We can have a simple standard table to choose from at departmental level. Evaluate each task on two scales: complexity (high, medium, low) and size of work (large, medium, small). A less complex task may still involve a large amount of work; for example, loading a database with information from paper forms may take several weeks. A very complex task may not involve much actual work but can still take a lot of time, as in tuning a database for optimum performance. Complex tasks are usually hard to split between many people/teams while large-size, less complex tasks can usually be split up between many people/teams.

Tasks effectively fall into one of nine combinations of complexity and size. For each combination, define an expected amount of time and resources required. For example, we could say that low complexity and small-size tasks will take one week at most, medium complexity and small-size tasks will take three weeks, and so on. These weighing factors will differ based on the team and project and should be reviewed after the project to help get better values the next time. Add together all these values for each task to get an estimate of time and resources required.

Size

Complexity

Low

Medium

High

Small

1) Tune database

Medium

Large

1) Load data

1) Integrate with security system
2) Create data validation routines

Figure 1. A sample table used for doing an order of magnitude estimate.

Doing rough and fair estimates

These estimates can be done when you have a good idea of the tasks to be done and how to do them.

Those who will do the actual work are the best people to do these estimates. One then can add up all the estimates from different people to get the final estimates. Ensure you collect estimates on the three variables of time, people, and infrastructure/material needs.

Break down tasks to as detailed a level as possible or at least 2 levels. As mentioned previously, it can help to consider typical software activities such as analysis, design, build, demo, test, fix, document, deploy, and support and see if they are required for each task. Break tasks down to a granularity of eighty hours or less.

Conclusion, the preceding techniques can help one achieve better estimates. Review estimated needs versus actual needs after every project. Identify what was correct and what was wrong. This will help you improve the next time. As with many other activities, experience will help you get better!

Now let’s look at the other best practice followed in majority of IT companies, The work breakdown structure (WBS) is an effective tool in managing programs and projects. It assists both developers and contractors in fulfilling management responsibilities. In accordance with good IT organizations management of major system programs and projects, a WBS is mandatory for major system acquisitions and major projects, and will be used for other projects when practical. A WBS is required when performance measurement is applied to a contract. The purpose of WBS is to support the initial project estimation till completion of program and project objectives within budget and schedule constraints. This can be used for various work efforts including research, development, construction, test and evaluation, and operations. The products of these work efforts may be hardware, software, data, or service elements (alone or in combination).

A WBS is developed by first identifying the system or project end item to be structured, and then successively subdividing it into increasingly detailed and manageable subsidiary work products or elements. Most of these elements are the direct result of work (e.g., assemblies, subassemblies, and components), while others are simply the aggregation of selected products into logical sets (e.g., buildings and utilities) for management control purposes. In either case, the subsidiary work product has its own set of goals and objectives which must be met in order for the project objectives to be met. Detailed tasks which must be performed to satisfy the subsidiary work product goals and objectives are then identified and defined for each work product or element on which work will be performed.

Completion of an element is both measurable and verifiable by persons (i.e., quality assurance persons) who are independent of those responsible for the element's completion. Because WBS element/product completion can be verified, a WBS provides a solid basis for technical, schedule and cost plans and status. No other structure (e.g., code of account, functional organization, budget and reporting, cost element) satisfactorily provides an equally solid basis for incremental project performance assessment.

It usually consists of three levels of products/elements with associated work definitions. The three upper levels of are defined below

  • Level 1 is the entire program/project.
  • Level 2 elements are the major product segments or subsections.
  • Level 3 contains definable components, or subsets, of the level 2 elements.
  • Level 3 can be further definable components, or subsets, of the level 3elements.
  • So on & so forth

Now let’s create some rules / regulations for the WBS process implementation in sample IT organization. I have tried to be as generic as possible in this.

  1. The WBS is prepared as early as project definition will permit.
  2. A preliminary WBS is developed in initial phase to define the top levels of a WBS for the entire project (system) life cycle. Normally, this life cycle WBS will be in two parts: one part for the acquisition cycle of the system being acquired (Phases A through D), and one part for the operations and support phase (Phase E).
  3. The WBS is to be compatible with the organization Wide standard Coding Structures defined in quality process as per the need & fitments
  4. A revisit WBS is prepared by compiling the elements of the WBS(s) with the new additions or modifications as per the defined standards.
  5. As design concepts change, the WBS is further refined and changed to reflect new systems and subsystem approaches.
  6. When a project initiated , the WBS becomes formalized as the project outline, and all changes to it should be formally approved by the program managemt office.
  7. The preliminary WBS, written by estimation group / project personnel, is developed through no more than the three highest levels of the proposed contract.
  8. The preliminary WBS is developed from the basic elements of the sales WBS and expanded for use in the request for proposal (RFP), preparation of proposals, and the evaluation and selection process.
  9. Normally, only the top three levels of the WBS will be specified in an RFP. The WBS is considered a preliminary WBS until it is finalized as a result of negotiation and incorporated formally into the contract.
  10. When high risk items are located at low WBS levels, these items can be identified against the higher-level WBS element of which the high risk item is a part. It is not necessary or desirable to extend the WBS below the top three levels in order to identify the high risk item.
  11. The periodic reviews are the basic need in Agile project execution methodology as the agility implies in changing the requirements & so the effort & cost plans in our daily executions.

As we can infer, a work breakdown structure defines all work to be performed for project completion. It is a product-oriented structure, not an organizational structure. To develop and maintain a WBS, you must have a clear understanding of the project's objectives and the end item(s) or end product(s) of the work to be performed. The WBS elements should represent identifiable work products (e.g., hardware, software, data or related service products). Because of its product orientation, a WBS provides the framework to plan, track and assess the project's technical, schedule and cost performance.

A preliminary WBS is established as soon as program management believes the project has reached a stage of definition where it is feasible. It is used to assist in the preparation of the program / project initiation documents and the project plan. As now the preliminary project development process is an iterative process. During its early phases the preliminary WBS may be revised as necessary. Once the project is established in sufficient depth,

procurements may be planned by using selected WBS elements to develop preliminary schedule diagrams. Preliminary WBSs are incorporated into the RFPs, subsequent proposals, and eventually finalized in the executed contract(s) based on negotiations.


Feel free to reach me at ravindrapande@gmail.com to share thoughts & suggestions.