Since we make the commitment to deliver on time all the time, you know that if we accept the project it will get done. Period.

Q: How can you be expert at both server side and wireless client development? Surely they are very different from each other?

A: Good engineers do good engineering. Certainly there are many differences. Building software for handsets is an exercise in perseverance and cleverness, overcoming limitations of the platforms and the unique quirks of the devices. Server side architecture requires discipline since small design mistakes can make a system fragile to change and brittle under load.

Of course server side architectures are more mature. We implement our services on the Java Enterprise platform (J2EE) and take full advantage of proven and robust open source tools such as JBoss, Spring Framework, Ant, Hibernate, OpenCMS and XDoclet and extend them as necessary. However we are pragmatists and will use commercial software if there is a compelling advantage, and avoid unnecessarily heavyweight solutions. We frequently review the available tools and replace old technologies with new ones as they mature and offer better value.

On wireless platforms J2ME, BREW and WAP we build and grow our own set of tools. This enables us to build more ambitious applications faster that are easy to port across multiple handsets and platforms.

Q: I can hire smart programmers in India for $x/hour. Why should I pay for developers in the US?

A: Maybe you shouldn't! It depends on the product you want to build, the support functions you can provide for the remote team, and the actual team of engineers that will implement it. Very remote development suits a project where you have a detailed product specification and a fairly mainstream set of requirements with few dependencies. You need to allot time and resources for managing the communication cycles and the latencies introduced when working with a very distant time zone. Shipping handsets and cables to the remote team, for example, adds significant latency. Also keep in mind that in many cases you need access to US cellular networks to test a networked application or for over-the-air installation.

We have worked with some good (and some not so good) source code coming from India and elsewhere, and certainly you may reduce expenses that way. When doing the analysis we recommend that you consider first how you validate the quality and competency of a remote team, and second what net saving you expect compared to the total cost of the product. Typically the pure engineering accounts for about 30% of the total cost. The cost of making a mistake with engineering can be both money and time, and time-to-market is almost always the key to success in wireless.

At ThumbJive we don't promise to be the cheapest. We do promise to deliver the right product, on time, and to specification or better. Rather than using cheaper engineers our approach is to use better tools and methods to make each engineering hour more productive. We also offer support and tools at each stage of production, from design through business development to deployment, and if required, training. All in all, in these competitive times ThumbJive offers a compelling value proposition.

Q: If we get another company to develop our product we'll lose control of a mission critical part of our business. Why should we be dependent on someone else?

A: This is a question of competence and integrity. Some consultancy companies, quite often big name ones, give loss-leader quotes to entice customers. Once you are locked in they can make the money back and more later on by charging extra-high rates for each new requirement change. Also you may find yourself bound to the consultancy by an overly complex system that only they can maintain and deploy.

At ThumbJive we believe in right-sizing the solution, that is building a product that is only as complicated as it absolutely has to be. We do use some proprietary tools and libraries, but only when necessary and when there is no comparable alternative. We take a great deal of pride in our engineering skill and commit to deliver the same code that we would want to receive from another team. You will use our services again and again, not because you have to, but because you want to.

When deciding whether to hire and maintain your own engineering team understand that it is difficult to obtain and keep the right skills. In wireless in particular there is a huge amount of arcane knowledge to acquire, much of which is not documented. Each handset, for example, has its own peculiar bugs; often the compilers and other tools don't quite work as they should; the different platforms and carriers have different capabilities. At ThumbJive we have many man-years of experience we can leverage across our whole team.

Q: I have heard that XXX off-the-shelf product / automated porting solution is really good. Why should we pay for a custom solution?

A: If someone has a good automated solution for a particular problem then you should use it. Custom engineering is not the answer to everything. If we know of a better 3rd party solution to all or part of your problem, we will tell you.

Q: We need to get a product to market in four weeks that does these things. Can you start on it today?

A: Sometimes our customers have ambitious goals that no one, not even ThumbJive, can achieve. Since we make the commitment to deliver on time all the time, you know that if we accept the project it will get done. Period. If we think it cannot be done we will work with you to rescope the project to fit to the deadline, or else give you a realistic timeline. Accurate estimation is arguably the hardest part of our business, however it is something we do well: well enough that we're willing to make a guarantee to you.

Services | Products | Technologies | Company | Contact | Site Map | Home
Copyright ©2005 ThumbJive, Inc. All rights reserved.