Our client Pana.ma just launched “Voice Messenger”, the world’s first integrated voice and texting service. Free-of-charge, Voice Messenger enhances traditional texting because users can now seamlessly add their voice to text conversations for simple convenience or when emotion and meaning cannot be conveyed by text alone. Because Voice Messenger is just like texting, Pana.ma is simple and intuitive for anyone to use.

The service is built on Pana.ma’s communications platform that answers the growing need for consumers and businesses to communicate asynchronously in the mobile or Web context using their voice as well as text. Users can easily create one-to-one or multi-party conversations (or conversation networks) by picking names from their address book or by searching the service’s user directory. These conversations can persist indefinitely.

“With virtually everyone mobile now, younger generations are calling less, texting more, and generally dismissing voicemail. We started Panama to add and deliver voice into the texting ‘paradigm’ because kids told us they wanted it!”

said David Hayden, co-founder and CEO of Panama.

“Texting is the communication mode of choice because it is more immediate, efficient, non-invasive, and convenient than any other mode (including calling). We simply saw that voice was missing and needed to be there to add the emotion and meaning that texting lacks. It’s a simple adjustment, and a natural evolution, but we think that this is a service that will have a radical impact on how we communicate.”

Available first to iPhone and 2nd generation iPod Touch users, Pana.ma’s service enables anyone to freely mix text and voice in a single conversation thread. The service will also be launched on additional platforms over the next two months.

The Pana.ma service includes the following features:

• Seamless integration of voice and text in any conversation thread
• The only mobile solution for sending and receiving private messages with a group of people
• The ability to create public and private conversations
• The ability to play back a conversation in part or in its entirety
• Unlimited messaging and unlimited storage
• Access to the only public forum for voice messages so anyone can easily create and participate in public conversations of interest
• Cost savings by eliminating reliance on traditional text messaging
• Alerts for new messages, even when the app is not running

This is really a super cool service, which we are now using to improve the communication with our own customers. Pana.ma is available on the AppStore; download it and send me a voice message @ remi.

Personal, Technical | No Comments »

I recently came across several very similar situations with software start-ups located in the Bay Area.

Venture capitalists seldom invest in software start-ups nowadays, especially if their product relates to WEB 2.0, social networks, or other online businesses. They first want to see (i) an initial product financed by the founders and (ii) some market traction. Market traction clearly means revenue; a sizable number of free users/subscribers is not recognized as market traction anymore.

It might not be that bad after all. We are back to a more traditional business model where entrepreneurs have to contribute their own savings, and turn to business angels, incubators or friends and family to complete their initial round of funding.

Budgeting and raising the proper amount of money required to get a product to market is critical, and entrepreneurs cannot afford any mistake, as these first dollars are likely to determine the fate of their new venture. The equation is simple: the initial funding has to take them to a point where their venture becomes either sustainable, or at least shows a demonstrable revenue model. If this goal is reached, then raising more money should not be an issue; if not, it would be highly challenging to get any extra funding.

And just because delays seem to be an intrinsic part of the software industry, entrepreneurs should always spend wisely and even keep a cash reserve when possible.

Some unnecessary expenses that were the hallmark of VC-funded start-ups have disappeared already, and that is very good: high-end offices stuffed with expensive furniture, company’s catered parties, oversize administrative team, etc.

There is still one area though where entrepreneurs tend to spend too much money, and that is on their development effort.

I can think of 2 major mistakes there, one happening when there is solid funding and the other when there is not enough funding. Let’s illustrate the point with these 2 sentences we all have heard too often:

1 – “We want the best developers, and we will pay whatever it takes to assemble the dream team.”

First, and unless the entrepreneur is the most wired person in the Valley, chances are he/she won’t be able to attract the shining stars. And that is not even the real question; if the very best developers are required to get the ball rolling, then the concept might not be as good as it sounds. The founder’s role is to over motivate his/her team, not to find and hire shining stars; shining stars who by the way are very unlikely to join any start-up, especially during these hard economic times.

