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

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:

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.

Gaining the Wisdom of Crowds in a Bootstrapped SaaS Company

When 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.

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

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.

Have Your Kids Tried Programming?

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.

The 7 Kinds of Software Developer Wushu

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.

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

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.

Scoble Discovers Developers are Schizo About New Platforms

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.

What Will GPU-On-The-CPU Mean for Analytics?

This week’s InfoBoom-sponsored post is all about Intel’s announcement that it would be shipping chips that include an integrated graphics processor (GPU) on the same chip as the CPU under their so-called Sandybridge architecture.  A lot of folks probably ignored the announcement thinking it meant better video games for their kids and perhaps their laptops, but there is a more interesting way to look at the impact of such architectures for business.

GPU’s are not just for graphics, as it turns out.  They’re extremely powerful supercomputers in their own right, with vector processing and other capabilities that are well on par with the Cray supercomputers that ruled during my college computer science days.  The Cray X-MP ran 941 Megaflops back in the day and was considered strategic weapons grade computing.  The latest Nvidia CUDA GPU’s weigh in at 1 Teraflop or better, so are fully capable of keeping up with the old Cray.  What happens when that kind of power is available on every CPU?  A whole lot of power, and a whole lot of change.

Check out my post over on InfoBoom to find out!

Database.com, nice name, shame about the platform (Huh?)

Matt McAdams writes an interesting guest post for Phil Wainewright’s ZDNet blog, Software as Services.  I knew when I read the snarky title, “Database.com, nice name, shame about the platform,” I had to check it out.

The key issue McAdams seems to have with Database.com (aside from the fact his own company’s vision of PaaS is much different, more in a minute on that) is latency. He contends that if you separate the database from the application layer, you’re facing many more round trips between the application and the database.  Given the long latency of such trips, your application’s performance may degrade until your app “will run at perhaps one tenth the speed (that is, page loads will take ten times longer) than a web app whose code and data are colocated.”  McAdams calls this a non-starter.

If using Database.com or similar database-in-the-cloud services results in a 10x slower app, then McAdams is right, but there are already ample existence proofs that this need not be the case.  There are also some other interesting considerations that may make it not the case for particular database-in-the-cloud services (hereafter DaaS to avoid all that typing!).

Let’s start with the latter.  Salesforce’s offering is, of course, done from their data centers.  From that standpoint, you’re going to pay whatever the datacenter-to-datacenter latency is to access it if your application logic is in some other Cloud, such as Amazon.  That’s a bit of a setback, to be sure.  But what if your DaaS provider is in your Cloud?  I bring this up because some are.  Of course some Clouds, such as Amazon offer DaaS services of various kinds.  In addition, it’s worth looking at whether your DaaS vendor hosts from their own datacenter, or from a publicly accessible Cloud like Amazon.  I know from having talked to ClearDB‘s CEO, Cashton Coleman, that their service is in the Amazon Cloud. 

This is an important issue when you’re buying your application infrastructure as a service rather than having it hosted in your own datacenter.  It also creates a network effect for Clouds, which is something I’ve had on my mind for a long time and written about before as being a tremendous advantage for Cloud market leaders like Amazon.  These network effects will be an increasing issue for PaaS vendors of all kinds, and one that bears looking at if you’re considering a PaaS.  The next time you are contemplating using some web service as infrastructure, no matter what it may be, you need to look into where it’s hosted and consider whether it makes sense to prefer a vendor who is colocated in the same Cloud as your own applications and data.  Consider for example even simple things like getting backups of your data or bulk loading.  When you have a service in the same Cloud, for example like ClearDB, it becomes that much cheaper and easier.

Okay, so latency can be managed by being in the same Cloud.  In this case, Database.com is not in the same Cloud, so what’s next?  Before leaving the latency issue, if I were calling the shots at Salesforce, I’d think about building a very high bandwidth pipe with lower latency into the Amazon Cloud.  This has been done before and is an interesting strategy for maximizing an affinity with a particular vendor.  For example, I wrote some time ago about Joyent’s high speed connection to Facebook.

Getting back to how to deal with latency, why not write apps that don’t need all those round trips?  It helps to put together some kind of round-trip minimization in any event, even to make your own datacenter more efficient.  There are architectures that are specifically predicated on this sort of thing, and I’m a big believer one whose ultimate incarnation I’ve taken to calling “Fat SaaS“.  A pure Fat SaaS application minimizes its dependency on the Cloud and moves as much processing as possible into the client.  Ideally, the Cloud winds up being just a data repository (that’s what Database.com and ClearDB are) along with some real-time messaging capabilities to facilitate cross-client communication.  The technology is available today to build SaaS applications using Fat SaaS.  There are multiple DaaS offerings to serve as the data stores and many of them are capable of serious scalability while they’re at it.  There are certainly messaging services of various kinds available.  And lastly, there is technology available for the client, such as the Adobe AIR ecosystem.  It’s amazing what can be done with such a simple collection of components:  Rich UX, very fast response, and all the advantages of SaaS.  The fast response is courtesy of not being bound to the datastore for each and every transaction since you have capabilities like SQLite.  Once you get used to the idea, it’s quite liberating, in fact. 

