Archive for the ‘Innovation’ Category

I love Apple products – and I’ve converted many PC users to Macs. But I often find some glaring things that I wish were’nt so about Apple hardware, software and service. So  here are some suggestions for things that Apple could do to make their products better and also some things that would make them more developer friendly – lot more developer friendly.


  1. Make the laptop surfaces not slippery – this is a major design flaw – provide easy grip matt surface patches where the user is likely to hold the laptop about 2 – 3 inches in from the edge – less repairs due to dropping – better for Apple.
  2. Provide a short 2″ adapter cable so that older laptops can be retrofitted to use the new magsafe power supplies – better for Apple – no need to keep making the older one’s. Users get the no-yank benefit of magsafe. 
  3. Allow easily replaceable and upgradeable hard drives in laptops please.  I don’t mind paying for a hard drive upgrade at an Apple store – they just won’t do it.
  4. Move all major ISV’s to native Intel this year – that way we don’t lose performance going through the Universal emulation layer.
  5. Have an advanced mode on OSX which is developer friendly and allows  backup and restore including all developer tools and settings etc  This could also allow an optional unified view of all /Applications directories on all mounted bootable drives;  same for /Users and ~/Desktop, /usr and /usr/local. This makes carrying your  environment on a bootable external drive seamless – you can now plug into any machine and not necessarily have to boot from one drive or the other.
  6. Java is not dead – please talk to your loyal developers about your Java plans – keep the lines of communication open and don’t yank important software after you have released it in your developer editions.  At least tell us why.  Developers are your biggest evangelists, don’t bite the hand that feeds you.
  7. Allow self-service at your stores where a pro-care customer gets access to diagnostic tools, bootable external drive, restore discs etc. so we don’t have to wait in line just to have something done we could do ourselves if we had the tools available.
  8. When you say you’ll give pro care users quicker service please mean it. I am tired of whiny iPod users being given preference even when I have procare, just because mine is “probably not a 5 min problem”.
  9. Take as much pride in your service as you do your product design.  Influencers are beginning to notice that Apple service needs attention.

Read Full Post »

The earlier article got a bit of interest, a lot more than I expected, but also some discussion of whether it made sense at all. An example oft quoted is of Google. So using recent events I’d like add this post to underline what exactly the Peter Principle of Innovation says.

This week Google bought DoubleClick for $3.1 billion, underscoring the fact that it is an advertising company. In the meanwhile Twitter an SMS based webapp exploded and continues to grow. And finally Dodgeball a company in the same space as Twitter was bought by Google and left to languish – clearly it did not fit in with the advertising-uber-alles credo.
The cash-cow – advertising. Other innovative applications don’t make it. A twist of irony is that Evan Williams, left Google and created Twitter underlining the part in the original article that innovators leave to form other companies. Clearly it could not have happened inside Google as it has no immediate relationship to the cash-cow.

‘Nuff said.

Read Full Post »

Dave Hornik spoke at the last FooCamp about viral marketing and lessons you could learn from an actual virus. I was there but I didn’t go. Thankfully, Christine Herron summarised his talk in the form of bullet points on her blog.

Since then, off and on, I have been thinking more about the opposite.
What blocks a potentially viral product from actually achieving critical mass. I haven’t seen much discussion of that.

So here goes.

Continuing the biological analogy, if you considered that the most unhealthy place was the one with the highest germ density then the Center for Disease Control in Atlanta would be right up there. But it’s not the most unhealthy place, because every infectious agent is enclosed in an impenetrable barrier. In a lab, that’s often a petri dish.

What then, is the software equivalent of a petri dish?

Something that is transparent, almost invisible, but an impenetrable barrier to proliferation. I call it transparent because the people who create the barrier don’t see it, impenetrable because the virus – the app does not overcome it and spread rapidly. So what is a real example of petri dish in this context?

Some examples from the antedeluvian past.

In the 80’s and early 90’s the most common petri dish was a “for-fee” SDK. The Business Unit Manager pulling out his trusty spreadsheet decided that the SDK for his world changing product would be available for 699$ after faxing a 10 page qualification questionnaire. After all it was going to be world changing and they wanted to be suer they had the right partners not just the “amateur developer”. This, while companies like Borland were charging 49$ and 99$ for world class developer tools.

And then in the early-to-mid 90’s along came Open Source and Linux …..

When Linux began to proliferate in the early 90’s I was doing development on Microsoft platforms as well as Unix platforms. Once I went to Linux I didn’t go back and never paid Microsoft another $ for a development tool. Needless to say, Linux grew virally. Last I looked, Microsoft still charges 2000$+ or so a year for developer tools.

But money is not the only barrier to proliferation. Ease of deployment – or rather, lack of it is another “petri dish”.

