Why Great Engineers Should Sometimes Write Crappy Code

A few weeks ago, I was involved in a project at Airbnb. We needed to design a brand new feature that needed to handle up to 5,000 requests per second. This project, being new, has quite a few requirement uncertainties. However, one of the known requirements was being able to handle more load than most other features at Airbnb.

There was an internal discussion around how to implement this feature. There were two approaches: Approach 1 involves setting up new internal services, new load balancers, and bunch of new infrastructure code to be written. This could take 1-2 months for an engineer to implement, but it will lay a foundation for future projects having similar load requirements. There was also Approach 2, which involves a bunch of small hacks, quite a few limitations, writing code that was not very reusable or extensible beyond the current scenario, but it will only take 1 week to implement for an engineer.

What is the right approach?

Engineers normally go through two phrase of training. The first phrase was the formal education. At school, they are taught to write quick and clever algorithms to solve a discrete yet hard problems. This is why computer science grads typically interview better than seasoned engineers. However, writing good interview code does not equate to being a good engineer. This is why engineers typically go through a second phrase of training, where they learn on the job to write readable code, design scalable architecture, and follow the best practices. A good engineers learn two skills on the job: being a good communicator and being able to handle complex systems.

A seasoned engineers can typically think more holistically about a solution. They will ask the following questions: what if the load is increased by 10x? Can the system be understood by new hires? Can the design maximize extensibility and reusability?

While these are all good questions to ask, it is easy lose sight of the root of all these questions, which boils down to one single fact: the future is unknowable.

In fact, all the questions we ask to design a system is to address this problem. If we know the future, then there is no need to make a system reusable, handle 10x load increase, or even understandable. We can simply write the solution to all the problems there will ever be. Why does a system need to be extensible if there are no new scenarios to extend to?.

I follow this up with two corollaries:

  1. Products must be able to adapt to changes, when the requirements change
  2. Most requirement changes cannot be known until a product is built

The first point is easy to understandable. As engineers, we loathe requirement changes, as it adds more effort and lengthens the development time. As a result, engineers tend to build product in anticipation of product changes. The fact that products are extensible is often to future proof changes. The second point, however, is not often understood. Engineers often think of requirements as the specifications written down by the product manager. However, product managers can never know precisely what the users actually want. What they do is to approximate the user requirement in the forms hypotheses, in hopes that the product built by engineers actually capture user’s value proposition. Because these requirements are hypotheses, the more complex they are, the more likely it is going to have wrong assumptions, and the less likely it is going to be useful. Products that are built to big and complex requirements often fail because of that. This is why we want to build the simplest products possible, so we can prove that the requirements are actually correct before we go further. Otherwise, anything we build will lengthen the time it takes to correct the requirements and is wasteful.

The reason extensible products often follow the first corollary but runs against the second one is that efforts to make things future proof is usually unnecessary. If a product in its lifetime never becomes extensible or scalable, then this high quality code will need to be thrown away. Imagine that someone took one year to write a beautiful web site with all the right practices and industry standards only to discover the right product is an iPhone app. How much waste would this produce?

So, what happened to the project I was involved at Airbnb? We built a simple version, and we quickly found out that this version was not what the user wanted and we quickly abandoned it. The engineering effort was only about 1 week. Some engineers started a separate track to build a scalable solution for both this project as well as other use cases. However, all these use cases disappeared over time. After about two months, the development effort on that project also halted.

Should We Redefine the Democratic Process?

In the aftermath of the election, the problem in the current political climate has become increasingly evident: the dividedness of the government. This past congress has been named the least productive congress on the record. The lawmakers can’t agree on anything from gay-rights to budgets. One is still awed by the madness of the fiscal cliff fiasco. How can each congressman, who seem perfectly intelligent individually, in a group fail to make the simplest decision in the world?

I can go out of my way and say, and I bet many will agree, that the government policies in the United States is even less inept to deal with the economy than the government of China. When it becomes obvious that education and scientific research are the corner stone of a sustainable economy, China’s increase on these investments is responsive and swift. In contrast, the US education system has been talked about for decades, and yet no one is doing anything about it. It seems China is really catching up, not just in absolute terms like total GDP. Even in per capita GDP, China is growing much faster than the US.