2 – “We have very limited funding (=not enough), so our team works mostly, if not entirely, for equity.”

In this case, the developers will become rapidly impatient, or will not give their undivided attention to the project. Bottom line is that precious cash (and precious equity) will be burned away for little result. Remember, getting only 80% of the first version of an application is getting nothing! In most cases, it will be easier to rewrite the code entirely, as opposed to trying to understand the existing stack. How many entrepreneurs have the cash to afford the rewrite of their initial version?

I meet at least 4 to 5 times a month with entrepreneurs who have spent their funding with no results and are turning to established outsourcing companies, offering them to finish the work for equity! Hello??

Remember, the first dollars are essential. If you were unable to deliver, why should anyone take the risk to commit their resources for an equity that is already worthless?

I do not mean to be rude, but I witness these situations too often. If you are an entrepreneur, spend wisely with your developers. My observation is that in most cases, the technical challenges are not as big as many entrepreneurs think they are. Technical problems tend to grow with the success of the company. Trying to anticipate too much at the beginning is just counter-productive.

And remember, turning to an outsourcing company that will work for a fixed price is often the best way to spend less, limit your risks and prepare for the next steps. And finally do not worry, if your business does take off, you will be snowed under by resumes of the Bay Area’s “best” developers.

Remi Vespa
Venus Software International

Business, Technical | 4 Comments »

I spend a fair amount of time on line, browsing the news, and reading various blogs. Also, being an Entrecarder, I come across a lot of great blogs every day, which I would love to read and digg.

That said, I just cannot dedicate enough quality time during the day to read these articles. I usually send them to my Google Reader, to further consideration at a quieter time.

Problem is I do not have much free time indeed, and when I finally manage to access my Greader, I am frustrated to find a whole lot of posts there, way too many for me to catch up.

I just found an interesting post called “10 scripts to muscle up your Google Reader”, which provides great tips on how to optimize the use of Google Reader. My favorite is the “Greader to Twitter”, a feature that sends a reader post to twitter.

A must read for those of us who spend a lot of time reading on the Internet, a population that includes the Entrecarders.

Technical | 3 Comments »

TCS have a white paper available on their WEB site called Evolving IT from ‘Running the Business’ to ‘Changing the Business’.

The first part of the document is loaded with some very interesting facts on software development success and failures.

I found amazing to see that the overall quality and reliability of the end-result software has not really improved while the tooling (computers, networks, development environments, etc.) has improved so dramatically. In fact, the actual percentages are only slightly better than they were 10 years ago!

Here is an excerpt of their paper.

For a number of reasons, business-critical software and services projects, whether done in house or outsourced, fail far too often. They take too long. They cost too much. They are riddled with defects and don’t accomplish the business goals for which they were designed. An August 2007 study by Dynamic Markets Limited of 800 IT managers across eight countries shows that:

• 62 percent of organizations experienced IT projects that failed to meet their schedules
• 49 percent suffered budget overruns
• 47 percent had higher-than-expected maintenance costs, and
• 41 percent failed to deliver the expected business value and ROI

Moreover, broad industry consensus indicates that more than one-quarter of all software and services projects are canceled before completion, and of those that are completed, up to 80 percent of budgets are consumed fixing self-inflicted problems. According to Gartner Research, “The lack of testing and QA standards, as well as a lack of consistency, often lead to business disruption, which can be costly.” Gartner also reports that “testing consumes 25% to 50% of the average application life cycle and often is viewed as adding no business value.”

Failure of software and services projects is so widespread and so commonplace that 43 percent of IT managers say their business managers and Boards of Directors. Quite understandably, only 11 percent of business organizations consider technology a “strategic weapon,” according to a recent study by Info-Tech Research Group.

I think we should really ask ourselves why these figures have not improved over the years while computing power and development environments have progressed tremendously.

