Google Maps India learns to navigate like a local

Although this is not still available for India, Bing maps has had this from about a year now.

http%3A%2F%2Fwww.bing.com%2Fcommunity%2Fblogs%2Fmaps%2Farchive%2F2008%2F09%2F24%2Fnew-feature-release-of-live-search-maps.aspx&h=bf3c951bafc03cfbc163700de8e8f595

I was talking about software in general -- not the specific case of google maps and wayfinding. In terms of rapid development and iteration to improve a product to suit the end-user. Monolithic design concepts are rapidly going the way of the dinosaur. Small iterations of "good enough for..." building up to "98% of what the user needs" (with copious feedback to every part of the iteration cycle) is proving itself to be the better way of building software over older, waterfall style approaches.

People often lament that "software engineering does not produce the kind of reliable engineering as does traditional engineer, if bridges were built like applications, nobody could use the bridges because they might fall down". But this misses one the core unique point of software. It's cheaper to tear parts of it out and "renovate" it to make it better than a bridge. The marginal cost of software is almost entirely labor. While a bridge is likely worth far more in materials cost than labor cost (what's the cost of 2 million tons of high-grade steel on the market?). Thus the analogy (and the subsequent lament) don't really work. You are going to keep your F/T staff employed anyways, why not have them rev. the software and make it better?

And as it turns (at least in my experience), greater time spent in software design before implementation rarely leads to a perfect product -- the fact that pretty much every piece of software ever written, no matter how small or utilitarian, reinforces that concept.

But spend a little time designing (which usually results in a little design), with an eye towards future revisions, build a minimal version, solicit user feedback, push feedback into the next iteration of minimal design and repeat ad infinitum seems to result in the following:

- The software begins to better fit the users' needs quicker.

- Fast release cycles build relevance to the users, if they thought your software was 10% relevant on v1, it might be 70% relevant by v3 and 90% by v4. And you can go from v1-v4 in 12 months if you release quarterly.

- Your software will be wrong. Get over it. Instead of lamenting it, take it as an opportunity to turn users into stake holders.

- The users feel that they are participating in the software design (since they are), it makes them implicit stake holders. And it also can foster a sense of partnership. If you do it right, the users are basically contracting you for your services without having to go through the hassle of setting up a formal agreement that they probably wouldn't have set up in the first place. The danger is that when something goes wrong, you try and leverage blame on the user for not knowing how to design software. I've found that simply going back and saying "well, what can we do to fix this by the next iteration?" seems to work miracles.

- Happy users spread happiness through your user community. A happy user community grows. A growing user community means your business is growing. Before we adopted this philosophy, our user community was shrinking at about a 10% rate/year following another development philosophy. We are currently growing at around %200 as soon as we switched development philosophies.

- Changing the development philosophy also implies changes to the rest of the business, for example it gives sales and marketing more reason to touch the users, and gives them better product to show. It also implies a different sales model, rather than charging $x per rev, charge $x+y dollars for new customers, and each rev is $x-z dollars. Or charge $x/years and $x*.40 per year after to build lock-in.

- Waiting 2 years for an overwrought design to produce something that maps poorly onto most users' requirements does not usually result in happy users, the post release exercise turns into damage control and not maintenance. For example, which is the better software, Windows Vista or Windows 7? Vista was a monolithic design that developed in the rarefied vacuum over the better part of a decade and the result was rubbish. 7 was a rather fast (for Microsoft) iteration based on user's requirements and people find it rather unobjectionable. The better product was the one that followed this model.

- Faster releases tend to be smaller releases, which tends to make testing the software easier which tends to produce more solid software.

- Bigger features can wait. Users see delta in software, if you delay your release by 6 months to push out one big feature, your users may loose interest. If you push out a smaller, feature packed release, full of small features and bits of polish, every 90 days, your big feature can come out in 2-3 release cycles and nobody will be wiser to it.

- If you slip a release date, it's better to be 2 weeks late on a 90 day release schedule than 6 months late on a 24 months release schedule.

This may sound like more the Rapid Development Lifecycles that are current coming into vogue, but it's really just common sense coming from lessons learned seeing lots of projects not pan out and burn through lots of investment and contract money to produce substandard product. It's more a manifesto than a development model. Google has largely internalized this kind of model as well, which is why their software seems to sit in beta forever, and they never seem to have big new releases -- going from chrome v2 to v3 was about as dramatic as loading another web page. Big features, like plugins, have been delayed for several release cycles while they push out smaller releases quickly.

The paper is interesting, but I'm more interested in hearing your startup story. Can you describe what lead you to start it, what were the problems, how did you find first customers etc.

Why the downvotes ? The parent comment may be offensive, but it isn't false.

I see where you're coming from, but 'lying' implies maliciousness. Somebody making up directions in cultures where not knowing is shameful isn't malicious, it's wanting to not be embarrassed.

The trick is to make sure the person feels they won't be embarrassed if they don't know the answer.

There is no "Real Indian". What you have is a collection of anecdotal evidence, personal experiences and consequent prejudices.

This Indian feels no shame in saying "I don't know".

This clearly means that a "real Indian" would say "sorry, I don't know," but Google would lie. (Actually it's closer to asking whether it is a lie to be too embarrassed to admit to ignorance.)

If it had meant that a "real Indian" lies about it, it would have had a comma after "know" or "does" at the end.

Uh, there are ads on Google Maps pages.

You do say "Turn left down XYZ Road" but if you don't know or can't see which road you are on(happens quite often in the small bylanes in Central London), there is always the very reliable, do you see "name of pub" in front of you - walk towards it.

I was indicating the latter.