Surprisingly, many have seen this model, though they may not have thought much about it.  As McAdams points out, “Database.com will do better with developers of mobile apps, which contain the user interface and the app code in the same bundle.”  Yup, many mobile apps are Fat SaaS.  The architecture becomes a lot more interesting when you start thinking about how popular apps are on mobile versus apps in browsers and why.  This also points the way towards some of the types of apps that are particularly well suited to Fat SaaS:  complex games, rich content creation applications, and a variety of things where the simple fill-in-the-form-and-do-the-workflow metaphor just isn’t right would do well with Fat SaaS.  There are also advantages for cost and scaling, where Fat SaaS it works great so long as your application’s usage patterns are largely hub and spoke.  What I mean by that is that there isn’t a lot of need to do cross-client processing in bulk.  Sure, a record may pass through several user’s clients on its journey, but you don’t have to do complex business logic that involves looking at thousands of those records across many clients very often.  When you’re doing hub-and-spoke, the client hardware is free in Fat SaaS.  It may be cheap in an elastic Cloud, but it’s hard to beat free!

The situation for aggregate processing looks worse for Fat SaaS, but it isn’t necessarily black and white.  Very often we find systems whose transaction processing behavior is a lot different than what we want for Business Intelligence.  Hence we wind up optimizing two different datastores–one the transaction processing store, the other the BI Data Mart.  The same approach can work here.

One last comment about McAdams’ post.  He concludes with a pitch for his company’s products:

The bigger criticism applies to all DaaS offerings, and it’s this: they’re solving the wrong problem. Making databases more accessible to programmers who already know how to use databases is nice and all, but how about making databases more accessible to business users? 

Why not let non-programmers build web apps without writing code? To do this, Database.com would have to include things that Salesforce.com discloses explicitly are not part of the platform: page layout tools, reports, dashboards, and so on. These can be built with Force.com, but using Force.com requires programming knowledge.

It seems to me the more innovative cloud DB players are the companies providing a cloud database with a complete, integrated app development platform that requires no coding, only point-and-click configuration. These platforms, like TrackVia (the author’s company) or Intuit’s QuickBase, are doing more to change how cloud apps get built than the better-known DaaS vendors are.

As I’ve said in previous posts, I’m not a fan of the “anyone can program with our special point and click application” ideas.  The demos look whizzy, but this is really not innovation, and the tools are pretty limited in how far they’ll take you.  We’ve similar tools for a long time under earlier guises such as 4GL or later guises such as the PC desktop databases like dBase or Microsoft Access.  We’ve seen it in languages with UI Builders like Visual Basic or Adobe Flex.  I have to say, we’ve seen a lot more point and click programmers than we have seen DaaS.  In addition, the idea that the problem a DaaS solves is one that is already solved, in other words that they’re trying to make understanding databases easier for programmers who already understand databases is also pretty far off base (and surprisingly given McAdams’ past in DBA software).

DaaS is all about two things that many developers are usually not so good at:  Scaling and Automating Operations.  There is a lot of work required for either and it’s work that the majority of developers who may have a ton of domain expertise for their app area typically are short on.

Forget SaaS vs On-Prem, Here are 8 Application Styles to Consider

The EI discussion about Microsoft’s poor handling of Silverlight brought out the different viewpoints swinging. The “RIA was never a good idea” camp was in full force as was the “this confirms everything about HTML5″ and the “Flash is on the same train as Silverlight” camps.

I don’t see these developments nor the evolution of Flash and its strategy as a confirmation that RIA is a bad idea at all, that Flash, at least is going away, or that HTML5 is the answer to all the world’s problems. Whether your RIA consists of Flash widgets embedded in HTML (my favorite RIA strategy for web apps) or AJAX HTML, RIA’s are essential for many kinds of app and HTML5 is years from being a first class choice for that work. There has been too much tendency to conflate every conceivable nuanced app type as one single web app that is best served by one single technology. That way lies crappy UX, high dev costs, and longer lead times to market.