There are many reasons for failure. However, and from the many discussions I have with our project managers and clients, I believe that estimates for the coding times are now relatively accurate, something that was not necessarily true 10 years ago. The purpose of this post is to highlight 2 areas that are still underestimated, causing projects to fall behind schedule:

1. When doing estimates, project managers rarely account any extra time between design and development, an omission that costs dear. Transferring know-how between designers and developers should not be underestimated.

   When using traditional methods like waterfall, this transition time enables to account for the many adjustments required between design and development, a significant time overhead.

   Agile-like methods, because of their empirical nature, require extra-time too, to compensate for the (many) requirements churn that happens during sprint time.

2. The second reason is that QA is still not understood properly, and too often reduced to bare testing. When we provide our clients with our estimates, they usually try to have the time allocated to QA reduced significantly; and the less technical background the people negotiating possess, the higher time reduction they want.

Writing an application can be done relatively rapidly, when seasoned developers are involved. However, making the application fit corporate quality standards can sometimes be a much bigger challenge than the writing of the application itself. If no time has been accounted between design and coding, and if QA times are significantly lower than coding times, expect bad surprises!

Business, Technical | No Comments »

Netcipia® is a WEB 2.0 startup that specializes in participative Web technologies (www.netcipia.com).

The two co- founders have been working together in the field of online collaboration for over a decade. During that time, they have gathered the feedback of hundreds of thousands of users worldwide and acquired a unique expertise and vision. The Netcipia participative platform is built upon this expertise and vision.

In addition, Netcipia’s CTO Miguel Membrado had previous offshore experience and therefore knew about the dos and doesn’t of offshoring; so when he approached us, he had a clear plan on how to allocate the money he raised from angel investors.

First, Netcipia was looking for a partner willing to share their financial risks. In fact, during the fund raising process, Netcipia committed to their investors to bring their product to a given level for a given price. So we, as an outsourcing supplier had to endorse this commitment.

That’s about sharing financial risk.

Their technical requirements to Venus were to provide with:

• Developers expert in J2EE, open source solutions, and Agile (SCRUM) methodology
• With existing knowledge on WEB 2.0 platforms since Netcipia was to be built on an open-source wiki solution
• Flexible enough to cope with fast evolving specifications
• Capable of interfacing with a software analyst and a GUI design team located in the USA.

Venus benefited from Miguel’s expertise in advanced collaboration tools. A solution based on wikis and blogs was implemented to optimize the ongoing communications between the parties, located in Palo Alto and Shanghai.

Venus assigned to this project a team of 5 senior developers and an administrator working under the supervision of a senior project manager.

Netcipia successfully went live early March 2008.

Venus is now working on the next version of Netcipia, which will provide a tighter integration with some popular WEB 2.0 platforms.

With engineering expenses under full control, the Netcipia management team can focus his efforts on expanding Netcipia’s business, en route toward becoming a global leader of monetization platforms.

Business, China, Technical | 1 Comment »

Our prospects and customers often ask us to recommend a development environment for a given application.

A really tough call, for so many parameters come into play when making a decision.

I would like to share few dos and don’ts when picking a language.

• Do not believe that picking the solution from the market leader (IBM then, Microsoft now) is less risky.

  Remember the “you cannot be wrong with IBM!” I do not know who coined this non-sense. Of course you can be wrong with IBM (or with Microsoft now)! Do acronyms like OS/2, PL/I, SAA, a central IRDS dictionary and the likes ring any bell? Corporations have wasted millions of dollars only because IBM told them they could not be wrong.

  I do not know if Java is a better choice than .Net, but it is fair to say that today Java does not appear a riskier choice than .NET. It might just be the other way around: a proprietary environment might find more resistance and less supporters than a product in open source or available under General Public Licensing.

• Some WEB sites, like www.tiobe.com for instance, have developed formulas mostly based on the availability of skilled engineers, courses and third party vendors, to measure the popularity of languages. This is certainly interesting information, but companies should not choose a language based on the number of talents available on the market.

  They should hire developers based on their intrinsic qualities, rather than on their knowledge of a given language. Talented developers will rapidly master a new language anyway.

