2. “In some cases [a hub is] guiding the users to the apps, in other cases it’s pulling data from the app or the app’s associated service” (http://gizmodo.com/5472235/windows-phone-7-apps-what-we-know-what-we-dont)

3. “If you play music, for example, the music will play back as you navigate around the experience and be smooth and glitch-free and all those sorts of things. If you’re using email, we have great support for push email, and that happens in the background.” (http://gizmodo.com/5472235/windows-phone-7-apps-what-we-know-what-we-dont)

So, that looks quite solid from my point of view. Each application may have background services, so if you close application, the service is running. The service could communicate with hubs (there are a lot of articles describing hubs in Windows Phone 7), sound, network and alerts.

Well, actually we don’t have any confirmations about alerts (but I assume “push emails” means some method of notifying users), and about restrictions for third-party applications. There could be some surprises there, but let’s make assumption what background services will be able to play sound, monitor network and perform other hardware-related tasks, as well as notifying users.

So with these assumptions we have to save – that’s everything we need from multitasking on the phone. Really, we don’t need several windows floating around on the small phone screen (actually I think we don’t need them for desktop either – but that’s different story). Instead we need background tasks to do their job, monitor events and inform users about their results.

Lets look at some standard apps requiring multitasking:
- Instant messager. No problems. Background service monitors network and issue alerts on new messages arrive.
- Archivers, downloaders, etc. No problems. They could do their work in background and send alert on completion.
- Route tracking while performing other tasks. No problems if background tasks will have access to GPS functionality as well.

In fact the idea is not new. The same multitasking concept was included in Palm OS 6 (Cobalt). There were 2 types of thread – interface and background and this system worked quite well.

In fact I have only 2 concerns:

1. There could be some restrictions for third-party apps. They could be very painful for developers.

2. Not sure how application closing will work. Windows mobile had issues with not closing applications and I wonder if there will be an ability to close background tasks.

But apart from that, the new Microsoft OS looks more than promising.

First we need to characterize the segment:
- Premium segment targets movies, games and CAD tasks. The tools of this segment are oriented on 3D modelling.
- Low-cost segment targets custom scene rendering. The tools of this segment are focused on scene composition from prebuilt models.
- Middle-cost segment targets the same tasks as previous, but for more advanced users. The tools of this segment are still focused on scene composition, but they also allow material editing, limited modelling and more advanced rendering.

The following features are common for the low-level 3D tools:
- Scene composition.
- Simple rendering.
- Library of models.
- Posable human figures.
- Conforming hair (hair emulation with 3D model attached to human figure).
- Conforming cloth (cloth emulation with 3D model attached to human figure).
The following features are usually present in middle-level 3D tools:
- Simple physics.
- Dynamic hair (change their form based on collisions and physical forces).
- Dynamic cloth (change their form based on collisions and physical forces).
- More rendering options.
- Limited modelling functionality.
- Environment design.

Low-level tools are often paired with middle-level tools by the same company. Many users increase their skills over time and low-level tools become not enough for them. By offering more advanced version, producers don’t loose their customers.

Below is the list of the most 3D tools of the low-to-middle segment with their analysis:

Poser

The most popular tool in the low-cost segment with some features from middle-cost (dynamic hair and cloth). Previous owner (e-frontier) offered Shade as a middle-cost tool, but current owner (Smith Micro) seems to have difficulties with supporting received code. Due to this they stopped selling Shade and started selling Vue from E-On Software as a middle-level companion for Poser. This move seems to be quite wise – currently Vue is the leader in landscape scene building.

Strong points:
- Huge library of models.
- Strong brand.
- Rich set of features.

Weak points:
- Quite obsolete interface.
- Weak development in recent years.
- Very weak library management (items are stored in a bunch of files, so there is no user-friendly method of adding/removing library items).
- Obsolete concepts of conforming hairs and cloths can’t handle collisions.
- Very limited set of dynamic hairs and cloths.
- Most hairs and clothes are incompatible between figures.

Daz Studio

Free tool from Daz3D designed to be Poser-compatible. While it still misses some Poser features (dynamic hair and cloth, some material options, etc.) its under very active development and seems to evolve much faster.

In the near future Daz3D is going to add poser-incompatible dynamic cloth plugin to the Daz Studio. The plugin is going to combine collision handling from dynamic cloth with nice look of conforming cloth. But since the plugin isn’t released yet, this statement is difficult to proof.

Daz3D offers Carrara as middle-level pair for the Daz Studio.

Strong points:
- Access to Poser libraries.
- Very intuitive interface.
- Active development.
- Very rich set of plugins.
- No cost.

Weak points:
- All Poser libraries disadvantages.
- Some Poser incompatibilities.

MakeHuman

Opensorce product for designing human figures. It doesn’t allow scene composition, but still could produce great results if paired with any other 3D tool.

Makehuman 1.0 which is currently under heavy development, is going to introduce hair and cloth support, which could make it a great Poser competitor.

Strong points:
- Open source.
- Full compatibility between models (we’ll wait for hair and cloth support to see how well it will be).
- Active development.
- Accurate human modelling with huge number of options.

Weak point:
- Restrictive GPL license prohibits integration into commercial aplications.
- No compatibility with existing libraries.

Carrara

Carrara is Daz3D middle-cost tool. In the recent years Daz3D stopped development of specialized products (Bryce for landscapes and Hexagon for modelling), trying to make Carrara one tool for all. However, Carrara landscape design is still weaker than in Bryce, so currently Daz3D have no competitor to Vue in this area.

Also, Carrara has the same problems as Poser – it changed too many owners and current development is quite slow. This makes Daz Studio – Carrara pair less effective, since Daz Studio development is much faster. For example, there is no plans to support dynamic clothes in Carrara. It is rumored that in the future Carrara could be replaced with something like “Daz Studio Professional”.

Unlike Vue, which imports Poser content using Poser itself, Carrara has its own support of Poser content. However, the compatibility is even more limited than in Daz Studio. Carrara has support for dynamic hairs, but they are incompatible with Poser.

Strong points:
- Good “all-in-one” tool close to premium segment.
- Modern interface.
- Poser content support.

Weak points:
- Slow development.
- Lacks 64-bit version (due to powerful set of features, especially in rendering, 32-bit version crashes with “Out of memory” very often).
- Limited support for Poser content.
- Problems with Daz Stusio compatibility.

Vue

Vue is environment design application. However, due to powerful renderer, Vue is a good companion for low-cost 3D tools. User could setup and pose human models in a low-cost tool and then place it into Vue environment and render.

Vue even supports posing figures right inside it, using Poser. However it is not recommended on 32-bit systems – Vue has the same memory problems as Carrara in 32-bit version.

Strong points:
- Leading environment design tool.
- Powerful renderer.
- 64-bit version available.

Weak points:
- Narrow specialization.
- Lack of internal posing support.

Conclusion

While the market seems to be very rich, it suffer from obsolete concepts. Most of the 3D content available is based on 10-year old Poser approaches (this statement mostly relates to human figures and hairs/clothes for them).

Two tools has a good perspectives:

Daz Studio’s approach is to add modern features while not breaking compatibility with huge set of Poser content. Going this way Daz3D has a very good chances against quite stagnant Poser.

MakeHuman offers fully modern approach, including figure unification. However its success will greatly depend on number of cloth models produced for it.

Countries like Latvia or Ukraine have a lot of top software developers who lost their work recently. And in contrast with other countries with strong IT, Eastern Europe couldn’t find new jobs for these people.

Hiring the newly jobless professionals is a tricky task, though. Their English is usually at “technical” level (just enough to read technology manuals and leave code comments) and they rarely know how to sell themselves on freelance websites. The jobless top software developers also often doesn’t have a portfolio, since they usually work on large projects, which could be of internal use and/or even unfinished.

To work with this kind of professionals it is required to have a native speaker, who is on the one hand familiar with the project and on the other hand familiar with Eastern Europe software development environment. Lets call this person a representative, since his/her role is to play on the project owner’s side in the developers’ language.

The first task for the representative will be gathering CV from the sites native to developers. With the database, remote interviews should be done to determine actual skill since (remember this?) portfolio could be irrelevant.

After the team is gathered, the representative should be used in the communication between the project owner and developers. It is usual for Eastern Europe software developers to have enough English skills to read documentation, but not enough to discuss it. In this situation representative is the only person who could ensure understanding for both sides.

There is also an interesting side effect of using the representative. Most top software developers prefer agile software development practices, which require skills and constant communication from the customer. With trusted representative, who plays the customer role in the agile processes, this could be done.

But there are also disadvantages in the approach:
- The language performance was sacrificed to development speed. The long-awaited Ruby 2.0 is going to make it better, but Ruby will never be a performance competitor for Java or .NET.
- The language is almost unusable for novice developers. Lots of advanced features and overgrown semantics makes the Ruby code totally unreadable for unskilled programmers.
- Good Ruby developers are not only expensive. For many of them programming is art, not craft. While this kind of people produce beautiful code, they rarely follow time constraints.

The key of Ruby success on the web is Ruby on Rails framework. It had a lot of revolutionary and unique features at the time of appearance. Of course, modern frameworks in other languages already adopted these features, but RoR (as Ruby on Rails usually abbreviated) took its piece of pie.

The RoR have another advantage – it dominates the Ruby world (Ruby have a couple of other frameworks, but they aren’t competitors). While Java, for example, have much wider community, it is spread over dozens of approaches. So by consolidated efforts of the Ruby community, RoR have a very rich set of plugins.

The weak point of RoR is pre-built solutions. There are some content-management systems, blogs, etc., but they aren’t so consolidated as RoR framework and thus have very pure community.

So to summarize this. Use Ruby on Rails in the following cases:
- There are a lot of custom requirements, making pre-built solutions poorly usable.
- Project expects high maintaince, probably by different teams. A lot of additional requirements could appear during or after development.
- All performance-critical functionality (such as multimedia processing) is clearly separated and could be done in another language. This requirement applies to PHP as well.
- There is a team of Ruby developers ready for the project.

It is not recommended to use Ruby on Rails if:
- There is a pre-built PHP solution which fits the project’s requirements.
- Part of the project interface is performance critical. Or interface have very tight connection with performance-critical parts.
- The project’s team need to be build from scratch.

First thing is cheap sites. Initially PHP was used to add some functionality to an HTML page structure. It is still used this way very often. The sites built this way cost not much more than plain HTML.

Second thing is a cheap hosting, even free. Since PHP is often used for cheap sites with minimal functionality, it’s easy to host a lot of different sites on one physical server without virtualization and other complex things.

The third thing is cheap developers. PHP is easy, if you use it with the cheap sites approach. This is the point where PHP kicks out all other server-based technologies. If development for Ruby on Rails is 2 times faster than plain PHP, it still have no sence if the PHP developers are 3 times cheaper.

The fourth thing is cheap software, usually open-source. PHP developers are numerous and they produce a lot of free and cheap stuff. So it is very common way of website development – just use a pre-built PHP solutions and customize it for your needs.

Of course, words “cheap” and “simple” have their drawbacks.

First, the PHP technology is oriented for easy development not efficiency (Ruby have the same issue, but it is oriented on very, very different kind of developers). If you need to make something complex – you need to do it externally. Usually Unix C applications are used for this purpose. If you have complex requirements – say goodbye to cheap hosting and say hello to expensive developers.

Second, PHP promotes bad architecture. Architecture is the thing, what needs to be learned (object-oriented approach, template-driven websites, etc.), so basic PHP is designed to live without it. If you need a large project, be very careful with PHP – the result could be a maintenance disaster.

Third thing is what most of the pre-built PHP solutions (content-management systems, social networks, etc.) were started by cheap developers with very weak architecturing skills. I think this occurs because experienced developers prefer to develop existing solutions instead of reinventing the wheel. Anuway, all the PHP solutions I’ve studied, are internally catastrophic.

How to make use of PHP pluses, negating its minuses? Here are some guidelines:

First, the PHP is for interfaces. Separate the performance-critical parts from the requirements. If these parts are tightly coupled with interface, it is better to proceed without PHP, otherwise use it freely.

Second, seek experienced PHP developers. There are many people who learned a lot in PHP, but for some reasons didn’t move to other technology. They are usually cheaper than, for example, Java developers, but have enough skills to produce well-architectured projects.

Third, use pre-built PHP solutions with a history. During their evolution, the solutions usually learned to hide their disadvantages. For example, in WordPress architecture, any module could ruin other modules or even the system core. But the WordPress developed naming conventions, which, if strictly followed, prevent the collisions.

The examples of useful open-source PHP projects at the time of writing are: WordPress and Drupal. Joomla have a long history, but there are still a lot of pitfalls in it, so choose it with care.

Fourth, if not use pre-built solution, use frameworks. Framework is architecture “skeleton”, so if developer follows it, this ensures quite good architecture. It is also very important, what this architecture will be easily understandable for other developers with the framework’s knowledge.

Most popular PHP frameworks are Zend Framework (from the company developing PHP itself) and Symfony. Both have good and flexible object-oriented design.

There is one pitfall of the frameworks, however – developers could make sites “near” the framework, so it is installed, but mostly not used. To prevent this, use experienced developers as supervisors, preferrable with high scores on the framework-related tests.

So it seems logical to select the technologies first and the development company basing on it. The perfect way is to use independent consulting on this stage, but I’m going to give several guidelines on the technology choice here and brief overview of the most popular technologies in further materials.

Critical parameters

The first criteria is environment:
- Desktop (list of operating systems).
- Server (list of operating systems).
- Mobile (list of operating systems).
- Browser (list of supported web browsers).
- Plugin (list of supported applications).
Each environment have its own strong, weak and completely inapplicable technologies. So at this step we could greatly filter our technology list.

For application there could be multiple environments. In this case it is useful to check which environments have shared functionality and which aren’t. For example – client and server applications usually don’t have shared functionality, while different clients (i.e. Windows, Linux and Mobile phones) have. The general rule is simple – in case of shared functionality it is recommended to use one technology to reuse the code.

The next criteria is critical requirements, like application performance or direct working with hardware. By analyzing these requirements it is possible to finally make a list of technologies to choose.

One important thing to note is that application for one environment could be made with several technologies. For example it is possible to make performance-critical modules on fast low-level languages, and combine it with GUI written in high-level language for faster development.

Additional parameters

After the first phase we already have a list of possible technologies. Now we need to optimize our project to develop it fast and cheap. It is recommended to make a full list of technology variants, gather additional parameters for each of them and later estimate. Here come the additional parameters.

The first criteria is library availability. Most projects have a lot of common functionality, so it seems logical to found the things already done and reuse them. Libraries could be open-source (in this case developers could fix the bugs and add features if needed) or proprietary (in this case you could count of support). The libraries could come in form of framework or even customizable application, general principle is the same – reuse code to reduce the work.

Second criteria is resource availability. For some technologies developers are very rare, for some – common, but costly, etc. This corresponds with code quality question, since different parts of the application may require different developer qualification.

The last and slightly mythical criteria is development speed for the technology. This question caused a lot of holy wars between developers, but in general it’s still a question of libraries coming in the standard technology set. With the modern IDEs programming languages don’t have a significant difference in the development speed.

Now you have different variants of realization and all the criterias affecting the time and cost. So it is time to make estimations and compare the results. If the winner variant was found you may start searching for developers. But once again it is strongly recommended to use independant consultant on this step, unless the choise is obvious.

The good architecture is documented and is using standard names for architecture patterns. Making architecture documentation doesn’t create a lot of overhead work with modern development tools, but it have a lot of value. The good architecture helps in 2 things: refactoring and switching to the new developer (even without the change, developer could forget some parts of the architecture and it will cost additional work).

The need of refactoring I hope to discuss another time, but most of the big projects change their structure several times during their lifecycle. So making the project refactoring-ready is recommended in most cases. Changing developers is unpredictable, so it’s also recommended to be ready for this.

There are also parts where you don’t need architecture skills from your developers. First case is really simple projects – documenting the architecture may be considered overhead if the project structure could be easily understood from the code itself.

Second case is not very complicated “extension” projects. If your team makes plugin to existing system, there usually are some guidelines for making these extensions. If your team follows them, the project is much easier to understand, so larger projects could be readable without architecture. Using frameworks is the same case.

Third case is complex projects with a dedicated architecturer (team leader, senior developer, etc.). In this case other team members could have low architecture skills. This is a very common practice for large companies trying to decrease their expenses.

Note: The good architectured project should also be split by layers and areas of responsibility. In this case you could have GUI designer without programming skills working with themes and templates; you could increase and decrease your developer team to match the timeline, etc. Of course, this makes more sense for the large projects.

Quality of code

The code quality consists of three parts – readablity, comments and performance.

The readability doesn’t require any additional work (standards are usually applied by the development environment, and correct naming is just a matter of practice), but they help a lot in case of project transition to another developer. So no discussions here.

Comments are more difficult point – some theories propose writing self-explaining code, but at least comments should be enough to feed documentation generator.

Code performance may seem very important, but it doesn’t. In real projects, only small amount of code have major effect on application speed. So it is often recommended to provide performance optimization at final stages of development after the performance tests (I already mentioned refactoring, it is used for this optimization as well).

So, the only requirement to the coding quality in most cases is to follow the standards. The high requirements are required only for architecturing and optimization, which is not very large amount of work.

Unit tests

Not to be confused with the testers’ work, unit tests are created by programmers for themselves. Unit tests are part of refactoring (mentioned two times before) and they could be run automatically. Their goal is to ensure what all parts of the application are still functionable after the changes.

The unit tests shouldn’t be necessarily written by the same programmer (it’s very common case – if good developer receives bad code, the developer writes missing tests at first, understanding the code in progress). And they don’t need to be written from start – they’ll be required before the first refactoring. For large projects this moment comes very soon, but small and/or strictly architectured projects may live without refactoring for a long time.

Note: Do not be confused, thinking that strict architecture saves time by eliminating the need of refactoring. First, the strict architecturing usually takes not less effort and, second, there will be unaccounted factors, which will usually lead to refactoring even in the strictest architecture.

Security

The security is mostly valuable for web and system applications. To make code secure, you don’t need high-quality programming. The situation is simple – developers need to follow standards and at the final stages of development, security testing should be performed.

It’s better to have a separate person for security testing – he/she should be more hacker than developer. This is one of the places there freelance shines – regular software development company couldn’t afford high quality security tester in office, but could easily hire one as freelancer.

Conclusion

The developer quality plays major role only if the developer doing all kind of jobs in the project. If you have 3 or more developers, it’s reasonable to have one highly-experienced team leader with architecturing skills. Other developers could be of average quality – they just need to know the standards, plus there should be dedicated people for testing, including security one.

The testing was almost uncovered here, I hope to make a separate post for it.

When you start moving a software development project to offshore, the most obvious choise is a partnership with big companies. They are the first in search engine results, you could found them through advertizing and if you put your project to freelance auction, the first bids will come from big companies. But obvious variant isn’t always better.

The main problem of big companies is what they have a lot of expenses. The larger company is, the biggest share of employees becomes management staff. Large companies require very stable income, so a lot of money is spent on advertizing and other additional project sources. So without additional measures the development with a large company would cost 2-3 times more than independent development team.

The second problem is developer cost. If you sell developer hours, their salary couldn’t be more than 30-40% of external work. If you sell software product, you don’t have this cap and usually could raise your developers’ salaries. This situation forces offshore companies to loose competition on the local job market.

For increasing price there is only one solution – the companies create an illusion of guarantees. They have big portfolio, US legal entities, many persons to contact, etc. And customers are usually ready to pay for guarantees.

The cost-quality exchange

The most obvious way for decreasing expenses is using lower-quality developers. They could be people not suitable for product-making companies. Or they could be people from country with undeveloped IT-infrastructure (and so not having product-making companies). The result is the same – lower salary, lower quality. Simple convertion.

Another method could look awfully for western people, but it works. The company could lay financial risks on developers. The scheme is simple. The company sends you a standard $10.000 proposal (no analytics – additional economy). The team will get no more than $5000, no matter how many they are and how many time they’ll spend, so the company will always have profit. Of course, it’s the same cost-quality exchange – programmers will not work in such conditions if they have a choice.

Note: I’m speaking a lot about developer quality. I think I’ll make a separate post aboit it, since the theme is not as simple as it looks. For now I’ll speak it simple: for many projects, low developer quality means unacceptable results.

The more complex approach

All the methods described above were marked simple, but the simple way is rarely effective. I’ve seen several companies evolved in the growing competition. Usually they ended up with a scheme with 3 levels of developers. This approach is not seen very often, but in some cases provides very good results.

The top level employees are senior developers. They are the treasure of the company and keepers of the knowledge. Their salary costs company more than it earns from their work directly. These people took their part in initial project analysis and about 10% of work in each project. Their job is architecturing, standards and technologies – the most difficult parts. And they gather a lot of experience, having 5-10 times more projects than regular developers. The senior developers rarely leave, but if they are – it’s a great stress for the company.

The average level employees are regular developers. They do most part of the job (60-70%), they have some experience and, usually, a specialization. They have a low salary, which compensates the company expenses (including high team leaders’ salaries), so they leave often and easily. Others become senior developers and some are just too lazy to leave and remain regular developers for a long time.

The lowest level employees are junior developers. Usually a students, they aren’t ready for working without control and are not interesting for the product-making companies. They aren’t doing a lot of work, and aren’t earning significant money. But they study a lot and eventually become regular developers, sustaining the cycle of life.

The advantage of this scheme is very high quality of senior developers, so the project could be analyzed and architectured properly.

The main disadvantages are a lot of required time (due to low qualification of regular and junior developers) and significant possibility of loosing a dismissed developer during the development process.

The companies of this scheme are usually have higher costs than low-quality ones, but they demonstrate great skills during the initial communication.

Problem description: Developers work slow with lots of bugs and are unable to make a research work.
Solution: The problem usually occurs during working with large offshore companies. If you need a top-quality staff, you need to pick them yourself. Or you may hire an independant consultant from the same country to pick them – the only requirement is direct hiring of the developers. On the other hand, if you need low-qualified workers (for manual text recognition, for example, or creating html pages for your website), offshore companies are preferrable.

Legal issues

Problem description: It is much more difficult to charge offshore company for not doing their part of agreement.
Solution: Large companies usually have US and/or Europe representation, so they could be charged and if not, they are too vulnerable in their reputation. So this applyes more to individual developers. To solve the problem (in both cases) you need to split the work into smaller cases and gain all the deliverables at the end of each phase. In this case conflicts will not cost you much and you’ll be able to continue the work with another team (see: “Working with fixed budget“). With the individual developers you also have an advantage of changing only part of your team, which is much easier.

Lack of control

Problem description: Customer can’t directly control how many hours developers spend and how much time they really work on the project.
Solution: You need a consultant, which will check the reports. In case of large offshore company, this will be a double work (their project managers do the same), but with individual developers this will be a natural control. In addition, working on fixed price makes this problem less, especially with individual developers, since you pay for work, not hours (for large companies there is still risk of loosing time if the developer will be actually assigned part-time).

Lack of communication

Problem description: Customer have a very limited communication with developers, usually through email. Sides may have a language barrier. Communication may be limited by time zone.
Solution: You don’t need to rely on direct communication. Documentation (preferrably in form of issue-tracking software, in my opinion) works much better than voice chatting. You may also use a consultant (aside, not between you and developers, direct communication is a must) who may generate ideas and solve problems by speaking with developers.

The Cost of Selecting a Vendor

The selection costs include documenting requirements, sending out RFPs and evaluating the responses, and negotiating a contract. A project leader may be working full time on this, with others chipping in, and all of this represents an opportunity cost. And then there are the legal fees.

To top it off, the entire process can take from six months to a year, depending on the nature of the relationship.

At this stage, travel expenses enter the picture as well.

Comment: This point really matters. But only in one case – you are working with a large company. If you are building a virtual office by hiring individual developers, you have good control over them.

The same applyes to travel expenses – you don’t need to visit individual developers to make things work. In most cases you don’t need to travel even if working with large company, but it’s a personal preference.

The Cost of Transition

The transition period is perhaps the most expensive stage of an offshore endeavor. It takes from three months to a full year to completely hand the work over to an offshore partner. If company executives aren’t aware that there will be no savings—but rather significant expenses—during this period, they are in for a nasty surprise.

Comment: This point probably had sence in 2003, but is completely obsolete now. You may demonstrate your application through remote desktop. You could perform videochat with screensharing and a lot of modern things, which make the personal connection completely unnecessary.

The thansition costs exist, but moving to offshore costs the same as moving to a new local developers team. And, of course, this applyes to a new project only.

The Cost of Layoffs

Laying off American employees as a result of your offshore contract poses other sometimes unanticipated costs.

Comment: It makes sence but only if you are moving your existing project to offshore. If you start a new project, this point doesn’t matter.

The Cultural Cost

One reason for that is the American workers’ comfort level with speaking up and offering suggestions.

Additionally, offshore vendors often lack developer experience.

Comment: This point applyes if you try to move everything to offshore mindlessly. If doing carefully, you may take even more from offshore workers. For example, you could hire a Russian animation character designer, which level is close to level of people working for leading animation studios. The offshore is the only way of hiring such professionals, if you aren’t Walt Disney. Just don’t try to use regular software coder as project lead and you’ll not have any additional costs here.

The Cost of Ramping Up

Most of the Indian offshore companies are ISO certified and at Capability Maturity Model (CMM) Level 3 or 5. If your own staff can’t get used to working at that level, you’re going to have a major disconnect.

Comment: This couldn’t be completely considered as an additional cost. Teaching your staff to work according to highest standards, strategically decreases your costs. And anyway, this applyes to working with large companies only.

The Cost of Managing an Offshore Contract

There’s a significant amount of work in invoicing, in auditing, in ensuring cost centers are charged correctly, in making sure time is properly recorded.

Comment: Yes, this is an additional cost, but again and again it applyes to working with large companies only. Their project managers control their staff and you need to control their project managers, paying for both layers. If you remove the extra tier by working directly with an offshore staff, you’ll not paying any additional money.