SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

Archive for the ‘software development’ Category

Authentication as a Service: Slow Progress, But Are We There Yet?

Posted by Bob Warfield on July 11, 2014

BankVaultSmallAuthentication as a Service solves a problem every Cloud Developer, mobile or desktop, has to solve.  As one player in the space, AuthRocket, puts it:

Do you really want to write code for users, forgotten passwords, permissions, and admin panels again?

To that I would add, “Do you really want to have to be a world class expert on that stuff to make sure you don’t leave some gaping security hole out of ignorance?”  I think the answer is a resounding, “NO!” to both questions.  Why do it in this world of Agile Development, Lean Startups, and Minimum Viable Products?  It’s one of those things everyone does (and should do) pretty much the same way from a user’s perspective, so there is no opportunity for differentiation.  You have to do it right because the downside of security problems is huge.  You have to do it right up front to protect your customer’s data and your investment (so nobody gets to use your products for free).  There’s basically very little upside to rolling your own (it’ll only slow you down) and tremendous downside.  Hence, you’d like to buy a service.

I keep going around this block for my own company’s (CNCCookbook) products, and I surely would like to get off that merry g0-round.  I wanted to buy this some time ago, and have written about it for quite a while.  For example, in an article I wrote 4 years ago on PaaS Strategy (Platform as a Service), I suggested login would be an ideal service for a pass to offer with these world:

Stuff like your login and authentication subsystem.  You’re not really going to try to build a better login and authentication system, are you?

I sound just like AuthRocket there, don’t I?  I’m sure that’s not the earliest mention I’ve made, because I’ve been looking for this stuff for a long time now.  As I say, I had to roll my own because I couldn’t find a good solution.  I would still like to replace the solution that CNCCookbook uses with a nice Third-Party service.  I only have few very generic requirements:

-  It has to offer what I need.  Basically that’s Email + Password login with all the account and forgotten password management interactions handled for me.  It would be very nice if they do Federated Login using the other popular web services like Amazon, Facebook, Twitter, Google, or whatever.  It would also be very nice if it could do 2 factor login.  The latter two are optional.

-  It has to work well.  I judge this by who has adopted it and how it is reviewed.

-  It has to be here for the long haul.  I’ll judge this by size of customer base and quality of backers.  AuthRocket, for example, is still at the invitation-only Beta stage.  That’s too early for me.  I have mature products and don’t want to have to change out this service too often.

-  It has to be easy for me to access the API’s.  I prefer a nice RESTful API, but I will take a platform-specific API for my chosen development platform: Adobe Flex.  And no, I don’t want to debate that platform, it has worked fabulously well for me, the products are mature, and I am not looking to switch.

-  It has to be easy to tie it back to securing my data in the Amazon Web Services Cloud.

-  Optional Bonus:  It helps me solve the problem of disconnected data access.  My apps are Adobe AIR apps.  You download and can run without a web connection for a period of time.  This is important to my audience, but means I’ve got to use data models that keep local copies and sync with the Cloud when they get connected.

While my apps are not yet available on iOS or Android, all of those things are almost exactly the same problems any Mobile App developer faces.  Therefore, this ought to be a hotbed of activity, and I guess it is, but so far, I still can never seem to find the right solution for me, and I don’t think I’m asking for anything all that crazy.  But, I have yet to find a solution.  Let me tell you a little bit about my 2 most recent near misses.

Amazon Cognito

I was very excited to read about Amazon’s new Cognito service.  At CNCCookbook we’re big Amazon believers, and use all sorts of their services.  Unfortunately, at least until Cognito, they didn’t really have a good service for solving CNCCookbook’s authentication problems.  They had IAM, which is a very complicated, very heavy-weight, very Big Corporate IT kind of solution.  It looked kind of like maybe you could do it if you had to, but you’d still wind up writing all the darned password management stuff and it looked like it was going to be a real ordeal.  Mostly, I think of IAM, as the tool used to define roles for how broad classes of users can access the various other Amazon offerings.  I wanted another service of some kind to be the sort of simpler, friendlier, front end to IAM.  Enter Cognito, and it sure sounded good:

Amazon Cognito lets you securely store, manage, and sync user identities and app data in the AWS Cloud, and manage and sync this data across multiple devices and OS platforms. You can do this with just a few lines of code, and your app can work the same, regardless of whether a user’s devices are online or offline.

You can use Amazon Cognito directly from your mobile app without building or maintaining any backend infrastructure. Amazon Cognito handles secure app data storage and sync, enabling you to focus on your app experiences, instead of the heavy lifting of creating and managing a user data sync solution.

A guy like me loves the part about, “You can do this with just a few lines of code” followed by “without building or maintaining any backend infrastructure.”  Now that’s what I’m talking about, I gotta get me some of this!

It’s nearly all there:

-  Amazon is an outfit that can be trusted for the long haul.

-  REST API’s are no problem, that’s how Amazon prefers to operate.

-  Tie back to other Amazon Web Services?  Puh-lease, who do you think you’re talking to, of course one Amazon Service talks to the others!

-  Sync?  Yeah, baby, that’s what Cognito is all about.  More potential time savings for yours truly.

Oops, just one little shortcoming:  it only does Federated Login via Amazon, Facebook, or Google.  That’s cool and all, but wheres my Email + Password login so I can seamlessly move customers over to it?  Maybe I missed it, maybe it’s coming, or maybe Amazon just doesn’t think it’s important.  Can I live with forcing my users to make sure they have either an Amazon, Facebook, or Google account?  Yeah, I guess maybe, but we sell a B2B app and it sure seems kind of unprofessional somehow.

Amazon, can you please fill this hole ASAP?

Firebase

I hear fabulous things about Firebase, I really do.  People seem to love it.  It’s chock full of great functionality, and on the surface of it, Firebase should fit my needs.  Yet, when I dig in deep, I find that the login piece is kind of a red-headed stepchild.  Yeah, they advertise Email + Password Login, and they even tell you how to do it.  But there’s no RESTful API available for it.  They list all the right operations:

-  Login, and returns a token
-  Create a new user account
-  Changing passwords
-  Password reset emails
-  Deleting accounts
etc.
However, it appears that those things are handled by a client library which is in a very dev platform specific format.  If you use one of their chosen platforms, it’s ok.  If not, you can only use their rest API’s for the Cloud Database–no login functionality.  That’s going nowhere for me.  It would’ve been so much nicer had they packaged what’s in the client library in their Cloud and provided RESTful API’s for the functions I’ve listed.  As I told them when I made the suggestion, that makes their offering accessible to virtually every language and platform with the least effort for them instead of just the few they support.
Conclusion:  Crowd Sourcing?
Hey, I’m open to suggestions and the Wisdom of the Crowd.  Maybe someone out there knows of a service that meets my requirements.  They seem pretty generic and I’m frankly surprised I still can’t find such a thing after all these years of building almost anything you can imagine as a service.  We’re not very far away from it.  Either Amazon or Firebase could add the functionality pretty easily.  I’m hoping maybe I’ll get lucky in the next 6 months or so.  If anyone knows the right people in those organizations (or their competition), pass this post along to them.

 

 

Posted in bootstrapping, business, cloud, mobile, platforms, saas, service, software development | 2 Comments »

How Moore’s Law Put Apple in the Driver’s Seat and Cost Steve Ballmer His Job

Posted by Bob Warfield on January 24, 2014

With the Mac’s 30th anniversary, lots of folks are writing all sorts of articles about it, so I thought it only fitting to bring up my own thoughts on what happened and how Apple got control away from Microsoft.  It’s not a theory I have seen anywhere else, but it’s the one that makes the most sense to me.

Recently, I spent the afternoon upgrading my PC.  I added 2 higher capacity SSD disks, a new graphics card, and a new power supply.  I had planned to add a CPU with more cores, but I couldn’t find it and frankly, I didn’t look all that hard because I knew it wasn’t going to matter very much.

Upgrading my PC is something I used to do like clockwork every 2 years.  I looked forward to it and always enjoyed the results–my computer would be at least 2X faster.  While it didn’t always feel 2X faster, the previous machine (when I still had access to it or one just like it) always felt a lot more than 2X slower.  Life was good in the upgrade heyday for the likes of Microsoft and Intel.  Steve Jobs was this idiosyncratic guy who made cool machines that you couldn’t upgrade easily.  Everyone knew Microsoft had stolen a lot of Apple’s ideas but it was okay, because heck, Apple stole a lot of ideas from places like Xerox PARC.  There were Mac users, but they were a tiny minority, so tiny that Jobs was actually fired from his own company at one point.

Fast forward to my recent upgrade experience.  I hadn’t done an upgrade in 5 years, didn’t feel like I had missed much, and didn’t spend nearly as much money on the upgrade as I had in those times past.  Before that prior upgrade it was probably at least another 3 or 4 years to get to an upgrade.  That one 2 upgrades back was largely motivated by a defective hard disk too, so I’m not even sure it counts.

Times have sure changed for Intel, Microsoft, and Apple too.  Apple is now the World’s Most Amazing company.  Microsoft is in the dumper, Steve Ballmer has lost his job, and Intel just announced they’re laying off another 5000 people.

What happened?

People will say, “That Steve Jobs was just so brilliant, he invented all these new products around music, telephones, and tablets, that nobody wants PC’s any more.”  In other words, Apple out-innovated and out-Industrial Designed Microsoft.  They even changed the game so it isn’t about PC’s any more–it’s all about Mobile now.  We’re firmly in the Post-PC Era goes the buzz.  VC’s are in a rush to invest in Mobile.  It’s Mobile First, Mobile is Eating the World, mobile, mobile, mobile, yada, yada, yada.