One might even say that US is going to benefit more from a dictator than a congress. Sometimes, that seem really true. But monarchy is far from productive. That’s why the western world abandoned that system in favor of the current one. Even China is moving towards democracy, however slowly. So what’s a perfect political system, a hybrid?

For democratic systems, the heart of the problem is the difference of opinions. What impact will it have to raise the taxes on the rich? Will it destroy jobs or stimulate the economy? Will abortion destroy humanity or will it lead to better lives? Are illegal immigrants stealing resources or are they helping the economy? No one really knows the answer to any of these questions, and that’s why we have endless debates. The effects of these policies are so uncertain that we had to resort to a poll of opinions, which are essentially religious beliefs that has little grounding in truth, and often enacting policies with unintended consequences. If we know exactly what happens with these policies, there will be no debate. The decisions are self-evident. However, since political opinions are so elusive, lobbyists spend money solely to change public beliefs, often using fear tactics.

This sounds fundamentally broken. We should do something about, and I think one way is to redefine the democratic process.

The modern democratic process started in the 18th and 19th century, when the monarchies see the trembling of their powers. The democratic process was created to stabilize the society, and it was iterative. France had multiple revolutions to reach its modern democratic state. In the process, different laws were passed and different thrones were overturned. After France, many countries followed, but some didn’t. However, most of the countries that attempted to maintain their monarchy failed. It was an experiment in the grandest scale: you flip a coin to decide which countries go to democracy. One hundred years later, you compare the control group and the experimentation group.

Fast forward to today. We are also experimenting with the policies that we enact, but different than that time, most of our policies are micro policies. That means the effects of these policies are so little that it can be overshadowed by other factors. For example, one can argue that cutting taxes stimulates the economy and creates jobs. However, in the past, cutting taxes have been correlated to both economic growth and slowdown. Can cutting taxes help economy? Maybe. One party will say the growth was caused by tax cuts, while slowdowns are caused by other economic and political factors. The other party will say the opposite. It won’t be until decades after the policies are enacted when we could compare the results across different countries. By this time, any debates on the policies have long been irrelevant.

What we really should do, is to accelerate political experimentation by taking objective measures. Rather than waiting years for the policies to take effect, one should randomly assign a small population to be subjective to the policies and then measure the results, and this is known as A/B testing. Because this is a controlled experiment, the results can have high statistical significance and come back in a matter of months if not weeks. Will tax cuts help creating jobs? Let’s randomly choose counties across the nation and cut their taxes. And then we measure the numbers in these counties relative to the rest o the country. Will the economy improve? Will they have better unemployment? One year of data is enough to give a clear answer.

We can do other similar experiments. How will education reform impact the teachers and the students? Randomly pick a set of school districts and change their policies, and compare the results on year later. Are gay marriages beneficial to the society? Randomly pick a set of counties and allow gay marriages.

As I describe these ways of doing things, there are undoubtedly two issues one need to address:

  1. What if people move from one region to another just to take advantage or avoid the effects of the policy?
  2. Many experiments, such as cutting taxes, cannot be run without congressional approval, which defeats the purpose of these experiments.

These are the real roadblocks to political experimentation. Here is why we need to redefine our democratic process to address these issues. For example:

  1. Make sure that the experiments have a very short duration to remove the incentives of frequent movers. For example, if tax cuts are in effect for only 1 year, people won’t move just for that one year.
  2. For those wide ranging social policies (such as gay marriage), the policy needs to exclude people who are not originally from a different group.
  3. The constitution needs to be changed, not only to permit experimentation of policies, but also to require them, before any sweeping policies to take effect.

Here are my thoughts. Everything above reads like science friction (changing the constitution?), but as social and economy changes have become increasingly accelerated, we cannot afford endless debates without hard evidence supporting either side. The idea of democracy is really really old. Isn’t it time to have a better and more productive government?

A Change of Job

In my previous post, I wrote about the process leading up to the change of my job, but I haven’t share much on the actual change. In this post I will write a bit more of what I learned. Beware that this is not a post about the actual interview questions or process. A lot of people have written about Microsoft interviews, so this won’t be one of those. Instead, I will write about the thoughts and impressions during the job hunt, a philosophical view, if you will.