In the early 90’s Sun did one thing massively right which was to give the Java run time environment and SDK away for free so developers could play with it. But they also to made it available on Windows with native installers – as much they hated Microsoft and Windows at that time, they saw the strategic importance of not having any obstacles. The Java VM infected Windows and IE and Microsoft’s best efforts did not stop this juggernaut. Although this virus rapidly grew API’s and mutated into a pig called J2EE ( been there, got emotional scars from that) by that time it had pretty much established a solid beachhead in the enterprise, effectively stopping Microsoft from taking over.

The petri dish in the form of a bad installer was something IBM did not see with OS/2 . It had this problem in the early days, even though it was becoming a stable and useful development environment and it never broke out of a very narrow niche of developer build machine and Lotus Notes Server class of machine. Some OS’s attempting to crack the ’86 market even required you to have SCSI drives during a time when the commonly used PC’s had IDE drives and SCSI drives cost upwards of 500$. Someone somewhere wasn’t thinking it through was looking straight through the petri dish without noticing the barriers.

Takeaway: If you want your app to have rapid proliferation, make sure you don’t put it in a petri dish.

I am sure you have your own examples of petri dishes. What are they? I haven’t thought through what the petri dishes are for Web 2.0 apps. Any ideas?

Read Full Post »

The original Peter Principle was a classic of the 70’s, essentially stating that “in a hierarchy every employee tends to rise to their level of incompetence”.
At that point they have reached as far as they can go in that organization and can no longer be promoted. As a corollary, the Peter Principle states, all useful work in an organization is done by those who have not yet reached their level of incompetence.

But that’s just by way of preamble. A larger and wider application of this principle emerges from looking at how companies grow in the marketplace and how they innovate and how they “lose their soul” and stop innovating.

I’ve been contemplating this for a while and I’d like to propose it as the following :-

Every company innovates until it finds a cash cow. At that point only innovation that supports the cash cow is promoted. Further, any innovation that threatens or does not support the cash cow languishes or is actively killed. Eventually, most of the true innovation ceases as the innovators leave and start new companies and the cycle repeats.

A young company is like a thirsty animal in the desert, desperately sniffing and searching with all its might for a supply of sustenance that will allow it to survive the rigors of the market. If the animals energy runs out before it finds an oasis, or better still a river or a lake, then it dies. If it finds a source of water it survives. It’s all very basic and primal “circle of life” stuff.

If it finds an oasis in the desert can you blame it for not wanting to take another long open ended trek in the desert. The search for the initial revenue stream for a startup is strongly analogous. Once you find it, you don’t want to let it go. And therein lies the rub.

That very act of hanging on will eventually lead to stasis and then death.

A company finds a cash cow (IBM – mainframes, Microsoft – DOS/Windows/Office, Google – AdSense, Oracle – database license revenues, … ) and it redirects all its energies primarily in ensuring that the cash cow never stops giving milk. And in doing so it domesticates itself and loses it’s ability for wild and woolly innovation.

Yes, there may be wild and woolly innovation inside the company but it will very rarely make it outside as a product.

There are of course some interesting anomalies here. What about Apple and iTunes?
Will Apple do anything new if it upsets revenue from the iTunes Store? Remains to be seen.

What about Google and 20% time? Yahoo and Brickhouse? Will innovation be jump started again? Will it not still be in support of advertising – the main Yahoo and Google cash cows?

Try as I might to find holes in the new application of the older principle, it seems rather robust.

What do you think?

Read Full Post »

Hello world!

Hello blogospherical world! As friends know I have been blogging about tags and databases for a while at Tagschema . But since that blog is narrowly focused and I want to keep it that way, and I have other non-tagschemical thoughts bubbling up for a while now, I started this blog.

Since I don’t want to restrict myself to any specific technical or non-technical subject this time, and since some of these topics actually came out of discussions I had on walks, the name of the blog followed somewhat from that.


Since we have the necessary preamble out of the way, here’s a preview of things to come. One major theme will be a somewhat subjective view on the inside workings of software companies and teams that do software development. Not the financials and the market dynamics but the internal dynamics of teams and management during the development of a product and related stuff.

I tried hard to get Om Malik to start an area on his site about these things but for some reason he didn’t bite. So I guess he’ll just have to get me to guest write ;-).

Another theme will be software development in India and ongoing comparison and contrast with processes there and in the US.

Yet another theme will be the environment and the technical community.

And then ongoing commentary on Web 2.0 and other trendy widgety, ajaxy, javascripty ruby-duby-doo’s.

You have been warned.

Topics of a couple of upcoming posts.

1) The Peter Principle applied to software innovation :-

Every company innovates until it finds a cash cow, whereupon all innovation is directed towards the support of the cash cow. And all other innovation is quashed or languishes. and what can be done about it.

2) Wizards don’t scale.

How you can’t build large companies by hiring a lot of software wizards and putting them together in one room. And why. And how ants do scale. And how this relates to software development in the US and India.

Discuss amongst yourselves.

Read Full Post »