But I don’t know anyone who has quit using their PC’s.  Quit upgrading?  Absolutely!  Putting a lot of time on their mobile devices?  Yup.  But quit using PC’s?  No.  Absolutely not.   There are many many apps people use almost exclusively on PC’s.  These are the apps that create content, they don’t just consume it.  One could argue they are the ones that add the most value, though they are not the ones that necessarily get the majority of our time.  Some people are totally online with Office-style apps, but they still much prefer them on their PC’s–no decent keyboard on their tablet or phone.  Bigger screens are better for spreadsheets–you can never see enough cells on the darned things.  And most are still using Microsoft Office apps installed on their PC’s.  CADCAM, which is my day job, is totally focused on desktops and maybe laptops.  Graphic Design?  Photoshop on a PC (well a Mac, and probably a laptop, but they sure don’t want to give up the big gorgeous monitor on the desk much).  Accounting and Bookkeeping?  That’s my wife’s daily work–Quick Books.  Enterprise Software?  Yeah sure, they got mobile apps, but mostly they’re desktop.  Did people unplug all the desktop clients?  No, not even close.  They simply killed the 2 year upgrade cycle.

People will say Microsoft was just too slow, copied without ever innovating, and missed all the key trends.  There is no doubt that all those things were true as well.  But think about it.  Apple has always been great at Industrial Design and Innovation.  Microsoft has always been slow and missed key trends.  Remember the old adage that it takes Microsoft 3 releases before they have a decent product.  That’s been true their entire history.  Something had to be different for these two companies and their relationship to the market.  Something had to fundamentally change.

What’s wrong with Microsoft and Intel has little to do with people quitting their use of PC’s and switching over to Mobile.  It’s not a case of choose one, it is a case of, “I want all of the above.”  There are essentially three things that have happened to Microsoft and Apple on the desktop:

#1 – People stopped upgrading every two years because there was no longer a good reason to do so.

#2 – People who wanted a gadget fix got a whole raft of cool phones and tablets to play with instead of upgrading their PC’s, and Microsoft botched their entry into the mobile market.

#3 –  People who wouldn’t consider spending so much money on a computer that couldn’t be upgraded when it would be clearly obsolete in 2 years suddenly discovered their computer wasn’t obsolete even after 5 years.  So they decided to invest in something new:  Industrial Design.  I can afford to pay for fruit on my machine, just like I used to pay for polo players on my shirts back in the Yuppie Age (I like cheap T-shirts now).  It’s the age old siren’s call:  I can be somebody cool because of a label.

#1 was an unmitigated disaster for Microsoft, and the carnage continues today.  #2 was a botched opportunity for Microsoft they may very well be too late to salvage and it created a huge entre for Apple.  #3 cemented Apple’s advantage by letting them sell high dollar PC’s largely on the basis of Industrial Design.

That’s the desktop PC market.  The server market has been equally painful for Microsoft, but we’ll keep that one simple since Apple doesn’t really play there.  Suffice to say that Open Source, the Cloud, and Moore’s Law did their job there too.  The short story is that there is still a certain amount of #1 in the server market, because machines don’t get enough faster with each Moore’s Law Cycle.  They do get more cores, but that largely favors Cloud operations, which have the easiest time making use of endless more cores.  Unfortunately, the Cloud is hugely driven by economics and doesn’t want to pay MSFT for OS software licenses if they can install Open Source Unix.  Plus, they negotiate huge volume discounts.  They are toe to toe and nose to nose with Microsoft.  So to those first 3 problems, we can add #4 for Microsoft’s server market:

#4 –  Open Source and the Cloud has made it hard to impossible for Microsoft to succeed well in the server world.

Why did people quit upgrading?

Simple put, Moore’s Law let them down.  In fairness to Gordon Moore, all he really said was that the number of transistors would double every 2 years, and that law continues in force.  But, people used to think that meant computers would be twice as fast every 2 years and that has come to a bitter end for most kinds of software.

If you want to understand exactly when #1 began and how long it’s been going on, you need look no further than the Multicore Crisis, which I started writing about almost since the inception of this blog.  Here is a graph from way back when of CPU clock speeds, which govern how fast they run:

Notice we peaked in 2006.  What a run we had going all the way back to the 1970’s–30 years doubling performance every 2 years.  That’s the period when dinosaurs, um, I mean Microsoft, ruled the world.

Oh but surely that must have changed since that graph was created?  Why, that was 7 or 8 years ago–an eternity for the fast-paced computer industry.  In fact, we are still stuck in Multicore Crisis Tar Pit.  A quick look at Intel’s web site suggests we can buy a 3.9 GHz clock speed but nothing faster.  By now, we’ve had 4 Moore Cycles since 2006, and cpu’s should be 16X faster by the old math.  They’re not even close.  So Moore’s Law continues to churn out more transistors on a CPU, but we’re unable to make them go faster.  Instead, the chips grow more powerful by virtue of other metrics:

-  We can fit more memory on a chip, but it runs no faster.  However, it has gotten cheap enough we can make solid state disks.

-  We can add more cores to our CPU’s, but unless our software can make use of more cores, nobody cares.  It’s mostly Cloud and backend software that can use the cores.  Most of the software you or I might run can’t, so we don’t care about more cores.

-  We can make graphics cards faster.  Many algorithms process every pixel, and this is ideal for the very specialized multi-core processors that are GPU’s (Graphics Processing Units).  When you have a 4K display, having the ability to process thousands more pixels simultaneously is very helpful.  But, there are issues here too.  Graphics swallows up a lot of processing power while delivering only subtle improvements to the eye.  Yes, we love big monitors, retina displays, and HD TV.  But we sure tolerate a lot on our mobile devices and by the way, did games really get 2X visually better every 2 years?  No, not really.  They’re better, but it’s subtle.  And we play more games where that kind of thing doesn’t matter.  Farmville isn’t exactly photo realistic.

Will Things Stay This Way Forever?

Microsoft got shot out of the saddle by a very subtle paradigm shift–Moore’s Law let them down.  Most would say it hasn’t been a bad thing for Microsoft to become less powerful.  But it is a huge dynamic that Microsoft is caught up in.  Do they realize it?  Will the new CEO destined to replace Steve Ballmer realize this is what’s happened?  Or will they just think they had a slip of execution here, another there, but oh by the way aren’t our profits grand and we’ll just work a little harder and make fewer mistakes and it’ll all come back.  So far, they act like it is the latter.

And what of Apple?  They’re not the only ones who can do Industrial Design, but they sure act like that’s all that matters in the world.  And Apple has made it important enough that everyone wants to do it.  Don’t get me wrong, I love Industrial Design.  One of the reasons I like Pinterest is it is filled with great designs you can pin on your board.  Is Apple really the only company that can do competent Industrial Design?  Do they have a monopoly on it to the extent that justifies their current profit margins?  Color me skeptical.  Think that new Mac Pro is more than industrial design?  Is it really that much high performance?  The Wall Street Journal doesn’t think so.  How about this hacker that made a Mac Pro clone out of a trash can:

GermanProHack2

GermanProHack

Is it as slick as the real thing?  Aw heck no.  Absolutely not.  But it was made by a hobbyist and professionals can do a lot better.  Companies like BMW are getting involved in this whole design thing too:

BMWAngleView

How Can Apple and Microsoft Win?

Apple has the easier job by far–they need to exploit network effects to create barriers to exit for the new mobile ecosystems they’ve built.  They’re not doing too badly, although I do talk to a lot of former iPhone users who tried an Android and believe it is just as good.  For network effect, iTunes is fabulous, but the video ecosystem is currently up for grabs.  Netflix and Amazon seem closer to duking that out than Apple.  Cook should consider buying Netflix–he may be too late to build his own.  Tie it to the right hardware and it rocks.He should consider buying Facebook too, but it may not be for sale.  Network effects are awesome if you can get them, but they’re not necessarily that easy to get.

Meanwhile, Apple will continue to play on cool.  I’ve been saying to friends for years that Apple is not a computer company, it is a Couturier ala Armani.  It is a coachbuilder ala Pininfarina.  It is an arbiter of fashion and style, but if the world became filled with equally as fashionable artifacts, it isn’t clear Apple could succeed as well as it does today.  Those artifacts are out there.  Artists need less help than ever before to sell their art.  Fashion is a cult of personality, packaging, and perception.  We lost the personality in Steve Jobs.  That’s going to be tough and Apple needs to think carefully about it.  They seem more intent on homogenizing the executive ranks as if harmony is the key thing.  It isn’t.  Fashion has nothing to do with harmony and everything to do with temperamental artistes.

Another problem Apple has is an over-reliance on China.  They’ve already had some PR problems with it and they are moving some production back to North America.  But it may not be enough.

Most people don’t realize it, but $1 of Chinese GDP produces 5X as much carbon footprint as $1 of US GDP produced here in America.  In a world that is increasingly sensitive to Global Warming, it could be a real downside if people realized that the #1 thing they could personally do to minimize it is to quit buying Chinese made products.  Apple can fix human rights violations to some extent, but fixing the carbon footprint problem will take a lot longer.  Apple is not alone on this–the Computer and Consumer Electronics sectors are among the worst about offshoring to China.  But, if the awareness was there, public opinion could start to swing, and it could create opportunities for alternatives.  And fashion is nothing but public opinion.  Ask the artists that have fallen because the world became aware of some prejudice or some viral quote that didn’t look good for them.  That’s the problem with Fashion–it changes constantly and there’s always a cool new kid on the block.

Microsoft has a much tougher job.  The thing they grew up capitalizing on–upgrade cycles–no longer exists.  They have to learn new skills or figure out a way to bring back the upgrade cycles.  And, they need to get it done before the much weaker first generation networks effects of their empire finish expiring.  So far they are not doing well at all.  Learning to succeed at mobile with smart phones and tablets, for example.  They have precious little market share, a long list of missed opportunities, and little indication that will change soon.  Learning to succeed with Industrial Design.  Have you seen the flaps around Windows 8?  Vista?  Those were mostly about Design issues.  Microsoft doesn’t worship Design with a capital “D” as Apple does.  It worships Product Management, which is a different thing entirely, though most PM’s fancy themselves Design Experts.  Microsoft is just too darned Geeky to be Design-Centric.  It’s not going to happen and it doesn’t matter if they get some amazing Design Maven in as the new CEO.  That person will simply fail at changing so many layers of so many people to be able to see things the Design Way.

