Top 9 “Apple” things I’d like to see in 2008

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.

Top 9 “Amazon Web Service” things I’d like to see in 2008

I have been rather gung-ho about AWS and the great people behind it.  So why would I complain?

I am not – it’s just that I’d like a good thing be even better. So here goes. 

1. A combination of Amazon Flexible Payment System and SimpleDB that is a user account subsystem with payments, pluggable into any web app.  This would be called something like Amazon Web Accounts Management .  It would have skeleton web pages for a user to signup, would automatically validate via email and would then set up a user account.  The user would pick a subscription model or one time payment or …  Just one more scalable infrastructure service I wouldn’t have to build.  Final part of this would be a layer so that users signed up by my app would use my AWS account for access without needing their own AWS account, but I would get periodic billing reports broken down by user and app.
2. A suite of slick Ajaxy web apps running locally on my desktop/laptop to manage all my AWS services.  The key is to make them local, so I can use my AWS keys without having to upload them to every web service.
3.  Alternately, an extension to OAuth that uses my AWS keys off my local machine and can login to 3rd party services that keep asking for my keys.
4. Sorting and grouping on SimpleDB result sets. Sadly currently missing.
5. Amazon should work with 37signals (Bezos funded them didn’t he?) to create a full fledged set of Rails plug-ins that provide no-compromises support for AWS.
6. A uniform RESTful approach across all the apps, have some internal standards for consistency across S3, EC2, SimpleDB, SQS API’s at least.  All the confusion around why SimpleDB API is not RESTful and all the noise around that detracts from the bigger issues of what SimpleDB is and how to use it.  Commit to the RESTafarian religion, do your API-tithing, say your GET/PUT/POST/DELETE mantra daily and move on.
7. A secure data API, so that service providers who use AWS can let enterprise customers know their data is secure.
8. “Telegraphing” of intentions when you are about to meter something previously not metered – e.g. per-request charges on S3.  This prevents  people’s business models from getting whipsawed – typically for a major change like this a 6 month warning would be really great.
9. Finally,  bulk pricing of S3 storage and transfer for people willing to buy in Terabytes.  There are data warehousing and business intelligence use cases for social data which work very well on Ec2 extra large images, along with S3, except that storage and transfer charges,  for say 10Tb,  get prohibitive.  Desktops now have TB’s – the age of the GB disk is passing – please have steeply discounted charges for the TB user.

9 data integration “things” I’d like to see in 2008

Maybe some of these exist already – I don’t know but I’m sure I’ll hear about it if they do.

 

Twitter

1)  The ability to pull a shorturl out of a twitter and directly place into del.icio.us or another bookmarking service in one click – a browser plugin that does this would be great.

2) An RSS feed of the favorites of people I am following.

3) Random suggestion of “related” people to follow based on my current “following” list.

 

Open Data

1)  A clear definition of what it means for a web app to have “open data” ( I have some ideas about this ).

2) Implementations of “open data” – I don’t expect these from the big names, rather new disruptive players will create applications based on  “open data” from the ground up and the big guys will have a hard time following these.

3) Simple and easy ways to integrate data on S3-like and SimpleDB-like repositories into blog posts – i.e. being able to “#include” arbitrary URL’s and have them rendered in place – this will make  it possible to maintain data independent of the app and maintain one definitive copy of the data rendered in multiple apps and different visual wrappers.

 

Mobile Data

1) A simple way to upload and back up my mobile phone content in a portable way.

2) Ability to restore backed up data to different phone when I move carriers and/or phones.

3) Ability to sync phone, web and desktop versions of data seamlessly.

 

 

The Pune IT Industry – Part 1

An outside-insiders informal view of the IT Industry in Pune, India by an Indian now living in the US.

Yesterday, I arrived in Pune, India where my parents currently live. Pune is ~3 hrs drive from Mumbai (the city formerly known as Bombay). Mumbai priced itself out of the burgeoning IT industry in the 80’s and 90’s due to impossibly high real estate prices, traffic congestion and general infrastructure overload.

A classmate of mine worked for the New York office of McKinsey & Co., the consulting firm. They did a pro-bono assessment, for the state government in the late 80’s, of what Bombay would have to do to emulate the success of Bangalore. Finding ways to make affordable housing widely available was on top of the list. The state government did nothing much and Bangalore became the center of Indian IT and now a well established player in international IT. The state government is being warned that it may make the same mistake again with Pune. Time will tell.

I will be posting about my highly personal and subjective assessment of Pune IT based on a limited number of observations and interactions with friends and new acquaintances. Take it for what it is. Just know that if you have heard of Bangalore, you may well be hearing a lot more of Pune in the next 5-10 years.

In the meanwhile here’s some background.

http://www.hindu.com/thehindu/mag/2005/06/12/stories/2005061200070100.htm

Stay tuned.

More on Peter Principle of Innovation

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.

Virus in a Petri Dish

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?

Did Murdoch just KO Google?

Robert Young, whose posts are always interesting and informative, writes on NewTeeVee about two of the many actors on the ‘Net Stage, with whom we have a love-admire-fear relationship.

Did Murdoch just KO Google?

When one is asked about Google’s incredible success to date, and what they did so right, the obvious answer will likely involve an explanation of the brilliant technologies that make up PageRank and Adwords.  More …

The Peter Principle of Innovation

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?

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.

There.

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.