Before I set out looking for a new job, I have decided place the biggest emphasis on one criterion. Having done relatively well in my role (and very grateful for my team for helping me), I realized that a good career at Microsoft means having a good manager. As you may know, Microsoft uses stack ranking to determine performance reviews. When you are stacked against other employees in your division, having a manager who is willing to fight for you can make a big difference. As a result, any single red flag for a bad manager will lead me to call off  the interview or decline an offer. In other words, I am very very picky.

The reason I get to be picky is that I have a received relative good reviews. Because of that, I get to “play the market”. What further fuels that belief is the stream of recruiter solicitations I got on my LinkedIn account. One thing I found was that having the name of UW on my profile significantly increased the amount of recruiter solicitations. No matter what people say, going to a top university does increase your odds of getting noticed. Interestingly, though, my UBC degree didn’t do much in that regard. I believe this is due to Americans being less knowledgeable of international universities.

This leads to a side discussion, which is that the best time to change jobs is when you are at the peak at your current job. If you are already doing extremely well at your current job, chances are it will be going downward from that point on.  Incidentally, some articles argue that people master their job in about three years. After three years, you are either at your peak or at an inflection point. In either case, there is an opportunity cost not to change your job. This likens to investing. The best time to sell is when your portfolio holds the most value (or just before the growth slows). Some people are reluctant to sell after a streak of good years, only to realize it is all going downwards after that. Sell when your assets are most valuable. There is some paradox to it.

At Microsoft, employees are encouraged to have an hour of informational interview with the hiring manager before the formal interview loop. This is time for you to get an impression of the hiring manager and vise versa. Due to my reviews, I did not encounter a manager who declined to proceed with a formal loop. On the contrary, I actually declined the offer of some of the managers because of red flags. You will be interested to know which things I deemed as red flags:

  1. You will be only person reporting to him. This usually happens when the manager himself is a new hire to the group. I found this happens usually when there is a brand new project or an old team has dissolved. In both cases, the manager comes in to lead in an uncharted territory, and both represents significant risk. I believe the only safe case is when the new manager was promoted to the role rather hired from a different group, as the first cases implies he has done really well and the second case the opposite.
  2. He is constantly late, interrupted, or otherwise disrespectful. My rationale is that if a manager can’t seem to care about you at meeting time, how can he fight for you in the long term? This cue might be a bit unfair, as a manager’s etiquette styles might not reflect his management style. However, this is the only cue we can use without having worked for him. This is as unfair as your manager determining your performance based on the interview. The feeling is mutual.
  3. What his direct reports or coworkers say can be telling. During one interview loop, I asked the manager’s direct report why he chooses to work in this team. His answer was that he was in a different team and got reorg’ed into the current team. This is hardly an enthusiastic endorsement. Another cue came from the PM, who said that “an senior dev can really help the the team”. Well, I didn’t know that an SDE2 is counted as a senior dev. I treat this as saying people with experience and knowledge don’t want to join the team. If I join, I will be an anomaly.
  4. Other red flags: There was one team that I actually was very interested in but declined because, well, the actual manager is working remotely. In that case, the manager was in Vancouver and the team was in Bellevue. As much as I want to return to Vancouver, I decided it was not the right career move. A remote manager is in the same disadvantage as a remote employee. The communicate costs can eat into the career. Another case was when the manager was being wish-washy and an asshole. At the informational, he asks a poorly thought-out question without a clear answer. It was not really a brainteaser but more of a wordplay. After the interview, he did not indicate whether he wanted to continue. It was not until two weeks later when he sent an email saying his manager wanted to meet me. Well, thanks, but no thanks.

Once your manager has passed your screening, it’s time for you to pass his. The lesson to learn here is that preparation is very important. The interview questions are not like the problems you face at work. I have come to believe that interview was not to meant to test your coding skills but rather your real life problem solving skills, like passing the interview. Once that is clear, it’s easy to understand why you need to do things that you don’t do normally. For example, in life I will never write my algorithm out on a piece of paper, but this turns out to be a big boost for my preparation. It is like preparing GRE for your master’s degree. It has nothing to do with your studies, but you have to do it.