Operate it autonomously from the top the way Steve Jobs did Apple?  The only guy on the planet who could do that is Bill Gates and he doesn’t seem interested.  But, Gates and Ballmer will make sure any new guy has to be much more a politician and much less a dictator, so running it autonomously from the top will fail.  Actually, Bill is not the only one who good do it–Jeff Bezos could also do a fine job and his own company, Amazon, is rapidly building exactly the kinds of network effects Microsoft needs.  The only way that happens is if Microsoft allows Amazon to buy it at fire sale prices.  Call that an end game result if the Board can’t get the Right Guy into the CEO’s seat.

The best acquisition Microsoft could make right now is Adobe.  It still has some residual Old School Network effects given that designers are stuck on Photoshop and their other tools.  Plus Adobe is building a modern Cloud-based Creative Suite business very quickly.  But this is a stopgap measure at best.

Can the upgrade cycle be re-ignited?

There is a risky play that caters to Microsoft’s strengths, and that would restore the upgrade cycle.  Doing so requires them to overcome the Multicore Crisis.  Software would have to once again run twice as fast with each new Moore Cycle.  Pulling that off requires them to create an Operating System and Software Development Tools that make can harness the full power of as many cores as you can give it while allowing today’s programmers to be wildly successful building software for the new architecture.  It’s ambitious, outrageous even, but it plays to Microsoft’s strengths and its roots.  It started out selling the Basic Programming Language and added an Operating System to core.  Regaining the respect of developers by doing something that audacious and cool will add a lot more to Microsoft than gaining a couple more points of Bing market share.  Personally, I assign a higher likelihood to Microsoft being able to crack the Multicore Crisis than I do to them being able to topple Google’s Search Monopoly.

Let’s suspend disbelief and imagine for a minute what it would be like.

Microsoft ships a new version of Windows and a new set of development tools.  Perhaps an entirely new language.  They call that ensemble “MulticoreX”.  They’ve used their influence to make sure all the usual suspects are standing there on the stage with them when they launch.  What they demonstrate on that stage is blinding performance.  Remember performance?  “Well performance is back and it’s here to stay,” they say.  Here’s the same app on the same kind of machine.  The one on the left uses the latest public version of Windows.  The one on the right uses the new MulticoreX OS and Tools.  It runs 8X faster on the latest chips.  Plus, it will get 2X faster every year due to Moore’s Law (slight marketing exaggeration, every other year).  BTW, we will be selling tablets and phones based on the same technology.  Here is an MS Surface running an amazing video game.  Here is the same thing on iPad.  Here’s that app on our MulticoreX reference platform that cost $1500 and is a non-MulticoreX version of the same software on a $10,000 Mac Pro.  See?  MulticoreX is running circles around the Mac Pro.  Imagine that!  Oh, and here is a Porsche Design computer running MulticoreX and here’s the Leatherman PC for hard working handy men to put in their garages, and here is the Raph Lauren designed tablet–look it has design touches just like the Bugattis and Ferraris Mr Lauren likes to collect!

ShelbyGT500KR

Performance is back and it’s here to stay!

Can it be done?

As I said, it is a very risky play.  It won’t be easy, but I believe it is possible.  Microsoft already has exactly the kind of people on staff already that could try to do it.  We were doing something similar with success at my grad school, Rice University, back in the day.  It will likely take something this audacious to regain their crown if they’re ever going to.  They need a Skunkworks Lockheed SR-71 style project to pull it off.  If they can make it easy for any developer to write software that uses 8 cores to full effect without hardly trying, it’ll be fine if they have no idea how to do 16 cores and need to figure that out as the story unfolds.  It also creates those wonderful lock-in opportunities.  There’ll be no end of patents, and this sort of thing is genuinely hard to do, so would-be copiers may take a long time to catch up, if ever.

This is not a play that can be executed by a Board that doesn’t understand technology very well or that is more concerned about politics and glad handing than winning.  Same for the CEO.  It needs a hard nosed player with vision who won’t accept failure and doesn’t care whose feathers are ruffled along the way.  They can get some measure of political air cover by making it a skunkworks.  Perhaps it should even be moved out of Seattle to some controversial place.  It needs a chief architect who directly has their fingers in the pie and is a seriously Uber Geek.  I’d nominate Anders Hejlsberg for the position if it was my magic wand to wave.

It’s these human factors that will most likely prevent it from happening moreso than the technical difficulty (which cannot be underestimated).

Posted in apple, business, multicore, platforms, software development, strategy | 2 Comments »

You Have to Have an Overseas Dev Team to Scale? Baloney!

Posted by Bob Warfield on September 7, 2013

Baloney1ba·lo·ney 2 also bo·lo·ney (b -l n ) Slang. n. Nonsense. interj. Used to express disagreement or exasperation.

Recently, I was doing something on LinkedIn, and it asked me to endorse various people’s skills like it often does.  One face in particular popped out at me:  Anders Hejlsberg.  I’ve known Anders for many years, so I immediately had to check what it was about.  In this case they wanted me to endorse that Anders knows something about Software Engineering.  Unfortunately, it was a simple Endorse/Don’t Endorse interaction, because I would like to have said that Anders knows about as much about Software Engineering as the Pope knows about Catholicism.  You see, Anders is a Technical Fellow at Microsoft.  But beyond that, he is one of the most brilliant Software Engineers I’ve ever known.  I met him when I was VP of Engineering at Borland and he was the guy that built Delphi, or Turbo Pascal as it was known when I first came to Borland.  He went on to do C# and a whole lot more for Microsoft after leaving Borland in 1996.  Not only is he a brilliant Software Engineer, he is also one heck of a nice guy.

By now you’re wondering, “What does Anders Hejlsberg have to do with Overseas Development Teams anyway?”

Let’s start with why I even bring up the overseas subject.  To put it simply, I needed to pen a rebuttal to Jason Lempkin’s Wall Street Journal article which says essentially that all SaaS companies are probably going to have to have an overseas dev team because its just too hard to hire talented Software Engineers.  In fairness to Jason, he did say “probably”, but he said it so softly it’s clear he doesn’t mean it.  I disagree violently with the conclusion, to put it mildly.

The thing is, most software companies go about developing software all wrong.  They get pushed in all sorts of directions when people who don’t know much of anything about Software Engineering (i.e. non-technical CEO’s, VC’s, and the like) insist things be done a certain way because someone else they’re familiar with did it that way and succeeded.  There may be limited correlation, but there is absolutely no causality.  It’s not like we technical types have a monopoly on that stuff, I’m sure there’s plenty of Technical CEO’s telling their sales and marketing people similarly poorly informed things.  But the thing is, it happens a LOT more often to the technical types.  Plus, we techies often don’t have the backbone and interpersonal skills to stand up very well when a CEO or Board Member gets up a good head of steam about some issue.  Sometimes having technical leads who can’t stand up and disagree is intentional.  I would say that in over half the VP of Engineering jobs I’ve ever interviewed for they were looking for someone who would demurely take stone tablets from some other source–product management, sales, the CEO, or some “visionary”–and just get it done on time and one budget.  And by the way, do it quietly and without disturbing the other functions.  Needless to say, I was “over qualified” for those positions.

A lot of companies do a lot of things wrong, but Software Development is different.  It takes longer to build software.  It’s harder to change direction at the last minute.  And by the way, did you notice?  They’re called “Software” companies.  They’re not called “Sales” companies, “Marketing” companies, or “CEO’s best notion of the moment” companies.  It’s important that you actually be competent at building software in order to have a real “Software” company.

I was recently reading over a list of startup advice (you know how those numbered lists grab the eyeballs) a VC had put forward on Facebook as being excellent.  I got as far as #8:

8) Should you have a technical co-founder if you are not technical? No. If  you don’t already have a technical cofounder you can always outsource  technology and not give up equity.

I quit reading in disgust so I could go on to see just exactly what sort of software this guy builds.  Mostly, he seems to have parlayed a pretty basic web site into a sale to TheStreet.com.  From there, he’s mostly in the business of telling everyone else how to succeed.  There are so many of these Dale Carnegie types out there these days.  He does not appear to be a Software Engineer, though perhaps he has played one on a TV show somewhere.  This stuff makes me nuts.  Companies that think software is easy to build.  A venture ecosystem that needs to invest in lightweight products because the founders have to pay to get it built on their nickel.  CEO’s that couldn’t care less about building something that can actually change the world, they just want to throw something out there as cheaply as possible so they can spend more on this month’s lead generation.  Bubble riding, in other words.

Whatever happened to the days when people actually had to build something of note?  Something that might change the world, even a little bit, and not yet another eyeball aggregator?

Let’s put that rant aside and get back to the question of whether you will have to have an overseas dev team to scale.  I will put my stake in the ground thus:

You have a choice for your software company:  you can either choose to be excellent at building outstanding software or you can choose to build adequate software cheaply.  The latter path will ultimately be even more expensive than the former, but you’ll be left holding junk instead of a real product.

I’ll warn you I’m being very polite when I talk about software being “adequate.”  Software is hard.  It is the most complex stuff we humans build, at least until we start building organisms from scratch by tinkering with DNA.  Many things that people say are harder are basically software, things like CPU chips.  There’s this little problem in the software world–we don’t know how to get lots of Software Engineers to be able to work effectively together.  There are entire disciplines such as Agile Programming that try to deal with this problem.  We’ve known about the problem almost from the beginning of software.  It was well articulated in the relatively ancient Brooks classic, “The Mythical Man Month.”  It turns out, we’re only good at getting 7 to 10 developers working smoothly together.  Any more than that and you’d better be able to break the software down into modules that are very independent.

