Recently I got into an interesting argument with one of my colleages. This was related to the sanctity of people who change their identity to meet their job requirements.
With the surge of BPO industry in India there are lot of instances where people have not only changed their accent but also their names to make themselves more comfortable with the cleints. A person who is devoting 10-12 hours in his job and is being referred by this fake identity is bound to get used to that and at some stage it will start reflecting on his behaviour. While trying to adopt to this new culture often it happens that the individual looses his identity which has been nurtured over the years.
This not only applies to the BPO sector but also to the numerous technocrats working in the IT sector who actually have a all-together different background but are now boasting of their expertise in Information Technology. How is it possible? After having studied in say civil engineering, chemical engineering etc they are now trying to adopt to the IT culture.
Needless to say I am part of this.
After having excelled in Chemical Engineering from a leading Institute in India have taken up the work in a software firm. Definitly, this when pointed out by my department professor did take some time for me to digust but then it was too late.
The question which I raise is "Is this change of identity helping our cause in the long run? If no, then what is the alternate?"
I too don't have any answers to this ...
Wednesday, November 08, 2006
Monday, November 06, 2006
War for Talent Heats Up
The October issue of The Economist features the war for talent as its cover story. The article mentions how the shortage of talent has become a top issue and “how the war for talent is shifting the balance of power from companies to workers”.
In fact I have encountered some of the most unprofessional behavior in my own search for talent. Engineering and sciences being the most sought after careers in India means that the softer skills are harder to find. And that means that the balance of power is definitely on the side of the worker. And it can lead to some unbelievable outcomes.
Recently I had given an offer to a candidate. Before joining the company she called up to request for an Offer Letter based on which she can resign from her current job. Once that was done she later called up saying that her current employer has raised her salary and hence her expectations have also gone up. Considering our immediate need for a talented resource we made another offer to make sure that she joins. She however called back, this time requesting for another favor that her brother should also be offered a job and only then is she willing to come. So within a matter of one month she had given me two different reasons for not joining the company after accepting the offer letter, neither of which sounded convincing by any means. Needless to say, she will not be hearing from me ever again.
I am sure we can all relate ‘war stories’ when it comes to recruiting. What is disconcerting is that such scenarios are no longer becoming the exception but the rule as Indian workers realize that the balance of power lies with them.
But unprofessionalism can’t be good for either side in the long run.
In fact I have encountered some of the most unprofessional behavior in my own search for talent. Engineering and sciences being the most sought after careers in India means that the softer skills are harder to find. And that means that the balance of power is definitely on the side of the worker. And it can lead to some unbelievable outcomes.
Recently I had given an offer to a candidate. Before joining the company she called up to request for an Offer Letter based on which she can resign from her current job. Once that was done she later called up saying that her current employer has raised her salary and hence her expectations have also gone up. Considering our immediate need for a talented resource we made another offer to make sure that she joins. She however called back, this time requesting for another favor that her brother should also be offered a job and only then is she willing to come. So within a matter of one month she had given me two different reasons for not joining the company after accepting the offer letter, neither of which sounded convincing by any means. Needless to say, she will not be hearing from me ever again.
I am sure we can all relate ‘war stories’ when it comes to recruiting. What is disconcerting is that such scenarios are no longer becoming the exception but the rule as Indian workers realize that the balance of power lies with them.
But unprofessionalism can’t be good for either side in the long run.
Mobile Data Management
In today's economic scenario all businesses need to have an edge over its competitors in the form of time, cost and support services offered to their customers. To achieve this, the business needs to leverage the power of modern technologies such as Mobile Computing.
Mobile computing using handheld devices empowers the management by providing access to information required for decision making while on the move. It not only helps in better management of information through collection and sharing of data electronically, but also gives the companies a tool they need to:
- Eliminate Paper
- Fast and errorless data collection on the field
- Monitoring (production / sales / inventories etc) while not in office
- Eliminate end of day manual data entry
- Improved Cash Flow from fast and accurate information
- Improved Customer service
The essence of technology comes into play when the unwarranted efforts are reduced and margin of error is optimally minimized. With a multitude of paper based activities and the dependency of the top management to take corrective actions from the information thus inferred, it is imperative to digitize and mobilize the inspection document themselves, thus providing more accurate , timely and cost effective management information which is critical for the success of any organization.
Companies and governments are looking to alternatives to expensive papers based processes to collect information.
Mobile Game Porting
Although the J2ME API is relatively easy to learn, it is misleading to suggest that mobile Java language game development is somehow simpler than developing console or PC games. In fact, in terms of the percentage share of the total revenue, the development and engineering cost for mobile games could be much larger than those for console or PC games. Most of the speakers at the Austin conference agreed that the biggest (and most expensive) challenge in mobile game development is the support of these many different devices in a fragmented market.
The J2ME platform makes the Java programming language and a standard set of APIs available across all the Java-compatible devices from multiple vendors. Ideally, a J2ME application developed for one Java handset should run without modification on all other handsets supporting the same APIs. However, Java's "Write Once, Run Anywhere" vision has yet to be realized, thanks to the fragmentation of the device market. Meanwhile, there are several reasons why there are so many phone models:
• Because mobile devices are highly personal, each one is designed for a very specific usage pattern. For example, enterprise users, consumers, messaging teenagers, price-conscious users, and hardcore gamers all get different phones with different combinations of functions and UI styles.
• Mobile phone manufacturers need to differentiate their product offerings. Different manufacturers adopt different CPUs, memory sizes, base operation systems, and UI features. They also provide proprietary Java extension APIs.
• Operators need to differentiate their service offerings, such as by customizing the device hardware and software. They can also decide to enable or disable certain data service on the device. For example, NexTel would not permit a third-party J2ME application download to general consumer phones on their network.
• Mobile phones are evolving faster than Moore's law, with hundreds of new device models on the market every year. Those devices support different versions of the J2ME standard and different sets of the optional API packages. Right now, the low-end MIDP 1 devices have the largest installed base. But many new MIDP 2 smart phones, including advanced devices that support the J2ME 3D, Bluetooth, and Web services APIs, are starting to take over the high-end market.
Supporting all the popular devices on the market maximizes the J2ME game's chance of reaching the critical mass for commercial success. A Java application needs to be ported, optimized, and tested for each target device it is intended to run on, which is a complicated challenge. For example, even among Nokia products, Series 60 and Series 40 devices have very different screen sizes, memory sizes, and CPU speeds. Furthermore, the quality control of the Java Runtime Environment (JRE) on devices has been weak. Different devices could have different bugs, particularly in their thread or memory management implementations. You have to work around those problems one device at a time. This can be extremely expensive and requires extensive technical know-how to optimize for more than 70-80 devices in house.
According to J2ME game developer Oliver Miao, CEO of Centerscore, today's J2ME game industry has original application developers and specialized porting houses. The original application developer typically develops a generic version of the J2ME game for a representative mass market device (or one version each for the high-end and low-end devices). If the operator is interested in the game, the operator arranges for a porting house to optimize and test the game for all Java handsets it carries.
For beginning developers, Mr. Miao suggests starting from a high-end device with the least amount of computational and API constraints. Those devices allow the developer to focus on the correct API usage and game design instead of advanced CPU and memory optimizations. A Nokia Series 60 MIDP 2 device would be a good device to start with. Then, as you gain experience as a developer, it's a good idea to move toward more restrictive mass market devices. For example, most Nokia Series 40 devices only support 64 KB Java Archive (JAR) file size and 200 KB heap memory size limits. To port a graphic-intensive application from Series 60 to Series 40 requires reworking the graphics and even changing the game play. This step is absolutely essential, though, for the commercial success of the game. As discussed here, the great strength of mobile games lies in the large volume it occupies in the mass market. The low-end devices have by far the largest volume in the mass market. For instance, the Nokia Series 40 devices -- the most widely adopted Java phone ever -- have sold 10 times more units than fSeries 60 devices. The skill to understand the low-end devices and optimize applications for them is what separates novice developers from seasoned ones.
The Nokia Series 40 was the most frequently mentioned line of devices at the conference. Developers love it for its huge market share, but hate it for the amount of optimization work needed to port applications to it. For mobile game developers, it is important to master the skills to scale applications up from or down to Series 40 devices.
The J2ME platform makes the Java programming language and a standard set of APIs available across all the Java-compatible devices from multiple vendors. Ideally, a J2ME application developed for one Java handset should run without modification on all other handsets supporting the same APIs. However, Java's "Write Once, Run Anywhere" vision has yet to be realized, thanks to the fragmentation of the device market. Meanwhile, there are several reasons why there are so many phone models:
• Because mobile devices are highly personal, each one is designed for a very specific usage pattern. For example, enterprise users, consumers, messaging teenagers, price-conscious users, and hardcore gamers all get different phones with different combinations of functions and UI styles.
• Mobile phone manufacturers need to differentiate their product offerings. Different manufacturers adopt different CPUs, memory sizes, base operation systems, and UI features. They also provide proprietary Java extension APIs.
• Operators need to differentiate their service offerings, such as by customizing the device hardware and software. They can also decide to enable or disable certain data service on the device. For example, NexTel would not permit a third-party J2ME application download to general consumer phones on their network.
• Mobile phones are evolving faster than Moore's law, with hundreds of new device models on the market every year. Those devices support different versions of the J2ME standard and different sets of the optional API packages. Right now, the low-end MIDP 1 devices have the largest installed base. But many new MIDP 2 smart phones, including advanced devices that support the J2ME 3D, Bluetooth, and Web services APIs, are starting to take over the high-end market.
Supporting all the popular devices on the market maximizes the J2ME game's chance of reaching the critical mass for commercial success. A Java application needs to be ported, optimized, and tested for each target device it is intended to run on, which is a complicated challenge. For example, even among Nokia products, Series 60 and Series 40 devices have very different screen sizes, memory sizes, and CPU speeds. Furthermore, the quality control of the Java Runtime Environment (JRE) on devices has been weak. Different devices could have different bugs, particularly in their thread or memory management implementations. You have to work around those problems one device at a time. This can be extremely expensive and requires extensive technical know-how to optimize for more than 70-80 devices in house.
According to J2ME game developer Oliver Miao, CEO of Centerscore, today's J2ME game industry has original application developers and specialized porting houses. The original application developer typically develops a generic version of the J2ME game for a representative mass market device (or one version each for the high-end and low-end devices). If the operator is interested in the game, the operator arranges for a porting house to optimize and test the game for all Java handsets it carries.
For beginning developers, Mr. Miao suggests starting from a high-end device with the least amount of computational and API constraints. Those devices allow the developer to focus on the correct API usage and game design instead of advanced CPU and memory optimizations. A Nokia Series 60 MIDP 2 device would be a good device to start with. Then, as you gain experience as a developer, it's a good idea to move toward more restrictive mass market devices. For example, most Nokia Series 40 devices only support 64 KB Java Archive (JAR) file size and 200 KB heap memory size limits. To port a graphic-intensive application from Series 60 to Series 40 requires reworking the graphics and even changing the game play. This step is absolutely essential, though, for the commercial success of the game. As discussed here, the great strength of mobile games lies in the large volume it occupies in the mass market. The low-end devices have by far the largest volume in the mass market. For instance, the Nokia Series 40 devices -- the most widely adopted Java phone ever -- have sold 10 times more units than fSeries 60 devices. The skill to understand the low-end devices and optimize applications for them is what separates novice developers from seasoned ones.
The Nokia Series 40 was the most frequently mentioned line of devices at the conference. Developers love it for its huge market share, but hate it for the amount of optimization work needed to port applications to it. For mobile game developers, it is important to master the skills to scale applications up from or down to Series 40 devices.
Subscribe to:
Posts (Atom)