Another thing is that your first interview is almost certainly going to fail. Mine did. What you should do is to learn from your mistakes and go from there. For example, I discovered my weakness in the first interview and was able to ace every other since.

Finally, I want to say that I think it is almost always better to change job within the company rather than going outside. There are few reasons. For me, I can capitalize on my good review and be picky. This is certainly not possible in an outside company. Another reason has to do with imperfect information. You can know more about your hiring manager, his team, and the company culture within the organization. The outside company can withhold more information that can be very crucial to you. It can be too late when you find out your manager is an asshole.

Then again, the reverse is true. Your future hiring manager in an outside company would also know less about you. If you are doing a horrible job at your current role, then your best chance is to hope that your future manager does not find out. This sort of explains why most companies who hire CEO externally actually end up worse.

A Change of Pace

This is a long due update. This blog has been used primarily to communicate information about my app GoVoice. However, this is not one of those entries, and soon you will see why there will be fewer of those.

This entry is about my job. As some of you knew (or guessed), I work for Microsoft. Recently I am switching from the Windows Phone team to the Bing team, and I have learned some valuable lessons. I want to share some of them here. If you are interested in my personal experience, please read on. Otherwise, you will find this entry of little use to you.

For those of use who are still reading, you may wonder: why Bing? This is a because of a series of realizations I had in the last couple of months.

It started when I was working on the notification server for GoVoice, I chose Azure because I wanted to learn more about Cloud. Cloud computing had been gaining attraction by producing a lot of buzz. To me at the time, cloud computing means paying for what you use instead of what you reserve. I did some research but nothing big came up. The biggest technology innovation in Windows Azure in that regard was simple: there is an API you can call to dynamically spin up or down machines based on traffic. Comparing to the traditional web service model, the technology behind it was surprisingly shallow, so why such a buzz?

It was not until I took a course at the University of Washington called Distributed Systems, where I learned some fundamental concepts in distributed computing, when I noticed a trend. Things like synchronization, consistency, and fault-tolerance surfaced as problems that only occurred on a bigger scale. There was also Google’s BigTable and MapReduce that become so famous that took the industry by storm. That’s when I realized this was something that people rave about.

While at work, I also noticed that there was an internal service has been suffering miserably. It had the same problems that a typical distributed system suffers: people spend days and days trying to figure out why something went wrong. They looked for the problems because a single failure can bring down or invalidate the entire system. To me, this sounds alarming.  A good distributed system should expect failures and must function in spite of them. A system using the Paxos algorithm, for example, should expect to function even 1/3 of its nodes have failed. This was not the case for that internal service. Furthermore, it did not have any notion of consistency, making it impossible to figure out its expected state at any given time. Obviously, the team that ran the service failed miserably and dissolved.

However serious, this kind of problems have already been solved by Google’s BigTable and MapReduce. The team that implemented that internal service might not benefit directly from these ideas, but at least they can borrow the concepts. This was the first time I noticed a disconnect between the edge of the industry and the team’s internal focus. Don’t get me wrong, I think the Windows Phone team is doing precisely what it can do to improve the product, but the internal team would not have enough resources to implement an internal version of the MapReduce. It just means that I won’t be able to learn the newest technologies.

The next realization came when I started my coursera courses. That’s when I found the problem of the decade: Big Data. We often hear buzzes about Big Data in the news and reports. However, when people think about the term “Big Data”, they have very vague idea of what challenges it presents. You may think it’s just normal data times a thousand, or maybe a million. This was what I thought, too, but I was wrong.

There are some engineering challenges associated with Big Data. For example, Facebook faces the challenge of locating and serving your data from a farm of hundreds of thousands of machines. If we just scale the traditional data serving technologies to that scale, it will probably take minutes, if not hours or even days to find your data from exabytes of data. However, this kind of challenges are also largely solved (although not yet within Windows Phone client team). The real challenge going forward would be how to make sense of data.