If that’s the fundamental limit, how do you build great software?  Here’s a hint:  you can’t do it by hiring more people onto the team.   Instead, you must focus on building great software with fewer better Software Engineers.  You must focus on breaking down the software into modules that work and play well together, something that is also very hard to do and can’t be offshored.  That’s hard core architecture that takes brilliant Software Engineers communicating well with all the groups.  I have never seen a product module that couldn’t be built with about 10 engineers provided they’re the right 10 engineers, they’re well managed, and they’re operating in a culture that supports their needs.

Anders, back in the day, built the Pascal software he is famous for almost by himself.  He had a little help, but surely not a giant team half of which was located overseas.  I have done the same with every product built over my career.

When I took over the VP of Engineering job at Borland, it was the darling of the software world.  We had our share of problems, and one of them was profitability.  I was directed to make cuts.  It didn’t take me long.  I zapped all the consultants I could find and reduced the maximum team size to 10 developers or so.  Not one single product slipped schedule as a result of it.

So what’s the deal with this big overseas software push?

In exchange for making the acknowledged weakest link in software development (communication) much worse, we get to hire lots more people.  At one point, Oracle would trade 2 open reqs overseas for 1 open req here on our shores (Redwood Shores to be exact).  They discovered over time what a bad idea that was and ended the practice some time ago.

Companies the size Jason suggests must go overseas, $3 to 4M in ARR, are still way too small to need to go overseas.  They’re still finalizing fundamental architectural underpinnings.

I can already hear the refrain, “That’s nice, Bob.  But I can’t hire enough good Software Engineers, what else can I do but go overseas?”

If you can’t hire, and I don’t doubt there are companies that can’t, you need to look much closer to home to find the problem:

-  Perhaps your company doesn’t value developers and act like the “Software” in Software Company matters.

-  Perhaps the head of your engineering group is not an inspiring figure.  Will walk-on-water developers follow her or not?  Does she know lots of walk-on-water developers who she can bring on?  Why not?

-  Perhaps your product vision is just not interesting to walk on water developers.

I’ve seen all of these problems in varying degrees at various places I have visited.  I went to a video ad company one time that was proud of the density it could pack developers into.  They had long benches and developers were literally shoulder to shoulder.  There was a strong “no telecommuting” policy in place on top of that.  Sales and marketing had conventional cubes, by contrast.  I wonder if management in that company was aware that software development requires intense concentration and focus?  In the heyday of Borland, each developer had their own private office.  Close the door and you could get some serious work done.

By the way, amidst all the hand wringing about there not being enough visas (more evidence we can’t hire enough developers and we must go overseas!), there is more than one study out that says it’s all a sham.  We are graduating more STEM graduates than we can even put to work.  Most of them don’t stay in their field and wages have been stagnant since 2000.  Does that really sound like a market where you can’t hire developers?

I have interviewed at companies where the developers begged me to come on board and save them from Sales and Product Management.  They wanted to be released from dealing with one unrealistic deadline and shoot for the moon set of specs after the other, because they were failing at every single one.  They had no voice in setting any of it up.  I wonder if the VP of Sales turned CEO set his sales quotas up to be unachievable time after time?  If he was, Sales was no doubt failing there too.

Too many customer demands to keep up with?  Hogwash (time for a word other than “Baloney”).  Build an architecture that’s intended to keep up with customer demands.  Build one that is customizable at the outset.  Salesforce did.   I ran engineering for Callidus Software through their IPO.  That companies processes sales compensation for the biggest companies in the world.  If you don’t think sales constantly fiddles with comp plans and that every company does it differently, you don’t know that market.  Our differentiator was that we had the only product that could deal with those customer demands and still scale to the levels giant companies like Sprint and Allstate needed.

Let’s wrap this up.  We will probably agree to disagree, but I want to summarize.

Good software is not expensive to build nor is a good software team hard to hire for.  The reason is simple–you only need 10 really good people to do almost anything.  Once those 10 are working well, start thinking about how to modularize your software for the next 10 person team.  You can start to get real business-changing things done with a lot less than 10 too, that’s just the maximum.

If you have any doubts, try tearing apart the financials for Salesforce.com.  They have managed to build the world’s most successful SaaS company with relatively few developers.  Fewer than their peers according to the numbers: the percentage of expenses that go to R&D is small compared to many other SaaS companies.  The architecture of their product is rich and sophisticated.  That didn’t happen by accident, it happened because they understand what I’ve been trying to say here.  They hired for quality, not quantity.

Bad software, on the other hand, is very expensive.  It is expensive because you’re throwing a wall of bodies at a problem that cannot be solved by a wall of bodies.  They will build something that is ultimately unsatisfying and unmaintainable.  They will not produce good architecture or good user experience.  They will not produce sustainable competitive advantage in one of the few areas software companies can have such advantages.  They will fail and your customers will be unhappy.  Your competition will love it.

Posted in business, software development, strategy | 3 Comments »

How Many Software Companies Monitor Their Software as Well as Tesla Monitors its Cars?

Posted by Bob Warfield on February 14, 2013

The unfolding story of how the New York Times’ negative review of the Tesla Model S may have actually been faked is a cautionary tale for software vendors.  Basically, there is enough instrumentation and feedback built into the Tesla S that Elon Musk was able to “shred” the review, as Dan Frommer writes.  The graphical plot of exactly what was happening with annotations is particularly damning:

NY Times Tesla Speed Chart

It’ll be fascinating to see how the NYT responds.  Hard to imagine how they do anything but investigate Broder and ultimately move him along elsewhere.  To do much else would imply very little journalistic integrity.

My question for you is that since you’re reading this blog and are likely somehow involved in high tech hardware or software at some level, how does your product compare in terms of how well it can monitor what your users are doing with your product?

I’m fascinated with the idea of closing the feedback loop for the good of customers.  Yes, it’s great Musk can catch the NYT in a bogus review, and perhaps you will catch a reviewer too, but the potential for improving your customer’s experience is of much greater value to your product.  This may seem like a Big-Company-Only idea, but I’m pursuing it with a vengeance for my SaaS bootstrap company (CNCCookbook) because I need precise feedback that pinpoints where I can do the most good for my users with the scarce resources I have available.  I can tell you from experience that the tools are available and straightforward.  You can have the data for very little effort invested.

The next thing I am after is to automate responses to that data.  I’ve been reading the blog of a company called Totango with some interest.  They essentially want to provide SaaS automation for a Customer Success team.  Various folks have written about the importance of Customer Success and I’m also a big believer.  My thoughts at this point are to start out relatively simple.  I want to understand the early lifecycle of my products and be able to trigger automated actions based on that cycle.  For example:

Step 1:  Installation

Monitor the first time the customer has successfully logged into the product.  Offer increasing amounts of help via emails once a day until they achieve this milestone.  The emails can start with self-service help resourcs of various kinds and eventually escalate to offering a call or help webinar.  The goal is to get the customer properly installed.

Step 2:  Configuration

This seems like part of installing, but in fact there is significant post installation configuration needed for CNC Manufacturing software.  Same sort of thing: provide daily emails with increasing levels of help until the system determines that the user has properly configured the system.  Also, this is an opportunity to collect information.  We provide canned configuration for the most common cases and finding out what the next tranche of cases to target should be is very helpful.

Step 3:  The Path to Power Usage

It’d be great if everyone who signed up for our 30 day free trial actually got to see and understand all of the features that set our product apart.  I’ve seen some other products like Dropbox (Full disclosure: they give me another 250MB of storage if you use that link and then sign up. If you’d rather I didn’t get the extra storage, use this link instead. If you sign up, they’ll give you a link where you can get 250MB free too.) walk customers through a usage maturity exercise.  They’ve somewhat gamified it by giving out some of their “currency” in the form of extra storage if you complete the tasks.  My goals here would be to get everyone to see as many of our unique functions as possible during the 30 day trial.

Step 4:  The Holy Grail: Referrals

If all this goes well, the customer gets through the Trial, understands the unique capabilities of our products, and likes the product well enough to buy it, then the final stage in this incarnation is to ask them to refer others they know who might like the product.

That’s a pretty simple roadmap for how to create some closed-loop feedback of telemetry and drip email that improves your customer’s experience.  So I’ll ask again:

Is your company setup to monitor your users as successfully as Tesla monitors its drivers?  Why not?  I’ve used a lot of software where it is pretty clear they’re not monitoring much at all.  I’ve even talked to some of them to encourage change, and they seem receptive.

If you have a story about what sort of work along these lines you’re doing, please share it in the comments below.  I’m very curious.  I think we have the potential to personalize the experience for our customers like never before.

Posted in business, cloud, customer service, software development, strategy, user interface | 7 Comments »

Gaining the Wisdom of Crowds in a Bootstrapped SaaS Company

Posted by Bob Warfield on November 19, 2012

Beta Survey FormWhen you’re bootstrapping a small company, sometimes it’s hard to do the things larger organizations take for granted, like making sure you’re listening well enough to your customers.  On the other hand, you can take advantage of your nimble nature and the availability of some great technology to do some things that even a lot of larger organizations don’t manage to pull off.  At CNCCookbook, my small Manufacturing Software company, I’ve had to think long and hard about how to register the wisdom of my Crowds to make sure the company is on the right track with its products.  Lest you think small companies with fewer employees than you can count on one hand don’t have Crowds to learn from, CNCCookbook gets over 1 million visitors to its site every year and we’ve had over 15,000 machinists use the software to date.  We count some of the world’s largest manufacturers on our Customer List as well.  In short, there’s plenty of Wisdom to be had from our Crowds, it’s a matter of finding the right ways to capture it and put it to use.