There are new categories of application coming along all the time, and the vast majority haven’t really stopped to think about the evolution of application types and their ecosystems. Let’s forget the ongoing dogfight about Clouds, elasticity, SaaS, and Multitenant for a minute, and have a look at factoring software along some other dimensions.

I see 8 different application design centers, and you choice of which design center to use and which tools and platforms to go with it can matter quite a lot.

#1 Plain Old Desktop (POD) Apps

 

I always loved the term “POTS” = Plain Old Telephone Service, so I’ll borrow the idea for PODs, which are “plain old desktop” apps. This is still a huge business including MS Office and much of what Adobe sells by way of content creation tools. It’s also huge for complex games, though the platform is sufficiently separate we will want a separate category for console games which I won’t get into here.

Typical platforms include the desktop OS–Windows or Mac, and the traditional developer languages such as C# and Java. To deal with the pains of PODs, your app needs to be something that requires too much horsepower for the other architectures as well as a rich User Experience (UX).

#2 Server Software

A command line is a UX, and for some purposes, its even a good UX, so we will count this as an “app” category. It’s like the PODS except there are more languages and OS’s to consider. On the OS side we have Unix in commanding lead (in all of its many flavors) with Windows distantly to the rear. From the langauge side, the world has probably spent more time and effort building an explosion of different evolutionary language branches here than anywhere else. I can’t even begin to list them all, but suffice it to say that when in doubt, you could do a lot worse than to bet on it being a language for server side development. Certainly we can count on Java, C#, and Ruby on Rails as all being in this category.

Some languages are a little bit muddled as to whether they’re server or client languages. PHP is a little of both that mostly errs towards client in my book, but you wouldn’t think of it for server-less apps (if no client is a headless app, are those tail-less apps?). For this app category, we have no UX but a command line, so I’m not sure we’d pick PHP. Put it in the category of helping out Plain old web apps and RIA’s.

#3 Client Server

 

The Client Server model is tried and true and still a huge business, especially for business software. I don’t know how much genuinely new Client Server software is being built anymore. The Cloud and SaaS are a much better model for most applications. Think of Client Server as the somewhat unwieldy combination of a POD and Server Software. Most of what I’ve said for those other styles carries to this one when combined appropriately.

The combination of Desktop, Server, and Client Server are the oldest app styles that are still vigorous today. We’ll call mainframe software a flavor of Server or Client Server. All three are under siege or revolution. Desktop and Client Server are clearly under siege as various web technologies via to take their place. Server is under the dual revolutions of Cloud and Multitenant SaaS. There have been many minor infrastructure revolutions as well as the world transitions from SOAP to REST or decides POJOs (Plain Old Java Objects) make more sense than deep J2EE architectures (let alone CORBA style, Service Bus, and all the rest of that melee).

#4 Plain Old Web (POW) Apps

 

No fancy RIA tech, AJAX or otherwise. This is the modern equivalent of the half duplex 3270 green screen. But, it is lowest common denominator friendly. That means everyone can access it, but the experience may not be great. Save it for times when coverage is more important than satisfaction. Simple UI you just have to get through once in a blue moon is perfect.

The platforms? Who cares. POW apps should use such vanilla HTML they never notice. Tools and languages? Vanilla HTML and whatever your favorite dev tools are for that.

If we add POW apps to the other 3, you really do have the majority of revenue and installed base at present. What follows are newer models that are catching on to a greater or lesser degree. I should add that I see POW as stable and non-controversial, Server as growing but full of revolution, and the other two (Desktop and Client Server) as in decline to greater or lesser degrees.

#5 Rich Internet Apps

RIA’s are web apps that live in the browser but provide a nicer UX than a POW can offer. AJAX, Flash, or Silverlight have to be there for it to count. HTML5 supports this poorly at present, but everyone knows it wants to go here over time.

The “Rich” part of a RIA can boil down to lots of things, so let’s call some out so they don’t go unnoticed. Yes, we will started with Rich User Experience. But what does that mean?

Well, instead of posting a form, you have enough expressiveness that you can actually create new kinds of widgets and respond to user inputs with much more fluidity. We also have rich media, including sound and video to play with, as well as sophisticated ways of manipulating bitmaps to produce animations and art.

However, depending on the RIA platform, you may also experience other “riches.” Flash player delivers a very high performance virtual machine. It isn’t Java-class, but it is darned good. Recently, browser makers have decided performance matters for HTML as well, but it isn’t clear they’re keeping up with Flash. If your RIA has to do some kind of crunching, Flash may help it along. It isn’t just about the high performance VM, there is also the support for more elaborate data structures, which are also helpful where more horsepower is needed.