We all heard horror stories about Google being able to profile us using what they know about us, but you may noticed that the ads that Google serves still remain largely irrelevant. There are maybe some good ones on their search engine, but that’s about it. Those are the only times when I clicked on their ads that are not by accident. Given what Google knows about us, I am surprised that their ads are not more relevant.

This is the challenge of Big Data, and in my belief, the only way to improve on that front, is through Machine Learning. This is exactly what I learned on coursera and what I will be learning at UW in my next quarter.

Machine Learning has the potential of unlocking patterns that are normally impossible for traditional software programs or even humans to detect, and this will become increasingly important in the new era of Big Data.

Before I made the switch to Bing, I talked to my manager regarding his next projects. There was a project on the horizon that borders on what people may call Big Data. I made a proposal to him to use a Big Data platform that is already used by Bing. Truthfully, I doubted if that project can be remotely called Big Data, but at least we can benefit from the fault-tolerance and data richness of the platform. However, his response was a solid no. I understand his rationales entirely, and I have to admit that I am bit selfish to push some thing with so many unknowns just so that I can learn the newest technologies.

As for Machine Learning, I know it would be irrelevant to the team. In my manager’s words: “I don’t worry about reporting. It is just UI”.

Well, so that is that.

Seattle Startup Riot – Where Million Dollar Ideas Started

I recently attended Startup Riot Seattle, a pitching and judging event for aspiring startups. 30 companies were given opportunities to present their ideas, each in a 6 minutes slot, in front of a panel of judges. After the judges have picked the five top candidates, three of them, voted by popular choice, were awarded 5 hours of investor meeting, plus $5,000 – $8,000 in services, presumably very helpful to support their startup efforts. The presenter was allowed to use a PowerPoint deck, but with only 4 slides and no animations – one of which can contain only a product name, email address, and team names. Each team was allowed three minutes for questions. The judges grilled the contestants American Idol style, with great entertaining effects.

The judges come from entrepreneur backgrounds, too. Andrew Hyde is actually the founder of Startup Weekend, an event similar to the Startup Riot itself. There was also Jon Crawford, who founded Storenvy, which just raised $1.5M from venture capitalists. In other words, these are the people who have made it, although not in the caliber of Mark Zuckerburg et al.

The event lasted for a whole day, concluded on a club night for the founders to network, and to drink beer. I didn’t attend the beer fest, but I did come back with a lot of things to share. I will pick a few that stayed on my mind. For what it is worth, if a company is forgettable to me after 10 days, it is probably forgettable to others, too.

The winner of the contest was Microryza, a very interesting project, not because of its potential to make loads of many, but because of its ingenuity and nobility. Essentially KickStarter for academia, it’s created by a recent Biochemistry grad from UW. The founder Cindy Wu noticed that 2/3 of scientific research did not get funded because of lack of support from the public sector. Microryza was an effort to raise visibility of those hardworking scientists to the general public, so that anyone interested in contributing to the scientific community can donate a couple of dollars to advance the state of mankind – a very noble and philanthropic idea indeed.

There are a couple of social networking startups, including Priceling (Louis Vuitton + Groupon + facebook), Kouply (Path for couples), and iWishFor (gift registry + Facebook). I have to say I am especially fond of iWishFor, just because of its small size and its laser focus on solving a single problem. I think anyone who has an iPhone and wants to receive gifts on a special occasion should use this app. And, how can I forget, this is a Vancouver company. Unfortunately though, none of these companies received an award. This probably speaks to the general fatigue of more social networks.

There are also lots of Vancouver startups, including PayrollHero (Payroll systems for Southeast Asia), a total of 6 companies out of 30 were from Vancouver. (There maybe more, but not all of them disclose where they are from). This makes me happy and sad at the same time. I am happy for the entrepreneurial spirit that outflows this far into Seattle, but, unfortunately, many of these companies lack the practicality and experience in execution, which is typical in Vancouver companies anyway. This means these startups will very likely remain very small and not very notable. Their ideas alone will carry them nowhere close to the caliber of Twitter or Facebook.