Having come from a Social CRM background at Helpstream, the value of harnessing the Wisdom was not lost on me.  It was something that had worked well for me throughout my career and something I very much wanted to do well with at CNCCookbook.  Here is a brief history of how I went about it and which tools, techniques, and technologies were put to work to do so.

Phase 1:  Forums and Web Analytics

Right from the very start I deployed a set of User Forums which I called the “G-Wizard User Club” (CNCCookbook is our company and web site, G-Wizard is the software brand that labels our products).  Much as I miss the sophisticated capabilities we had at Helpstream (they haven’t been rivaled by any product since), I had to make do with what was available and what fit my budget.  I knew I wanted a SaaS-based service.  However easy it might be for me to install and administer phpBB or some other Open Source bulletin board, it would be one more thing for me to do.  As the sole person working in the company at this time, I made the decision to focus as much of my time as possible on things that were uniquely differentiated for our company.  Deploying phpBB wouldn’t even come close, so I went with an alternative that was both a SaaS service and ad-supported called ProBoards.

It has worked reasonably well, and served its purpose.  I moderated membership and got a lot of mileage out of the boards.  They continue to be popular to this day, and we have not quite 2000 members there today.  To make sure every User was aware, I also instituted an in-app button to take open the browser and take them to the User’s Club.

You can see there’s more than just the User’s Club there on that Login Bar, but it started with just the User’s Club and grew to encompass a number of resources every User needs to be aware of.  While our app doesn’t run in a browser (it’s an Adobe AIR app as disconnected running is often important to our audience), it behaves in every other way like a browser-based SaaS app and we have embraced a lot of the design concepts for such apps, such as seamless access to the important parts of our web presence and incorporating that presence as a first class citizen of our navigation structure.

Another critical source of the Wisdom of Crowds is your Web Analytics.  We use Google Analytics, and there is a wealth of information to be gleaned.  For example, our User Guides are entirely online and we can see from the Web Analytics which parts of the product are more interesting than others just by watching the traffic patterns.  As we do each new release we write a blog post that discusses the new functionality in the release and again this provides a framework for using Web Analytics to understand what’s going on with the product.

In app access to Getting Started Resources, our Support Portal, and the User’s Club Forums…

Phase 2:  Blog Comments, Social, and Surveys on the Web Site

CNCCookbook started as a plain old web site and went for quite a while like that.  We had an area where articles were presented in a quasi-blog format, but it wasn’t really a blog.  It didn’t take long before we’d outgrown that format and it was time to add a real blog based on WordPress.  If I had it to do over again, I would recommend that every company simply start with WordPress and eschew the plain old web site phase.  It’s a fantastic content management system that has a rich ecosystem supporting it.  In keeping with my SaaS philosophy (why would I spend my scarce time maintaining a commodity like WordPress instead of focusing on what makes our company different?), we signed up with page.ly to host WordPress for us.  We spliced the blog into our plain old web site using DNS Made Easy, a SaaS DNS service that’s been excellent.

This transition marked a big step up for us in a whole lot of ways.  There were obvious SEO advantages that were very visible in the Google Analytics reports.  It became much easier to manage our content and we did a major upgrade to the site’s look and feel (it’s getting close to time to do another, I think).  Best of all, we now had comments on every post and could deploy a host of social widgets to help harvest as much feedback from our audience as possible.  One of the first things I did once WordPress was up and running was to go out and survey key sites to see what sorts of plugins they were using with WordPress.  My approach was to use a variation of a Blackjack card counting strategy I had perfected to decide my Social Widget strategy.  I’ll say more about the Blackjack in a future post, but suffice to say I analyzed the widgets used by a number of top marketing blogs on the theory that these people should know.  I went to companies that clearly had lots of experience with conversion and A/B testing like Unbounce.  I went to specific marketing gurus like Neil Patel’s Quick Sprout blog.  It was an excellent way to focus my efforts and populate the CNCCookbook blog with what I think are an excellent set of Social plug-ins to maximize engagement.

Having done that, I turned to Surveys.  While it was kind of an expensive luxury, I bought two different tools.  I wanted a survey tool that would be innocuous and unobtrusive.  I hate visiting a site and getting hammered with a full stop “please answer our survey” ten seconds after I get there.  At that point, I have formed no opinion but a negative one about the damned survey.  At the time, KissMetrics had an awesome tool called KissInsights that would slide up from the bottom of screen in a very low key way.  That tool is now sold by Qualaroo and works great.  It’s biggest issue, and the reason I don’t use it for all my surveys, is it is limited to simple surveys.  So, I also subscribed to SurveyMonkey.

I use the Qualaroo tool to derive a Net Promoter-style feedback score on the overall product (ours is very high) and I use the Survey Monkey to do more detailed surveys aimed at understand the details of my audience.  For example, I have done surveys of which CAM software they use or which CNC control is on their machines.  Not only is this invaluable data (sort of like surveying which PC, OS, or browser a PC software audience uses), but it makes great content to publish on the blog.  Some of my all-time best traffic articles are just the results of such surveys.  Apparently others also want to understand the Wisdom of Crowds.

Phase 3:  Ideation and CRM

For Phase 3, I wanted some Social and Conventional CRM.  It was time to get a Trouble Ticketing system going.  I chose a vendor called UserVoice for several reasons.  First, it comes with a very nice Ideation App.  Ideation gives my audience the ability to suggest new features and vote on them, like Dell’s Ideastorm.  This is an extremely powerful capability for a small organization to use to focus scarce development resources.  The results will often surprise you.  Ideation is one aspect of what we had at Helpstream, so it was nice to get some of that back.  Second, it’s SaaS.  And third, I got a great deal on it via AppSumo.  BTW, AppSumo has yielded several good deals for my bootstrap venture.  I’ll warn you in advance, they’re very spammy in their email and you really have to know what you’re looking at when you consider the products they push, but if you are patient about wading through some spam and have a clear idea what your business needs, you’ll find some great deals to keep the overhead down.

One of our products, G-Wizard Calculator, is much more mature than our later products because it has a 2 year head start on them.  While I still have a lot of ideas about where I want to take that product, it has a solid conceptual foundation.  What I mean by that is that it is ready to be steered to a much greater extent by customers.  Ideation tools are a great way to do this as they force customers to ration their votes.  On our site, they get to use 10 votes, and can vote no more than 3 votes on any given idea.  Submitting a new idea uses up a vote.  Once the votes are used, they have to wait until the fait of an idea is decided, they are either implemented or rejected, at which time they get the votes back, or they can redeploy the votes.  This scarcity of votes gives a clearer signal of what really matters to your tribe.  Any time I am preparing to do a new release of the Calculator, I always start with our Customer Support Portal and look over the Ideation results.

Phase 4:  In-app Feedback and ET Phone Home Telemetry

This brings me to our current stage of evolution–In-application Feedback and Telemetry.  In keeping with our theme of making the product behave like a web application, we added a Beta Survey popup such as you see above.  This has been a very useful way to monitor our progress from Beta to release-ready.  After spending 10 days focusing development entirely on issues raised in the Beta Survey, we’ve been able to move to 81% of respondents scoring the app during the last week as either “3 – I could use this” or “4 – GWE rocks!”  For the period older than 1 week, the score was only 47%.  Clearly, users were able to tell us what they needed that was missing from the app.  We intend to continue for a while longer until we see a point of diminishing returns and then we’ll declare the Beta done.

In addition to the Beta Survey, we also receive what I call, “ET Phone Home Telemetry.”  This is basic telemetry on which parts of the app are actually being used and how well they perform.  For example, the centerpiece of the application is a complex 3D graphics simulation that shows how the machine tool cutter will move as it executes the g-code program loaded into GW Editor.  We monitor and report back the longest runs so we can get an idea of how the system is performing and whether we need to do more work on performance.  We also track usage information like how many times the user has logged into the app.

The technology that makes the in-app telemetry and Beta Survey easy is something called “Mandrill” that is offered by the MailChimp people.  Rather than having to build back-end server infrastructure that loads all this data into some form of database using an API, the app simply emails it back to us with Mandrill.  The volumes are such that it is very straightforward to collate the information in Excel for analysis.  Building a full-on database application for a 2000 person Beta test would have been needless complexity and time taken away from our focus on doing what differentiates our software.  Mandrill is what MailChimp calls “transactional email”.  I take that to mean email generated by machines, rather than by people, and that’s exactly what we’re doing here.  MailChimp has a Freemium model, and at our level, Mandrill is essentially free.  Not only was it very easy to implement, but it doesn’t cost us anything.  For bootstrappers, that’s a hard combination to ignore.

Conclusion

Just because you’re bootstrapping and have minimal budget and resources is no reason to ignore the Wisdom of Crowds.  In fact, I’d argue that having the Wisdom of Crowds helps you to allocate your scarce resources where they will really matter.  Towards that end, what we do differently at CNCCookbook as bootstrappers is build as little software as possible.  We want to focus every line of code written on problems that you simply can’t get solutions for elsewhere.  Problems that are unique to our audience of CNC machinists.  The more of those problems we can solve, the more value we bring to our customers.  Everything else is just overhead.  Towards that end, we have relied heavily on SaaS, on the Amazon Cloud, and on our ingenuity to lash together the available off-the-shelf technologies to give us the ability to deliver an overall User Experience that is arguably better than almost everywhere I’ve ever worked.  This despite every where else having vastly more budget and resources at their disposal.

I’ll give one last plug to SaaS and the Wisdom of Crowds.  We do as much testing as possible, but again, as a bootstrapped organization, we don’t have large numbers of testers.  Our software quality is therefore a focus of three things.  First, unit testing is important.  Whenever complex new subsystems are added to the software, we make sure there are unit tests.  I personally believe in single stepping the debugger until I’ve seen all the lines of code executed and verified the intermediate results are good.  Unit Tests not only help tee up the execution of all the paths, they also ensure that down the road we can validate intermediate results as changes are made.  Second, we release often.  I don’t like to change too many things without doing a release.  This means that the amount of testing per release is relatively contained to new functionality and our scarce testing capabilities can be focused.