• The opinion of developers is an interesting indicator. First, they are usually reluctant to use languages before they reach a certain level of recognition, because it does not add value to their resume. By the same token, working with outdated tools makes them look like laggards, one of the worst things in this fast changing industry!

  The ideal scenario for them is to learn and use a language when there is a significant market demand that outpaces the supply; such shortage usually happens when a language has gained enough customer traction to become mainstream (it does not mean it will become mainstream though!). In the Silicon Valley, it is now the case with PHP, or RonR to a lesser extent, for instance. Does it mean that corporations today should go for these environments all the time? Of course not.

  I would suggest this: for non-mission critical applications, it is wise to let developers pick their favorite language. However, for the applications that are critical to the business, nothing comes close to mainstream solutions (J2EE or .NET).

• Some managers heavily rely on reports published by industry analysts. During the 15 years I spent marketing development environments, I remember gaining or losing business, just based on our product’s position on the Gartner’s magic quadrant. While I understand the need for synthetic tools, I strongly disagree with making choices purely based on these reports.

  Analysts and bloggers can create a buzz around a product, but not a lasting market demand. Because of their transient nature, buzzes do not last.

  Last January, I remember attending a presentation given by an industry analyst on the major trends for 2007. The wide adoption of VIsta by corporations was topping his list!! It takes more to understand the market trends than circulating a survey once a quarter to a panel of CIOs.

• Languages usually have a longer life span than frameworks, accelerators, generators, interpreters, etc. Cobol, C, C++ have survived Telon, Forte, Powerbuilder, Delphi and the likes. For the same reason, J2EE is likely to survive Zope, Ruby on Rails, etc.

• I recently found this excellent comment from David McCoy on a forum where the pros and cons of RonR were debated: “IMO, Ruby is just another in a long line of scripting languages that was going to display C, C++, and Java. It was going to be bash/csh, then tcl/tk, then Perl, then PHP, then Python, then Groovy, and now Ruby. What displaced C? C++. What displaced C++? Java. The real question is: what will displace Java? Most likely another statically typed language. I could not agree more with his comment.

Today, there are 2 major environments available: .NET and J2EE. Let us hope that corporations will still have a valid choice in the future between 2 or 3 alternatives.

When given the option, we tend to use J2EE-based frameworks for the non-client part of the application. For the user interface, we would usually go with either Javascript / Ajax or Flex, depending on the customer requirements.

Technical | 4 Comments »

I had a dinner recently with a friend of mine, a senior Vice-President of a mid-size, publicly traded software company, based on the East Coast.

In talking to him, I could recognize a pattern I have seen over and over with mid-size software companies. For obvious reasons I cannot disclose the real company name.

I listed below the main traits of the pattern:

• A first generation of products that has been successful enough to put the company on the map, often making it a leader in its domain

• The initial designers have retained a very strong power and influence within the company. They usually hold the positions of CTOs, possibly still VP Engineering, Chairman or President. This in turn means that the position of CEO has historically always been a difficult one, since the various CEOs have struggled for a power that the founders would only scarcely release

• The company is cash rich, thanks to its stable revenue flow from maintenance and customer services

• And finally the company is encountering the utmost difficulties to bring to the market a much-needed newer generation of its products.

A scenario that sounds familiar to many, I am sure.

Although not exactly the situation described in “crossing the chasm” by Geoffrey A. Moore, they are in the middle of a chasm that is a major gap in revenue, a situation unfortunately not uncommon for companies ruled by technical people.

The likely outcomes for the company are either to be purchased by another software vendor, or to slowly disappear, remaining alive as long as its maintenance and service revenue permits, which might mean years by the way, especially in the enterprise space area.

Of course, some companies have crossed the chasm and successfully released several generations of products, but they are the ones whose management recognized the roadblock early enough to take the proper series of actions.