Now to the judging, there are some repeating themes one can summarize from judge’s questions. Here are my impressions on how to “deal with” these judges:

  • Show your product. I can’t stress this enough, nobody will buy into an idea on a napkin. No actual product means no execution, and no execution means no future.
  • Know your customer. Your users are not necessarily your customer. Your customers are those who pay you. If you have a lot of users, but you don’t provide values to the people who pay you, then you don’t have income.
  • Know your problem and solution, and present them well. This is really a presentation skill. If you are solving a problem that doesn’t exist or your solution does not solve your problem, of course you are not going anywhere, but more likely is that you know both but the judges don’t. Nobody will buy into you if you can’t explain what you do.
  • Data speaks louder than confidence. If the judges ask you “why will your product take off”, and your answer is “I am confident it’s so revolutionary that it will change how people work/play/live”, then you’ve lost them. The best response is “our data shows that ##% of users return within xx”. Data help the judges see a clear trajectory, or at least show that you know how to improve.
  • Know your competitor/market. Some say that you should ignore your competitor and just follow your heart. Fair enough, but chances are there are someone doing the exactly same thing as you do. If they are doing a better job than you, why would anyone invest in you? If you know your competitor, then at least you are not blind sighted by a better product. If your product is truly innovative enough that no other product is the same, then your competition is the status quo. Why would someone stop doing what they do and choose you?

I think these  judges have provided really good feedbacks to the presenters. I benefitted greatly from them, too. However, I do have some reservations for the format. The Lean Startup points out that execution, not an idea is the most important factor determining the success of a startup, but the problem is it is hard to present your execution in three minutes. Usually it takes some time for an investor to know the team to know whether the project will succeed. I guess if the investor was at the event, he can always chat with the presenter during the networking time to know more, but the presenter needs a lot of elevator pitch skills to present his million dollar execution.

What can I say? This event did help shape my view of the scene a bit. I do have a few pet projects I am working on. I wish next year I will be a person presenting. Hmm…one can always dream.

GoVoice and Your Privacy

In a blog entry on CNET, Danny Sullivan criticized the lack of Google Voice options on the Windows Phone platform. To summarize, the problem was that he couldn’t find the official Google Voice app on a Windows Phone, and that he didn’t want to use any unofficial apps. He concludes that this predicament isn’t just inconvenient – it’s probably insecure.

Aside from hearing people sayings that GoVoice “works better than the worthless Android version”, which leads me to wonder why Danny is obssessed with an official app, his article also probed me to think whether he missunderstood something I wrote in the app, which as he quoted, is the following:

We take your privacy seriously and we don’t store your password on the device unless if you choose to do so. Even if your device is compromised you can still revoke GoVoice’s access.

Apparently, he is not content with that statement. He seems to be a fairly technical guy, so he asks (paraphrased): if GoVoice does not store my password on the device, where exactly did it store it? How can GoVoice access my personal information if it did not store it?

For those who are technical enough to ask these questions but not enough to answer them, such as Danny, I would direct you to visit this page, which essentially tells you how your passwords are used to authenticate apps to Google services. It basically says that you don’t need to use a password to interact with Google services. All you need is an authorization token. You acquire this authentication token by exchanging your password with Google’s server. What an authorization token is is a temporary pass Google issued to application for limited interactions with Google services. After an app has this token, the app doesn’t need your password to talk to Google any more. Google places a limited trust on the app. How limited? An authorization token has a few characteristics:

  1. It’s time sensitive – it can only be good for a certain period, usually a few weeks. After that, it will be expired.
  2. It’s limited to one service – a token issued for Google Voice cannot be used with GMail
  3. It can be revoked at any time – if you change any security settings on Google or if Google is suspecting anything malicious, Google will revoke that token without requiring you to take any action.

As you can see, this is much more secure than to interact with Google using a password. So where does GoVoice store your password if it is not stored on the device? The answer is that GoVoice does not store your password, it stores only your authentication token after it receives it from Google. The password is erased as soon as you exit the app. However, due to characteristic #1, your authentication can expire, so you have the option to ask GoVoice to store your password securely on the device, so in the case of expiration, GoVoice can acquire a new authentication token from Google. However, your password is never transferred to the server.