Lastly, we use what I call a “feathered” release methodology.  Each time we release, there is a 7 day cycle.  On each day, we expose an additional 1/7 of the user base to the availability of the release.  Customers that insist on having the latest and greatest can change a setting so they see every release immediately, but most stick to the default.  This ensures that if anything is too badly broken, we’ll hear about it before a very large fraction of the installed base is exposed to it.  In this way, we’re also using the Wisdom of Crowds to help safeguard the quality of our software, and it has worked extremely well to date.

So, whether you’re a bootstrapper or a big company, think about how you could take advantage of the Wisdom of Crowds.  Not only will it make a big difference for your software, but it’ll show your audience that you care and that they have a voice.

Posted in bootstrapping, business, customer service, saas, software development, strategy, user interface | 7 Comments »

Biggest Post Ever Redux: NoSQL as a More Flexible Solution?

Posted by Bob Warfield on July 23, 2011

Thanks to Reddit, HackerNews, and a host of other sources, my post on NoSQL being a Premature Optimization just became the biggest post ever for Smoothspan Blog.  Thanks to all for reading!

I’m actually surprised at how little argument the post has gotten.  The best comeback has been that NoSQL is not just about scaling.  You can see some of that sort of response in the comments for the original post.

The “it’s not about scaling” argument boils down to it being easier to model some kinds of problems with NoSQL than Relational because the tools and model are more flexible.  To this, I can only respond, “yeah maybe, but was modelling really the hard part of what you’re doing?”

I’ve modeled a lot of things in relational.  Some of them were very arbitrary and had little to do with the hardcore relational way of thinking.  Come to think of it, most were pretty arbitrary.  More than one commenter suggests that the existence of object relational mapping layers is a clear indication of how painful relational can be.  But it sure doesn’t feel that way if you’ve done a lot of it.  Seems like the usual sort of shoehorning some arbitrary notion into a data structure that we deal with all the time in Computer Science.  There are lots of good proven tools for it.   I’ve built mapping layers too and even that wasn’t all that hard.  Adrian Cockcroft from Netflix left one of the very first comments and suggested it was hard to beat the productivity of Ruby on Rails with MySQL for a small team.  That’s a case where the mapping layer became integral to the fabric of the framework, and one I’d love to see happen more often given how fundamental persistent storage is to a lot of problems.   One could even argue it is the fundamental thing that sets Ruby on Rails apart was making persistence a first class problem they wanted to solve up front.  Maybe there is another Ruby on Rails success story just waiting for a NoSQL tool to get crossed with some up and coming dynamic language.

Go back to my original post on NoSQL and go through some of the Netflix materials.  Some of the problems they had to solve in NoSQL are modeling problems there too, BTW.  The difference is that the warts and edge cases for relational are pretty well understood by now.  You don’t have to invent your own solutions (as the Netflix people did for things like NULL handling)–there are 6 or 8 out there just waiting to be Googled to choose from.

But this all ignores my question about whether modeling was really the hard part.  I don’t think it is, though developers love to think about the up front “minimum best fit to their design vision” as the hard part.  Having been through 6 startups now, the hard part is all the stuff that isn’t written down.  It’s the problems that pop up when things just don’t work, don’t work as expected, stop working, work too slowly, and generally just piss you off for no good or predictable in advance reason.  They pop up in the middle of the night, late in the project, after customers get hold of the software, and when there is no turning back.  They show up in spades when you hire new people and don’t have time to train them, so they just have to figure it out on their own.  Such problems extend far beyond mere development of a prototype and will in the ops and day-to-day care and feeding of a successful system.  They are problems born of a lack of maturity.  They get gradually burnished away over time in mature toolsets as bugs are fixed, experience spreads, and patterns and know-how are disseminated to the community.  NoSQL (let alone NewSQL) is just not old enough to be there yet relative to relational.  Give it a minimum of 5 years and more likely 10.  Companies like Netflix are helping make it happen as we speak.  When there are 10 Netflixes that have all built big projects that are wildly different and in total involved over 1000 developers, then we’ll have a start on it.

Meanwhile, you have a startup or a project that needs doing.  If you have a cadre who have already been through NoSQL in a prior startup or project, they may have the experience and scar tissue to make an informed decision about it.  They represent a localized burnishing of the worst problems away.  If you haven’t ever done more than read articles and tinker with toy projects, why would you risk your important project playing around with this new technology?  What do you hope to gain when there are proven solutions already at hand?  Do you expect the Silver Bullet that will magically cut your development time in half?  Do you think your startup or project is so easy you have the luxury to experiment with additional risk?

Interesting.

Posted in software development | 7 Comments »

Have Your Kids Tried Programming?

Posted by Bob Warfield on July 14, 2011

Each summer we try to arrange that our kids have a mix of fun things and self-enriching things to do.   Self-enriching things are intended to help them develop their talents and maybe get a little better prepared for the next year in school.  If they had some weaknesses the prior year, we’ll have them work on those a bit and we’ll try to get them looking ahead at next year’s equivalent class.  We try to give them some say so on these projects so long as they stick to things that move the ball forward against the original goals.  By way of developing talents, this summer we decided to try programming.

I had looked into the possibility months before and decided Python would be the learning vehicle.  It has a number of charms, seems to be one of the Cool Kids Languages, is powerful enough to do useful work, has a following among educators and so on.  In addition, it had a couple of strong marketing attributes that I think worked well with the kids.  First, they respond when they hear it is one of the languages of choice at Google.  I’ll never forget driving by Google’s offices one day in Mountain View and having my 12 year old daughter beg to go check it out.  I was surprised that a young girl would care about Google, but to her it was a chance to see a very cool thing.  I explained that the campus wasn’t really open and that while there were some fun things inside the doors, it was mostly just offices.  I felt a bit bad for having deflated the dream a bit, but this argument that we’re going to learn Python because it’s what Google uses still carries weight with these kids.

The second key marketing attribute I have made sure to mention and remind them of several times was that I don’t know Python myself.

There’s a psychology to be aware of that I’ve seen before–kids don’t want to compete with Dad once they move into their teens.  They want to win on their own terms, and if Dad seems to far ahead on something, that something is a lot less interesting.  Knowing Dad is a programmer, I initially felt some push back over whether the kids would want to learn programming or not.  But telling them I didn’t know Python and would look to them to teach me about it had the desired effect.  They liked that a lot.

How has it gone?

It’s early days yet, but I have been impressed.  First, I had only assigned this task to my son, but my daughter jumped in almost immediately of her own volition.  Second, they’re chewing through the basics at a pretty good clip and without a lot of help.  Their code seems pretty clean and well structured.  They’re at the stage of basic control flows and seem to get it.  Lastly, without any prompting from me, they’ve naturally taken to using the Internet as any developer would to help answer their questions as they come up by cruising forums, StackOverflow, and a variety of other resources.

I don’t know yet whether my kids will be great developers or not.  I am from the camp that thinks software developers are born and not made.  I have seen too many cases of inexperienced brilliant developers with little or no formal education coding circles around developers with computer science degrees from MIT, Stanford, and other top schools.  Those that have the spark can manifest it at an early stage and grow rapidly from there.  As every father would, I hope my kids can be stars at what their father loves, but at the same time I want them to choose their own way.

Meanwhile, expose your kids to a summer of programming just so you both can see how they take to it.

Posted in software development | 4 Comments »

The 7 Kinds of Software Developer Wushu

Posted by Bob Warfield on May 5, 2011

James Governor got me thinking along these lines by asking how to segment developers.  He asked whether the web “killed” the professional developer, or at the very least radically reshaped the segments.  I don’t know about all that, in fact I’m pretty skeptical.  But what I do know is that the way James talked about developers didn’t really resonate with me at all.  I’ve been managing developers for 27 years now, including a couple of stints that have involved selling tools to developers (via Borland and my Integrity QA startup, then at Rational/Pure Atria), and I just don’t think of them as “hobbyists”, “enterprise timeservers”, or any of the other possibilities suggested.  Likewise, while I found Coté’s alternative niches vaguely entertaining, they didn’t fit either in terms of providing me a unified field theory of how to think about developers.  Part of the problem is in not defining what the segmentation is for.  When I hear “segmentation”, I think about mapping out a plan to go sell something to an audience.

Putting all that aside, what really was more interesting to me was thinking about how to dimensionalize the skills of developers.  There are a number of very development-centric skills that I have seen that describe what developers are capable of in terms of development.  We could add a bunch of the usual more HR-centric qualities (works and plays well with others, yada, yada), but let’s keep to being development centric.

What then are the 7 Kinds of Developer Wushu?

1. Hackers

I’ll start with the purest expression of development Wushu.  The Hacker grinds out code.  Uber Hackers practically exude it from their pores.  I had the pleasure of working with Rob Barnaby, the creator of the original Wordstar word processor for one gig.  Rob was the consummate hacker.  He could directly type code in as fast as a touch typist could transcribe and in fact, it often seemed like the keyboard was preventing his expression of code from proceeding as fast as his mind could create.  Watching Rob in action convinced me once and for all that an editor had to be fully operable without taking one’s hands from the home keys to facilitate this kind of bond between man and machine at the highest possible bandwidths.

Hacking is distinct from the other forms of Developer Wushu, as we will see.  As an aside, “hacking” used to have a very bad connotation, and maybe it still does in some quarters.  At one time it meant someone who haphazardly coded, beating their way through the process through sheer trial and error brute force.  It was the antithesis of the elegance so many developers worship.  When I use the term “Hacker”, I mean it in a good way!

FWIW, I rate myself a “5” on the 1 to 10 scale of hacking.  I grind out code pretty well, but if I’m productive, it is more because some of the other Wushus have allowed me to write less code.