Companies having problems crossing the chasm are inevitably contemplating outsourcing as a possible way to disentangle their engineering.

At this stage, there are a few major traps that have to be avoided at any cost:

1. First, CEOs/CFOs might face significant resistance from the technical management who won’t view favorably outsourcing the development of their new generation. The reasons given are usually that either none of the potential candidates would provide with an offer that would satisfy their requirement, or that their current version is too complex, too old, too undocumented, too anything to be outsourced.

   The reality is that most founders believe that outsourcing means acknowledging their inability to do it again. I also believe there is something more personal, like a parent seeing his child definitely go away from home. Companies in this situation have to be ready to make brutal decisions regarding the founding figures’ ability to interfere with the new development plans.

2. The second error is to decide to outsource, but without rethinking the innovation process. There are valid reasons why the company has been unable to release a new generation of its products. These reasons must be understood first; how could otherwise the outsourcing provider succeed where the company has failed? Outsourcing a problem does not solve it, but rather amplifies it.

3. The third pitfall consists of selecting the wrong outsourcing partner. I won’t review the usual criteria that should be taken into account, they are well known. I just would like to add one to the list, which is to play a critical role when crossing the chasm; since the company is in a critical situation, it needs to select a provider for which the project is also critically important. Picking the wrong provider will in most cases seal the company fate.

Let me elaborate by coming back to my friend’s situation. Since they are in an excellent cash situation, they could afford one of the Top 3 Indian BPO firms, a company with a well-deserved excellent reputation. And that is possibly the biggest mistake: they signed a deal that was unbalanced by design.

With annual revenue way over $ 1 B, tier-1 offshore companies are aiming at 9-figure (when not 10-figure) deals with Fortune 100, and at becoming global as rapidly as possible. Their real challenge is in delivering on multi-year BPO agreements with Fortune 100, not in developing another software product. Such a contract can only be a commodity for them.

Granted, the Indian giant has certainly assigned decent developers and an experienced project management team to the project. Of course some of senior managers will assess regularly the progress made and raise alerts if and when needed, of course the whole process is likely to be CMM-5 compliant, but at the end of the day it is not going to make any difference: an unbalanced contract is set for failure, and odds are it is going to fail.

A much better solution in their case would have been:

• Either a company with a proven experience in handling similar projects in Europe or Japan, but just entering the US market, and therefore in need of a solid reference

• Or a company already established in the USA, which has already tackled similar projects from a smaller size, and is ready for the next step

• Or a company specialized in their market segment with the required breadth to tackle the project successfully.

They would have been strategic to their outsourcing provider, since they would have helped them take it to the next step. Their CEO would have asked to be informed periodically and directly, they would have assigned their best of breed resources, etc.

It might be unfair, but some companies are growing smoothly, while some other are engulfed into crossing the chasm. Any company falling into the second category should rapidly make drastic decisions regarding their engineering management, clarify its goals, and pick the right partner for outsourcing.

Business, Technical | No Comments »

I discussed this morning with the CTO of a Silicon Valley based WEB 2.0 company, whose entire development team is outsourced to Venus Software in China.

I asked him about which project management solution he was using. I was more than surprised and intrigued when he told me he was not using any.

In fact, the development team uses an Agile development method called SCRUM
[SCRUM page on Wikipedia] and according to him, it renders the use of a tool like Ms Project obsolete.

He could certainly sense that I was not really convinced and let me connect into the online “development place”, in fact a series of integrated blogs and wikis that are used by the team members to meet, exchange information, post results, hold their project reviews, etc.

It works! The productivity is at its best and the developers over-motivated.

I am really inclined to push for generalizing this environment to more of our clients who work with Agile techniques.

And it makes me smile when I read in some not-so-well documented articles that only low-level IT work can be outsourced to China.

The time has come to kick out some old habits, and a good start might be to kiss your project management tool good-bye!

China, Technical | 1 Comment »