Now, I need to add that your authentication token is also stored on our push server. GoVoice sends your authentication token to our server via https, and the server will never disclose that token to anyone. So your extra safe authentication token is transmitted and stored securely. Why do we need to do this? This is only there to update your live tile. When a new message arrives, GoVoice’s server goes into your Google Voice inbox and retrieve an unread message count. (Remember that the server cannot do anything outside of your Google Voice account, such as Gmail. This is the characteristic #2.) This is how you get your big count on your live tile.

Now the final question is: Can you trust me?  I didn’t have the application open sourced, but for those of you who are technically inclined (hint: Danny), you are always welcome to download the app from the marketplace so you can decompile it to study it. Just don’t get too carried away to put that code in your own Google Voice app.

Termination of the Paid Version of GoVoice

Starting today, if you run the paid version of GoVoice and you have notification enabled, GoVoice will ask you to switch to the free version. After you switch, all the features that you enjoy in the paid version will also be available in the free version. However, if you have never used the paid version and you download the free version, the notifications will not be available.

The paid version will be removed from the marketplace on June 1. If you really want to have notification now, you will need to download and run the paid version (it will ask you to switch to the free version, but then you will get push.)

The current schedule to bring Push to free users is not determined. However, I will look into adding more features to GoVoice for Mango.

The Free Version of GoVoice on the Marketplace

You may ask why you will need to pay $2.99 for an app that has a free version. Here are the reasons:

If you have never paid for GoVoice before, the free version you download will not give you push notifications at all. The GoVoice push will only be available to paid users. When you use the free version of GoVoice, our servers will look up whether you have used the paid version before. If you have, then you will get push. If you haven’t, you will not get push.

We will bring push to the free version later in another shape and form, but it is not available right now. That *alternative* push service will probably require additional setup, and you *may or may not* have to pay a small fee.

If you are a current paid user and have used the notification in the paid version before, the free version and the paid version are identical to you (except the paid version has a bug fix, for now).

If you have never used push and don’t care, then free and paid versions are the same to you.

Again, I want to repeat that we will find a way to provide push to free users in the future. Paid users will always have GoVoice push both on the free app and the paid app, but the new free users will receive push in an alternative way.

GoVoice 3.0 – More Certification Inconsistencies

I submitted two identical binaries of GoVoice for certification, and guess what? One version went through and the other failed. Some needs to check the consistency here.

I have just resubmitted my paid version after fixing the “bug”. (hiding all labels crashes the app – a possible scenario at all?) But the free version should be up in the marketplace very very soon. I will update again when the paid version went through.


The free version link is now live:


GoVoice Will Be (Completely) Free Soon

While I am readying an update to GoVoice, I think I should also explain what I plan to do with it in the future.

Here it is. GoVoice will be free.

It will not happen in the upcoming release yet, but it will definitely happen in the one after next.

What does it mean to you? Depending on who you are, it means different things:

  1. If you are currently a trial user, then you will get all the features of the paid version (with a caveat, details later)
  2. If you are currently a paid user, you will still be able to use the paid version through the upcoming release. After that, the paid version will be removed from the marketplace, and you will need to download the free version.

What about Push (the caveat)?

  1. The GoVoice servers will stop accepting new push subscriptions. If you currently have a push subscription through the paid version of GoVoice, you will continue to receive Push notifications from GoVoice server.
  2. Paid users will be asked to switch to the free version, but they will continue to receive Push from the GoVoice server.
  3. If you are a current trial user, you will not be able to use the push service from GoVoice server.
  4. We will provide a way for new users to receive Push, but it will not be through the GoVoice server.

The conclusion is: everyone will still get the exact the same functionality as before. If you need Push and you already paid for it, you will still get it. If you need Push and you didn’t get it through the paid version, we will have a way for you to get it.

I guess the question now is: why?

To this I can only say it is entirely a personal choice. It is not a complaint against Microsoft. Microsoft has done everything I needed to make what I needed happen, but it is solely a personal reason for me to make that change.

The second question is: are you abandoning the project?

The truth is no, although I probably won’t devote as much time to it as before. I still want a couple of things to happen to GoVoice because I also need them. As you will see in my next post, I will add quite a few new features to this release. If time and technology permit, I want to add the GMail calling to GoVoice some day.

Please stay tuned for my next update.

[Update]: Currently, the version difference is here.