2. Language Polyglots

Did you read “Godel, Escher, and Bach?”  Did you really understand what it all meant?  Did you glide through that book effortlessly, constantly in agreement, and finding it a sheer joy?  Or was it one of those books you see that smart people all claim to have read and understood, but that was sheer drudgery for you?  If you’re in the former category, you may be a Language Polyglot.  For you, the ability to execute a language, to be a Turing Machine, is the highest accomplishment of the computer.  It’s what makes it our only Universal Machine, at least until somebody figures out nanotech replicators, which will have to be computers in large part anyway.  My first product, Quattro Pro, contained no less than 18 specialized interpreters that implemented various domain specific languages to accomplish different deeds.  These little interpreters made Quattro Pro easier to write, faster, and more flexible than the competition.  In the end of the day, all things computer wind up being lanuages.  Adobe proved that by making printers into languages in the form of Postscript.

The Language Polyglot makes every problem into a language of some sort.  These folks worship Lisp (first language I learned to program in, yes, I’m a Language Polyglot).  More recently, they create tools like Ruby on Rails.  Ruby, the language, by itself is interesting.  Rails, a framework on its own, is another framework.  But somehow the marriage of the two is magic.  It takes a Language Polyglot to figure out that sort of thing.  Good ones are responsible for all things Meta, which is to say imbuing a software program with the ability to change and take on some of the universal character that makes the computer a unique machine among machines.

I will somewhat egotistically give myself a “10” as a Language Polyglot.  It’s what I do best.

3. Algorithm Mentats

Ah, the Mentats of Dune.  What a compelling image.

Does your software need to be fast?  Does it need to scale?  If so, you’d better have some Algorithm Mentats.  These people uniquely understand how to combine algorithms and data structures to make a software program fly.  There are lots of sub-specialties.  Database algorithms, parallel and distributed computing, graphics, and others to name a few.

A good Algorithm Mentat is not just good at creating algorithms, these folks are often the most familiar with the literature in their areas of specialization.  Computer Science, as a discipline, is largely about Algorithms and Languages, with some Architecture in the sense I will describe shortly thrown in.

I will charitably rate myself an “8” as an Algorithm Mentat.  I don’t love it enough to do better, not like I do Languages and UX.

4. UX Wizards

If some poor user actually has to understand and hopefully love your software, your success depends on the quality of your User Experience (UX).  This area is poorly understood, frequently abused, and much talked about.  Everyone is a consumer of UX and everyone therefore considers themselves expert at UX.  Most of them are wrong.  Some view UX as a Design problem.  It’s not really, although Design helps a lot.  Some view it as understanding Workflows, and there are elements of that.  I think about it as a mixed discipline that involves Design, Workflows, Communication, and a deep understanding of what the User is trying to accomplish.

UX is about crafting a medium that communicates in both directions.  Until we had computers, communication was largely one way.  We had writers, composers and musicians, actors, and so forth.  Those folks have a lot in common with UX, but let us not lose sight of the fact that like any medium, UX is specialized.  We don’t expect Mario Puzzo to be a great movie director nor Steven Spielberg to compose a symphony.  They’re masters of a particular medium.  And, it’s a medium that morphs.  Batch had a particular UX, then we had dumb terminals.  PC’s ushered in an era, and then we had GUI.  Today we add Social and Mobile.  What a rich palette for the UX artist to draw from.  It’s all still here, amazingly enough.

I rate myself “9” on UX.  I hold the patent on spreadsheet notebook tabs (originated in Quattro Pro), and would be named on a patent for the right mouse button if we hadn’t felt it was entirely too obvious to patent back in the day.  We did that first and I remember the Microsoft Product Managers where lined up in the aisles taking notes like crazy when we first demoed Quattro Pro at Comdex.  Pretty soon Excel had these features too, LOL!

5. Architecture Builders

Architecture Builders are masters of arcs and circles.  They know what to put in the boxes and how to connect them for best results.  They think in layers, abstractions, and interfaces.  Refactoring is a joy to be embraced each and every time it is called for.  Patterns are their method of expression, as are the various odd notations associated with Object Modelling.  All large products need Architectural Builders, lest they be poorly architected and collapse under their own weight.  A good Architect can create a product that allows more people to work on it longer, which can be a decided competitive advantage.  Bad architecture results in constant rewriting with the difficulty of finishing increasing almost exponentially with each new release.  Architecture Builders are masters of managing complexity and hiding it where its mischief can be minimized.

I’ve done architectures for software that’s stayed fresh without need of rewrite for many generations, so I’ll call myself a “7” on this type of Wushu.

6. Process Plotters

What do you call that developer that has a million little scripting tools that make them awesomely productive?  They seldom have to create much as they’re forever transforming or improving using tools and processes.  These are Force Multipliers not to be underestimated.  Whether your Process Plotters are focused on the scripting and tools side or whether they’re focused on Agile Programming or whatever other methodology is the tool of choice.  They know when you have too much process and it is interfering with productivity.  They know when you have too little, and it interferes with quality and ultimately, productivity.  With the right tools, they are the consummate DevOps gurus.  They are consultants and managers who set forth the right campaign to accomplish your goals in a timely way.

While many of the processes and tools of development are useful in other disciplines, there has been little evidence the converse is true.  Assembly lines, Six Sigma Black Belts, and the like have not made much impression on the world of software.  It is for that reason that I call Process Plotting one of the 7 Wushus of Development.

I do okay with process and was practicing a variation of Agile Programming before the movement even had a name.  There are papers written about the productivity and processes used by my Quattro Pro team by a Bell Labs PhD named James Coplien.  They serve as some of the earliest working documents for the Agile movement.  Based on that, I put myself down as a “7” on process.

7. Black Boxers

This one is a curious trait, but I have seen it in action too many times not to be certain it exists as a powerful skill.   Black Boxers know how to deal with Black Boxes.  They’re the best debuggers, the best at going into code they didn’t write and understanding it.  There are different kinds of Black Boxers.  Some are ideal QA experts.  They formulate tests that are effective in mapping out the unknown territory associated with Black Box testing.  Some are very low-level.  One of my startups involved very sophisticated automated software testing tools.  We had frequent “blue screens of death” as our software had to do a lot of undocumented and unsupported unnatural acts to accomplish its job.  One of our team was an awesome Black Boxer.  He had a hardware debugger, which was a card with a button that could stop the machine and let him poke around inside what was left.  From that, he could usually figure out the source of our BSD and tell us how to fix it.

Incidentally, the very best Black Boxers hack security and break copy protection schemes.

While I have done Black Box reverse engineering, and managed to derive the Lotus 123 file format for Quattro without disassembling any of the software code in 123, I don’t rate myself very high on the Black Boxer scale.  Call it a “4”.

Conclusion

There are at least 7 Kinds of Developer Wushu.  If there are more you can think of, please comment.  It should make for a spirited discussion.  Any developer has strengths and weaknesses along all of these dimensions, though I’ve never met a developer that was a star in every category.  It takes all kinds to round out a team, so it may be helpful for teams to take inventory of the Developer Wushu expertise of their members.  It can shine a light on strengths and weaknesses and inform how you hire and grow the team moving forward.  It may also be helpful when interviewing new developers to think of questions and discussion topics that focus in each of these areas.  Get your developers who excel in a particular art to focus on questions about that art.  You’ll pretty quickly understand what your applicant is capable of and what will be challenging for them.

Posted in software development, strategy, user interface | 1 Comment »

Those Special Customers Developers Love (Well They Should Love Them!)

Posted by Bob Warfield on March 3, 2011

Do you have any special customers that your developers hate?

These are the customers that can mysteriously break your products over and over again, even though perhaps thousands of others report no problems.

How does this work?

First, understand the psychology of bugs.  Developers don’t consciously create bugs, they come about as errors of omission, misunderstanding, distraction, and incomplete thinking.  Sometimes they’re a result of interactions between complex connected systems that the Developer does not understand or did not foresee.  Most Developers are pretty conscientious about not wanting customers to see bugs, and about getting them fixed quickly.  At my last startup, the Developers were part of the Customer Service crew, which gave them an even keener sense of the customer’s perspective.  Believe me, they wanted their bugs to stop hurting these customers!  BTW, I use that language of “bugs hurting customers” on purpose, because that’s what it feels like to Developers when they get to experience the customer’s pain firsthand.  I highly recommend it!

Yet, we still have bugs.

Second, consider how it all looks to the customer.  The first thing you have to do before you can put Developers on the phone is to get them to quit taking bugs personally and assuming the customer is wrong.  The customer reports a problem, and the immediate assumption is it is the customer’s fault somehow.  At least that’s how it can feel to your customers.  In reality, the Developer doesn’t literally think of finding fault, but they know the customer is doing something different, something they didn’t think of, and they have to get to the bottom of that as soon as possible.  In the worst case, it feels like a witch hunt to your customers when it shouldn’t.  If customers understood why the questions were being asked and why were they asked in that certain special Developer bone headed way, they would understand more.

Getting back to those special customers, they are the ones that do things differently than the vast majority, for whatever reason.  For example, if I talk to a customer that works in IT, I always take a mental deep breath.  These are the sorts of folks that will customize their browser’s security levels, erect additional firewalls, and do almost anything else to really customize their machines to work the way they want them to.  The vast unwashed are going to run their machines pretty much as they come out of the box.  So, the IT guys see some bugs that the vast unwashed don’t, simply because their configurations are different.

If I’m in a crowd with my wife, trying to find seats, I always follow her.  She’s left-handed and she will make different decisions than the vast unwashed, who are largely right-handed.  We will magically wind up getting to a shorter line or finding the better seats that are still available.  If you know a left-handed person, try following them.  It isn’t just a matter of picking left instead of right.  They perceive all of the cues around them just a little bit differently when making their decisions.