I have been fascinated by an idea I came up with called “Fat SaaS”.  We live in the multicore era where computers no longer get faster in raw terms, they just get more cores.  At the same time, it is very hard to write software that takes advantage of all those cores.  On the server side, the world has been evolving towards dealing with the issues need to scale large problems onto grids of commodity PC’s as a way to deal with the realities and economics of the multicore era.  On the client side, it seems that machines accrue more and more unused capacity without delivering good reasons for customers to upgrade as often as they used to.

Fat SaaS is an architecture that pushes as much down onto the client as possible and leaves the server farm largely for data storage.  In an extreme Fat SaaS case one could imagine that the clients become the business logic processing grid.  The goal is to tap into the computing resources that lie fallow there, and there are a lot of them.  Most organizations will have more client cores than server cores.

But we digress…

The last bit of “riches” I want to touch on is device independence.  We largely got there for server software, and write once run anywhere is a beautiful thing.  Other than Flash, we are nowhere in sight of it for the client.  This is a sad and embarrassing tale for our industry, and one that developers too often try to power their way through by just writing more code.  Browser incompatibilities are insidious.  As I write this article in WordPress, I’m trying to use their rich text editor.  It runs with varying degrees of success and a little differently on each browser.  Lately, it mostly fails on IE, meaning the UX has not been kept up to snuff.  If they would simply invoke Flash to do one single thing, manage the text editing, they could deliver an identical experience on every browser, not to mention many mobile devices too, though on Apple’s devices they would need an app to do that.

This browser dependence is absolutely the bane of HTML based RIA’s, and I can see no reason why the problems won’t continue with HTML5.  As vendors race to see who can deliver better HTML5 support sooner, keep eyes peeled for the incompatibilities to start.  If they do, that’s a sign that the HTML5 dream is not all its cracked up to be, even in the fullness of time.  It will take some new generation and a bunch of restarted browser implementations to get there.  Meanwhile, Flash will have gained another 5 to 10 years lease on life, despite detractors.

#6 Rich Internet Desktop Apps

RIDs!  A RID is a really cool thing.  It is the web era approach to building desktop apps–we build them with web technology.  Amazingly, nobody seems to have noticed that if you need to run disconnected, or if you want to build an app with web technology that does meaningful things on the desktop, Adobe is the last man standing.

Google killed Gears and Silverlight looks more and more deprecated by the day.  HTML5 is still struggling to get to the minimum RIA bar and will be for years.  What’s a poor RID developer to do, but focus on Flash?

RIDs are fascinating apps, and I would argue your nuts to build any new PODs or Client Server when this model would work. In the area of games, there are amazing developments in 3D coming for Flash Player that will also play to this architecture. Lastly, Ialready mentioned “Fat SaaS”, a model which is ideally suited to RIDs.  The RID just gives the Fat SaaS access to local disk and more of the machine’s facilities.  Fat SaaS work can go on whether the client is connected or not, and a connection can wait until the client needs to connect, which reduces the demand on the Cloud Server Farm still further.

#7 Mobile Apps

MAs are closely related to RID’s, and certainly much better known. The non-HTML RIA platforms are excellent for this purpose, and it is no accident MSFT sees this as Silverlight’s future.  HTML5 doesn’t do enough and it will be years before it does to have real apps stand alone with it. iPhone’s default toolset is basically foisting desktop technology on you to build these apps, and I’m skeptical this is as productive, but the stakes are high enough people deal with it.

#8 Mobile Internet Apps

MIAs:  when you want to live in a browser on a mobile device.  Plenty of data suggests that for apps that are not heavily used, users prefer to consume via browser.  This shouldn’t be controversial as it simply makes sense.  The browser makes it much easier to dip in and out of a lot of apps that you probably never use enough to learn really deeply.  MIAs are a different category than RIAs because like the RIA, there are considerations beyond one-size-fits-all HTML.  However, a MIA could be a RIA MIA (LOL) or a simple HTML MIA.  I won’t bother breaking those two out as new app types–we already have 8 and that’s enough.  The reality is the MIA is a placeholder reminder that you have to do something to make your app palatable on a mobile device lest you have a below par UX.

Conclusion

Have you thought about when to use each of these design centers, what the optimal tool sets are for each, and especially how to weave an all-platform strategy with as little work as possible?

Most haven’t.  I see low expertise in out in the world as much of this is new and very few organizations have so much breadth of experience.  Most of the time organizations start with one design center and move chaotically on to others as targets of opportunity present themselves.

We increasingly live in a world where being on one or a few platforms will not be good enough, and we won’t be able to build for all with organically grown “luck” strategies.  Maybe this is a good time to start thinking through these issues in a systematic way for your organization and its products?

Related Articles

Recursivity and RWWeb talking about Fat SaaS.