Jag Venugopal's Blog

May 26, 2009

India’s aspirations to greatness, and Sikh-on-Sikh violence in Punjab

Filed under: India — Jag @ 2:24 pm
Tags: ,

Over the weekend, a group of Sikhs attacked another group of Sikhs in a gurudwara in Vienna. From what I could discern from newspaper accounts, a group of upper-caste Sikhs assaulted a group of lower-caste Sikhs (from a sect called the Dera Sachkand Ballan), resulting in one fatality and another person suffering injuries.

  The reverberations of this Sikh-on-Sikh violence were felt in Punjab, where followers of the Dera vented their rage on public property, including buses and trains. Curfew was imposed, the army called out, and an appeal for calm ensued from the Prime Minister.

The Times of India duly reported all the news, but added its own twist, headlining that the “Vienna clash may put caste in global spotlight”. Now it appears that in a meeting of NGOs in South Africa in 2001, caste-based discrimination was treated on par with race-based discrimination. The Times reported that “India fought back a determined and coordinated bid by NGOs to recognise casteism as racism”, and stated that there could be “renewed international pressure for recognition of caste-based discrimination as a global concern”.

I take issue with the action, counter-action and reporting.

My concerns are first with the Sikh-on-Sikh violence due to caste. Religions such as Sikhism were founded on the basis of repudiation of the caste system. The ten gurus of the faith must be turning in their graves to see their followers perpetrate fratricide on the very basis they sought to eliminate! And by no means is this restricted to the Sikh faith alone. A Catholic friend of mine once remarked on the seating arrangements in his church in Mangalore (south India). It seems that the converts to Christianity from the upper castes got to sit in the chairs to celebrate mass, while converts from lower castes (even if they were Christians for many generations) were made to sit on the floor. Like a blogger on the the Times of India noted: “you can take people out of the caste system, but you can’t take the caste system out of people”. Apparently, we Indians haven’t yet gotten to an egalitarian society that our founding fathers dreamed of, and the gurus of our various religions (Sikhism, Buddhism, etc) envisioned when the broke away from mainstream Hinduism.

My second concern is with how the followers of the Dera sect took umbrage at the injustice that was perpetuated on them. They turned around, and in a display of violent catharsis, inflicted damage on public property in Punjab. Now, their use of violence to settle scores put them in the same league as the agressors. What is stupefying though is why they chose to burn trains and buses. By ruining public property, in effect, they are hurting themselves! The Government of India was not the wrong-doer. Heck, they couldn’t have done much to prevent something that happened in far-away Austria. It is incomprehsible, therefore that they had to damage public property. Additionally, it is reported that a Hyundai showroom was completely burned by the protestors. What sin the South Koreans had committed to deserve this, I do not know. Again it will be the state-owned insurance companies (or in other words, the people) that will have to make good on the losses.

Yet a third level of concern manifests itself in the opinions of the Times of India. To any neutral observer it is patently obvious that the violence was caused by discrimination of one group by another based on accident of birth, or lineage. If this is not racism, then what is? Yet the Times is concerned that this would equate casteism to racism. My response to that is — it’s about time. Caste-based discrimination is the first cousin of race-based discrimination, and ought to be condemned as such in a civilized society. The attendees at the NGO meeting in 2001 that opposed equating the two forms of discrimination were flat out wrong — instead they should have vehemently argued the opposite point — that the two forms of discrimination are identical.

How does this all tie into the Superpower-status aspirations of sections of Indian intelligensia? Very simple — I think that a society where people are discriminated against on the basis of caste (racism by another name), where people decide to address their frustrations and disagreements through violence (and that too, perpetrated on unrelated third parties), and where apologists for casteism try to sweep the problems under the rug instead of forthrightly acknowledging and condemning it, has a long way to go before it can be a superpower. Mere possession of a few nuclear bombs and space vehicles does not make a country a Superpower (whatever the word means). We’ll have a stronger claim to it when we address the societal ills that plague us.


May 21, 2009

Overlooked criteria for hiring project team members

Filed under: Project Management — Jag @ 5:46 pm

IT recruiting tends to focus only on knowledge of a specific toolset, while ignoring many other (significantly more important) attributes. This leads to substandard developers, business analysts and QA staff, who are putatively proficient in one specific version of a specific toolset, but lack the analytical, planning, and communication skills necessary to perform their jobs well.

A glance at Monster.com will reveal job positions for candidates in “C# programming using .NET 3.5, with ASPX and ADO.NET”, or the corresponding buzzwords in the Java world. Lip service is paid to a few soft skills in the job posting. The screening and interview process is oftentimes limited to validating that the prospective developer knows the desired tool set (he can identify a hammer, and given a nail, knows how to wield it). Today, companies will typically not train a new employee in their tool set, preferring instead, to hire from the market. Little thought is paid to other important criteria that are just as essential if not more so.

Some criteria to evaluate a developer:

  • How many domains has the candidate worked in? Can she talk intelligently about the business aspect of the solutions she has implemented, or is she just a code jockey? Can the candidate be trusted to understand the business problem that is being solved?
  • Given a problem, how does the developer candidate go about solving it? Does he make attempts to first understand the problem, and then develop a plan to address it, or does he dive headlong into coding? Specifically, can he break down a large task into a hierarchy of smaller tasks? Can he denote interdependencies between these smaller tasks, and estimate them? How good are his estimates? (To put it differently, how does he identify that the task needs a hammer to complete, and not a screwdriver or a saw?)
  • Can the candidate communicate well? Can she speak in complete sentences that are intelligible to others in the team? How good are her writing skills? Can she use a drawing tool such as Visio to illustrate a technical concept? (All these skills are essential in documenting a good design). Can she make a presentation to other members of the team in an intelligible manner?
  • Is the candidate teachable? Can she be taught new skills, or new ways of doing things that she already does? Or is it the case that any attempt at teaching or coaching is met with immediate resistance? Is the candidate manageable? Can they work with a project manager to plan and track the project, and report accurate status?
  • How good is the candidate’s Emotional Intelligence? Can he stay calm under pressure, or does he routinely hit the panic button? Can he get along well with other members on his team?
  • What is the candidate’s work ethic? Can they be counted on to pull through in crunch mode
  • Finally — and I kid you not — is the candidate presentable? Are they well attired? (No one expects a developer to wear a three-piece suit, but one could reasonably expect business casual attire in most IT shops, such as khakhis and collared shirts). I’ll not venture into the area of personal hygiene; suffice it to say that you’ll soon be aware of the lack if it when you’re stuck in a meeting room for two hours with no direct ventilation.

Clearly all these factors are difficult to discern in 4-8 hours of interviewing, which is typical for a permanent position and even less for a contract position. For many contractors, much of the interviewing is over the phone, making the process even more difficult. One potential approach to hiring would be to have a temp-to-perm arrangement, with an “up or out” clause. Either the candidate is hired at the end of the temp period (say, six months), or they are let go.

Additionally, businesses would do well to give thought to hiring relatively junior candidates with some of the desirable attributes mentioned above, and then growing them within the organization to progressively senior positions. After all, a toolset can be learned with some time and effort. Many of the above attributes are ingrained in a person, and not easy to change.

May 20, 2009

Ebooks and the Kindle

Filed under: Digital Living — Jag @ 3:31 pm

Amazon’s kindle is being hailed as the next big thing in books. It does away with needing to produce ink on paper, and is touted as the resurrection of the ebook. Additionally, there is a fair amount of buzz on how it is the savior that the newspaper industry has been desperately waiting for.

I, for one, am not so sure. There are a couple (significant) problems with the Kindle that will need to be addressed before it is ready for mainstream adoption.

Problem No. 1: DRM. When I buy a book, I can read it, photocopy a few pages under fair use guidelines, lend it to a friend or sell it second-hand. Kindle titles are wrapped with a DRM scheme. This means that they can only be read on the Kindle device for which it was sold. I’m sure that as you purchase new Kindles, Amazon will allow you to bring over your books to the new device, but still: you cannot share it, and you are restricted from reading it on anything other than your device. In short, a lock-in of your books to Amazon. its ironic that Amazon, which is a large seller of DRM-free MP3 music would choose to DRM-protect its books.

Problem No. 2: Price. The larger Kindle costs close to $500. Assuming that the average book is priced $10 on the kindle than in the print copy, it would require 50 book purchases to break even. Given that the life of an electronic device is somewhere around three years, that would require you to read 50 books in three years to break even. this equates to a book every 3 weeks, non-stop. Read less than that, and you won’t break even. Of course, it could be argued that the Kindle cannot be justified on the basis of cost savings alone, but on the added convenience of not having to lug books around. This justification can, however, be neutralized by citing the comparative advantages of books: chief among them being that you don’t lose a lot of money if you damage one. Further, paper on ink books offer better resolution and color, both things that the Kindle doesn’t.

I read a lot of e-books, some purchased through O’Reilly, and others acquired elsewhere (though to keep my conscience clear, I always purchase a paper copy to ensure that the authors and publishers get paid). I like to read the ebook if I’m working on my computer, and use the paper copy elsewhere. A viable e-book solution would be platform-neutral and DRM-free (perhaps using custom watermarking to thwart pirates). It would be standards-based and work on multiple e-book hardware and software platforms.

May 19, 2009

Brief introduction to the PMBOK Guide (and PMI)

Filed under: Project Management — Jag @ 3:54 pm

I made a presentation to a group of business analysts to introduce them to the PMBOK Guide. In it, I presented the purpose of the guide, its structure, how it maps to an SDLC, and suggested a reading path. I also shared my opinions on the PMP certification and the usefulness of the PMI in general.

May 18, 2009

Is the H1B visa useful to America?

Filed under: Information Technology — Jag @ 10:37 pm

There is a heated debate about whether the H1-B visa program should continue in the face of recession and widespread job cuts. Opponents of the program argue that the H1-B visa is a vehicle for fraud, and for lowering market wages payable to American citizens and permanent residents. Evidence is provided of an ethnic stereotype whose technical skills are sub-par, and whose social skills are significantly worse. Proponents of the program usually trot out one or the other example of a brilliant programmer who came to the United States many years ago, became extremely successful, laid down roots, and started an innovative business that is providing employment to a large number of people.

As is usually the case, the truth is not black or white, but can be found in shades of gray. The H1-B visa has become a vehicle to bring skilled, talented people into the United States, who add significant value, and are paid at the top of their salary brackets. Such individuals do not depress wages. They create additional value. Equally, there is significant evidence for whoever is willing to look with open eyes that the H1-B program, in the hands of storefront “consulting” companies, has become a way to import ultra-cheap labor of questionable quality and competence. This has the dual effect of lowering wages in certain occupations, and driving reasonably competent workers out of those professions, due to the low wages in the marketplace.

The assertion that the H-1B program is being used by certain sections of employers to keep programming salaries low cannot be denied for one simple reason — H1-B employees have little or no leverage with their employers when it comes to negotiating salary and benefits. A US citizen or permanent resident can choose to walk off a job if they find that they are being paid less than what a comparable position would fetch them elsewhere. An H1-B employee on the other hand, does not have the leverage for two reasons. The first reason is that moving to a different employer will require more immigration paperwork (H1-B visas are employer specific), involving time and expense. The second reason is that an H1-B employee is often in the middle of a permanent residence (“green card”) application. The application can take a good part of a decade to come to fruition. And if the employee leaves during certain parts of the process, the entire process needs to be restarted. Thus, even if the H1-B employee is being paid less than what her colleague performing the same job is being paid, there is a strong incentive to grit one’s teeth and bear it, to save the aggravation of either more immigration paperwork or losing one’s place in the green card line.

There is another reason why the H1-B visa is being misused. A large number of H1-B visas are going to individuals recruited by “body shops” of questionable legality, who then place these programmers in various contract positions. Not all body shops are illegal by any stretch, but I am personally aware of individuals with made-up skills and work experience that got in through them. A glance at classified advertisements on the web for body shops (e.g. see http://www.sulekha.com) clearly demonstrates the lack of skill and experience of the potential recruits — the body shops promise to train them in whatever technology is the flavor of the day, before they are placed. If the recruits need to be trained, how can they be highly skilled workers? Classified advertisements on the same website offer “80/20” or “90/10” deals to potential body shop contractors. Under such an arrangement, the contractor finds their own job, while the body shop provides legal cover in the form of H1B paperwork and a green card application. For its services, the body shop takes a cut somewhere in the region of 20%. Note that this is patently illegal but is allowed to flourish. For one, there is no offered job in the bodyshop. Furthermore, there is no fixed salary or benefits. Thirdly, there is a requirement for the contractor to be paid when they are “on the bench.” It is difficult to envision how the body shop can pay a benched contractor under an 80/20 or 90/10 arrangement.

The current debate centers on whether H1-B visas are appropriate given the high unemployment currently being faced in the US. Companies that receive federal bailout funds and hire H1-B workers are now treated as “H1-B dependent employers” under the law. Still, the question arises — should the granting of H1-B visas be suspended? kept level? expanded? eliminated?

There can be no denying the current dismal employment situation all around, even for technology workers. One of the premises of the H1-B program is that workers are imported to address a critical labor shortage. Any honest person would admit that in this present instance, there is no labor shortage. Rather, there is a job shortage. A significant one. Equally, there exist a small minority of individuals whose continued employment is critical to large corporations such as Microsoft and Google. It could be argued that it would cause grave damage to the competitiveness of these companies if they did not have the freedom to hire the cream of the crop coming out of computer science graduate programs, even if they were foreigners.

One way forward that addresses protections for the US worker while giving some latitude to companies is to institute an annual cost of procuring an H1-B visa. This fee would start at $20,000, and would reduce to $10,000 upon the unemployment rate decreasing to a certain percentage. This amount would go straight into a fund meant for training of citizens and permanent residents, and additionally, into increasing enrollments in Computer Science curricula.

A large fee of this nature would still make sense to Google, Microsoft, and friends if their prospective employee was truly highly qualified, difficult to recruit stateside, and contributed significantly to the corporate bottom line. Indeed, it would be akin to the signing bonuses and stock options that these companies offered their recruits just a few years ago.

On the other hand, the fee would increase the hourly rate of body shops by about $10 an hour (assuming 2000 hours per year). Not yet a big deal. but significant enough that the economics of body shopping of unskilled workers starts to erode. By increasing the cost of imported labor, it makes local labor cost-competitive. Yet, this fee would not be so onerous as to completely eliminate H1-B recruiting. It would merely serve to change the competitive equation in favor of those in the US, at a time of significant unemployment.

If we bring in highly qualified temporary workers under a restructured H1-B program, I would also like to see them have the opportunity to lay down roots in the US permanently, through a fair and fast, merit based, permanent residence opportunity — not the decade-long farce that the green card process has turned into. Is it not in the interest of the US that these workers, after they have enhanced their work skills and experience in the US, continue to work, earn, invest in, and enrich their local communities in the US rather than be forced to take it all back to where they came from at the expiration of their visa?

A little disclosure: I had an H1-B visa back during the tech boom of the ’90s. Understand that both sides of the H1B debate (legitimately) argue out of their own self interest — US workers have an interest in restricting the labor pool, which will eventually drive up wages. Employers have the opposite interest — in diluting the labor pool to keep costs down. As always, caveat emptor.

Selection of Projects by Project Managers

Filed under: Project Management — Jag @ 10:33 pm

A surgeon of any repute will insist on examining a patient, and reviewing their medical history prior to agreeing to perform surgery. Similarly, a lawyer will not take up a case until he has a broad level of comfort with the client and some reasonable chance of prevailing. Yet project managers routinely take on, or get assigned to projects, without performing their own go/no go analysis for the project. One possible reason could be that project managers are on staff, thus having to do what they are asked to do without murmur. That may be the case, but I believe project managers still can pull the levers of politics, and find a way to avoid projects that do not have a reasonable chance of success. PM’s live and die by their reputation, and the success of their projects. Picking doomed projects, even if done with the best of intentions, is a sure way to commit career hara-kiri.

Assuming that a PM has some way to accept and decline projects based on a certain set of criteria, the question then arises as to what the criteria are. Below, I offer some thoughts on criteria I would use. These are specific to my skills of being a PM on single projects of moderate size and high/medium complexity. Managers of programs, and larger projects may have a different set of criteria.

Criterion No. 1: How big is the project? If all you’ve managed is 10-15 person project teams with six month project durations, then it makes little sense to accept a project with a team size of a hundred, and taking eighteen months to complete. Smaller projects require a smaller span of control, and deliver quicker. The longer the project and the larger the project, the greater the probability of failure. One option for the project manager faced with such a situation is to work with the sponsor to carve out subprojects, one of which they could own under the umbrella of an overall program. ‘Tis better to be successful managing a small project, delivering frequently than to fail on a larger one with a late or absent delivery.

Criterion No. 2: Who are the people? Does your prospective team see value in project management, or are you seen as the person who brings bagels and signs timesheets? Have they successfully worked with a project managed team before, or has it been an anarchic collection of prima donnas running the show? Does your team have the necessary attitude, skills, and domain knowledge to get the job done? Is there sufficient critical mass of knowledge on the team that if you had to let a person go, it would not affect the team’s progress? In other words, will you be held hostage by “irreplaceable” team members?

Criterion No. 3:
What is the level of support from management? If management imposes scope, schedule or resource constraints, do they own up to it in front of the team? Does the overseeing manager/sponsor attend team meetings at least sometimes? And when they do attend, do they tell the team the same things that they’re telling you? Beware the manager that sees the Project Manager as the hatchet man. Sure, you could be one if you were paid enough, and never had to return to the place again, but be very careful in all other instances.

Criterion No. 4: Why do you want to do it? On a tough project, what’s your motivation? Learning? Money? Promotion? Opportunity to make a difference? Is there a reasonable prospect of your achieving whatever it is that you want? This is an important question to ask yourself — if you can’t find the right answer, your personal movitation is not likely to be sufficient to take you successfully to project completion. What kind of sacrifices do you foresee in the execution of this project? What kinds of opportunity costs? Are you willing to make those sacrifices?

Criterion No. 5: Is there a defined methodology? If not, will the organizational culture allow you to adopt one? It doesn’t matter as much what specific software development methodology you adopt (e.g. SPSG, Agile, Feature Driven Development) as it matters that you have one, and follow it. Conversely, is the organization so completely besotten by one methodology that it sees every single project as a nail to be beaten with the methodology hammer?

One sometimes encounters the argument that for a competent project manager, none of these criteria represent insurmountable obstacles. The picture of the ideal project manager which is often conjured up is that of someone whose people skills rank right up there with Dale Carnegie, who can build teams better than Theo Epstein of the Red Sox, is totally self motivated, a master of all technologies and a domain expert. Sure, somewhere, sometime one might find such a project manager. In the meantime, it behooves the rest of us to carefully consider what we’re getting ourselves into.

Time Management for IS Professionals

Filed under: Project Management — Jag @ 10:15 pm

Most IS projects (if not all) work under severe time constraints. Our optimism in estimation is without bounds. Therefore, it becomes crucial that, as IS professionals, we manage our time as best we can.

There are a number of time management methodologies out there. One such example is the FranklinCovey Focus method. This can be used with paper or Outlook as the implementation device. There are other time management gurus as well — for example, Julie Morgenstern.

I am currently using the Getting Things Done (GTD) methodology which seems to find favor with a number of IT professionals. This method is described in a book of the same name by its author, David Allen. The book is a tough read — he’s stretched into a book what could have been described in a couple succinct pages. Nevertheless, the methodology is both useful and easy to implement.

David sells on his web site an eBook on how to implement GTD with Microsoft Outlook. This is worth a read if you’re into using Outlook as your planner. The option I follow is to use GTD in plain paper. David has a free article that describes how to do it. The advantage of paper is that you’re not beholden to a computer. Plus, you can track both work and personal life in the same planner. I could do that in Outlook, except I’m hesitant to put my personal task list into the Exchange server at work.

The great thing about GTD paper planning is its extreme low cost. My cost for all materials has been about $10. The recurring cost is about $1 each year for filler paper.

Ultra-Brief Review: Heads First Software Development

Filed under: Information Technology — Jag @ 10:14 pm

I just finished a quick read of Heads First Software Development. I both liked the book and was also disappointed by it.

What disappointed me was that the book has a very ambitious title… it promises no less than a complete overview of the software development process. What it does in fact deliver is a very focused sliver; one way of delivering custom built software of low to medium complexity.

I really liked the book as an introduction to agile/iterative software development. There is a lot of good material about many of the buzzwords du jour: user stories, iterations, various testing methods, continuous integration, velocity and the like. For a manager or a developer trying to understand how to write software iteratively as part of a small team, this is a great book.

The book stumbles in addressing other software methods: for example where the architecture is likely to be highly complex, how does the team deal with architecture? Is there an upfront architecture phase? The book seems to recommend the “architecture by accumulation” approach, where the architecture evolves out of a number of small on-the-spot decisions and not a coherent, properly thought through phase.

The book takes a simplistic view of capturing requirements as user stories and then getting the team to estimate based on a very limited understanding of the user story. I have found that in the complex software systems I’ve delivered, requirements need a lot more than a sentence, or a couple on a 3×5 card to document. Furthermore, estimation of the requirements is not a straightforward “x number of days” approach, but is broken up by discipline, based on very specific detailed requirements, and a range rather than a single number.

My concerns notwithstanding, I would recommend the book, with the caveat that the reader keep an open mind about the possible circumstances into which the advocated methodology will fit, and also read, for example, SPSG to get a different perspective.

Personal Productivity for Project Managers

Filed under: Project Management — Jag @ 10:13 pm
I’ve built a personal productivity framework based on three components:

  • Microsoft Outlook
  • OneNote 2007
  • Getting Things Done

Outlook is the standard issue email client for most large companies. So I won’t dwell on it too much at this point. I would advise the interested Project Manager to check out its task management features — most people I know make little or no use of the task management area.

GTD is a wonderful framework to manage your workflow in a very high traffic environment where you receive and process hundreds of email messages. As a methodology, it is more workflow management than time management, though most people use it for time management. Further information about the basic GTD framework can be had from the canonical book, Getting Things Done. The author of GTD also has a monograph on how to use it with Outlook that he sells as an eBook. I recommend that the interested GTD user purchase and utilize this — setting Outlook up is quite easy to use. Of special note is that GTD can be made compatible with PDAs and SmartPhones from either Palm or one of the many Microsoft models.

OneNote is the third leg of this efficiency stool. I have a OneNote book divided into multiple tabs. My tabs are as follows:

  1. Daily standup meetings
  2. Customer/User Notes
  3. Manager Notes
  4. Team Member Notes
  5. Issues
  6. Deployments
  7. Other

There are two features in OneNote that make it virtually indispensible to the project manager: the first feature is automatic saving. In other words, you don’t lose the last half hour’s work if you’ve forgotten to save, and your PC crashes during the middle of a meeting.

The second feature is the ability to create tables very easily. Unlike Word, you don’t need to pick a menu button to create a table. An easy way to create a table with three columns is to type the title for column 1, followed by a tab, followed by the title for column 2, then followed by a tab, finally followed by the last time. An enter begins a new row.

The key to success with this framework is for the project manager to take their laptop with them to every meeting, and be prepared to take notes on the fly.

How do you treat your contract employees?

Filed under: Project Management — Jag @ 10:11 pm

Most project managers in the IT space must have at some point or the other worked with a team member who was not an employee, but a private contractor. If you were in that position, how did you treat such individuals?

One school of thought says that contractors are compensated heavily when compared with “permanent” employees; therefore they are not deserving of the courtesies normally extended to one’s fellow employees. Adherents to this viewpoint insist that contractors must do as they are told, work the hours that they are asked to work, and in general have no business in corporate celebrations or outings.

It cannot be denied that contractors are sometimes paid a large amount of money. And some build up strengths in an organization so they become “permatemps”. Highly paid ones at that. I’ve worked with one contractor who pulled in a quarter of a million a year. And I thought highly of him.

My thought is this… when a contractor is in a significant position to affect your project, either positively or negatively, then they are deserving of the same respect, regard, courtesies and motivation that you provide any of your team members. You really need to ask yourself: for my project to succeed, does this person need to produce at her best? Does their motivation matter? Do I need them to become a team member rather than an hourly-wager?

If the answer to these questions is yes, then I would recommend that you treat contractors with the same regard as you would any other member of your team. This would include taking time to keep them abreast of the context in which the project is operating, seeking their input when project decisions are made (depending on their level of knowledge and capability, of course), and involving them as equal members in team celebrations. When the inevitable push comes to shove, rather than bark orders, paint an honest picture and seek their help in accomplishing whatever it is that you want accomplished. They’re just as human as your other team members.

Next Page »

Blog at WordPress.com.