Look for people with different hardware.  They’re travelling the less traveled road.  They will find things your mainstream may not.

I have known dyslexic people who did the most amazing things with software.  I have seen problems uncovered through random behavior.  To a certain extent, I have also seen concentrations of bugs as indicating not just that an area of a product is buggy, but that it has poor User Experience.  Why?  Because areas that have poor User Experience cause people to do all sorts of crazy things as they try to guess at how to work the feature.  Hence it flushes out the bugs.  Always consider UX as a possible source of bugs!  And while you’re tracking these bug concentrations, recognize that unnatural locuses of bugginess are either indicators of Bad UX, Bad Architecture, Bad Developer, or something really really hard that you’d better invest more systematic testing in.  Let’s call these “Areas of Special Interest.”

I unwittingly became one of those “Special Customers” for KISSInsights during the last week (cool service I will have more to say about in a later post).  I had a problem with my account they kept trying to fix and couldn’t.  I escalated all the way to the CEO.  Not only did the problem not get fixed, but problems like making me a premium customer for a month for free were apparently being broken.  Both sides were becoming increasingly frustrated.  Then we discovered the real issue–I had two accounts.  They were fixing the older one and I was viewing the newer one.  DOH!

So what’s the moral?

1. Embrace your special customers.  Reward them.  They are like gold because they’re finding bugs that others haven’t found.

2. Seek out people who experience the world differently when using software.  I don’t know if you can go to the extent of trying to make sure your testers include South Paws and Dyslexics, but OTOH, maybe it’s a good idea.

3. Keep an eye on bug concentrations as a potential early indicator of Bad UX, Bad Architecture, or an Area of Special Interest.

4. Make sure everyone involved recognizes that positives that come of an effective quality process.  Never focus on blame.  Reward progress in discovery, correction, and avoidance.

Posted in customer service, software development, user interface | Leave a Comment »

Scoble Discovers Developers are Schizo About New Platforms

Posted by Bob Warfield on February 12, 2011

I just listened to Scoble’s bar interview of @longview (Nick Long) and @renatto (Paul Robinett), two Dreamworks developers who are building a mobile app of their own.  They’re talking about the Mobile World, and there are some great sound bites coming from the interview.  BTW, the Cinchcast tool he used to do the interview was pretty cool.

These developers conclude Nokia-Apple are “screwed”, Android is the cutting edge, yada, yada.

Some key passages and ideas I’ve paraphrased: 

-  The constant refrain: “No one is developing apps for X”.

-  It’s costly to learn a new platform.  Android has Java.  If you know Java and have to learn Objective-C that’s hard and vice versa.  You have to hire a new programmer.

-  It’ll be hard for developers to straddle 2 platforms and 3 is impossible.  How can there ever be a #3 of any consequence?

-  You have to pay us up front enough so it wouldn’t matter if anyone bought the platform.  Because they can’t guarantee the distribution.

 – Cool is about openness, not about closed.  The big momentum is with Open on Android. 

-  The Cool Kids want to be on the cutting edge, but that’s slowing down a little bit for Apple.

-  When somebody builds the uber cool app on Android first, that shift away from Apple will be here.

-  Scoble’s advice to Microsoft, get rid of Windows and go XBox.  They may have been too long in the bar at this point!

-  What if the Apple store is full of hundreds of thousands of apps, and you’re lost in that sea of apps.  How about a marketing decision to launch on Google first so you stand out?

Takeaways for Once and Future Platform Kings

I am a developer and have worked with developers for my entire career in a variety of different markets.  I’ve also spent a lot of time doing the “impedance match” between marketing/sales and developers, and formulating winning product strategies in new markets.  Let me tell you it is an interesting challenge to juggle all of those balls just because of how the various players think and are motivated.  It’s worth getting behind the sound bites of this interview and understanding the developer, marketer, and strategic implications for companies who want to be Platform Kings.

Let’s start with the marketing / strategic perspective for the mobile world.  It’s all about the apps you have on phones, and Scoble gets this in a prior blog post very eloquently:

Nothing matters in this world more than apps. Write that on your forehead. Write that on the mirror on your bathroom wall. Write that on your car windshield. Whatever it will take so you remember it.

HP execs know this. Google’s execs know this. Everyone in Silicon Valley knows this.

Apps are the ONLY thing that matters now.

Why? Because when a customer, whether in Cape Town or San Francisco or Tel Aviv walks into a store to buy a smartphone they will NOT want to feel stupid.

What makes you feel stupid when buying a Smartphone? Buying one that doesn’t have the apps your friends are taunting you with.

Apps need a platform, so if you’re going anywhere in these markets, you’d better have one that will attract the right apps.  Unfortunately, it’s getting late to try to establish a new platform.  Why?  Because the developers are in control of whether or not apps will appear on your platform, and you will have a hard time attracting them.  Many companies are woefully unprepared for the idea that if they’re in the platform business, they actually have two sets of customers.  First are the people that buy the phones.  Those are the obvious customers, the ones marketers at companies like Nokia have built their entire professional careers learning how to deal with.  Second are the developers that bring the apps.  These are the customers many of these companies have no earthly idea how to deal with, yet they are the gate keepers for the apps.

So how do we think about developers as customers and how do we get them to adopt our platforms?

There are a very limited number of opportunities to attract developers because they are so schizoid about new platforms.  On the one hand, developers really hate having their expert status reset to beginner while they learn a new platform.  They may protest that its cool, they’re always learning new things, they love to learn, yada, yada, but they really hate the nuts and bolts of the learning.  This is a corollary of what happens when you give a developer somebody else’s code to maintain.  The code may have come from their most revered uber geek hero, but if they don’t know that’s the source, their first words on briefly looking over the code will be, “This code is shit–we have to rewrite it.”  Welcome to the real source of NIH.

So what will get a developer to voluntarily surrender his Uber Geek status for the time it takes to learn a new platform? 

There really are only two things.  Either that platform is so hot and sexy they will lose their Uber Geek status anyway if they don’t learn it, or the platform is so successful that profit motive dictates it must be supported.  Are you beginning to see the problem with introducing a new platform?  It hasn’t been around long enough for profit motive to kick in, so you have to make sure it isn’t just a little bit cool, it has to be ultimately way-over-the-top-super-duper-no-kidding-insanely-friggin-UBER COOL. 

This has been Steve Jobs genius.  He has managed to create such platforms multiple times in his career.  That’s no small accomplishment, and I don’t know whether we’ll ever see it again in our lifetimes from someone else.  The Apple II.  The Macintosh.  The iPod.  The iPhone. The iPad.  Dang Steve, that’s gettin’ jiggy with it.

When the corpocracy wants to roll out a new platform, that’s what they’re faced with.  There are a limited number of things the Corpocracy (my term for that faceless Big Business  thing the lady in the Apple 1984 commercial threw her hammer at) can do about this.  The best one is to make their platform absolutely compatible with some other platform so that developers don’t have a long learning curve.  We’ve seen a lot of those kinds of things going on in the industry.  It’s one reason why some things just won’t die.  Sometimes it works to give away the platform, and make it open.  It’s helpful if in the process you can make it as compatible as possible with something developers know.  Enter Android with a lot of Java inside.

That’s about it.  If you can’t make your platform fit those molds, you’re probably not going to be a Platform King.  Not enough developers will learn your stuff no matter how great it is because it was either not sexy enough or didn’t already have a big enough installed base.  The latter, BTW, is why Gordon Moore says it is better to go from app to platform than vice versa.  At least you’ll have the installed base and ecosystem of the app users to drag developers onto the platform.  They come to make the app users happy if there is enough motivation in that.  But this does not necessarily a huge platform success make.  This is the problem Salesforce struggles with in Force.com. 

Getting back to the Scoble interview, are these developers right, is Nokia screwed?  And whither the other mobile platforms?

Because developers have this big speed bump in their willingness to learn new platforms, they will tend to create sub-cultures that don’t communicate very much.  Right now we have a huge division between the Unix + Open Source world and the Windows + .NET world, for example.  Only a very small number of developers can claim to be Uber in both camps.  The vast majority know very little about the camp they are not Uber in, and often hold it in extreme disdain as a result.  But that does not mean they’re right.  It only means you have to understand where those boundaries are and what they mean to the success or failure of your product strategy. 

Translation:  don’t ask a set of developers about whether a platform they will have to learn will succeed unless all you care about is whether they perceive it as cool.  They don’t know much else.  It’s all religion to them.  Despite the fact they are engineers, very few will look at this sort of thing objectively.

In fact, Microsoft may have the only viable alternative platform opportunity that will work for mobile after Apple and Android.  Why?

Because there is a large community of developers who don’t have to relearn their tools.  To the extent the phone platform can minimize relearning and appeal to that group, they’re in.  It would be ideal if Microsoft can also create the commercial reality of a big enough market.  In fact, that will be a requirement in the long run.  But in the short run, Microsoft needs to stimulate some innovative hit apps on the platform that show life and prime the pump.  Steve Ballmer, if you’re listening, that’s the most valuable thing the billions you spend on R&D could purchase.  Bring 3 to 6 hip, really cool, must have apps to your platform so your customers don’t have to feel stupid (ala Scoble and mobile phone apps) and you have a chance.  While you’re waiting for that lightning to strike, at least make sure you have apps that give great experiences for all the key hip web properties out there, such as Facebook and Twitter.  And with whatever cash you have left, make sure your phone platform is minimizing the speed bump for .NET, Windows, and XBox developers to put apps on your phones.

It’s not too late, but it is far from early.

Related Articles

This community of developers who know Microsoft platforms is one of the under-served markets I alluded to in my article saying that Nokia-Microsoft are filling the last of the 3 winning market strategies.

Posted in platforms, software development, strategy | 5 Comments »

 
Follow

Get every new post delivered to your Inbox.

Join 325 other followers

%d bloggers like this: