TL;DR Software Development technology adoption lifecycle is susceptible to the same rules that apply to any other high-tech. Market success is not guaranteed by sheer innovation, technical excellence or even product capabilities - it does require certain qualities, but also favorable market situation & adaptable product marketing (adjusted to cycle stage). In fact, vast majority of technology novelties we so adore (and already consider "The Next Big Thing") will never go beyond geek inner circles.

I've recently finished one of the absolute classics among product development books: "Crossing the Chasm, 3rd Ed." by Geoffrey A. Moore. Book itself is at most average, but the presented concept (of "Chasm") & description of high-tech adoption life-cycle make a lot of sense. Additionally, all this seems very applicable in context of modern software development innovations (like new platforms, programming languages, databases, etc.) - hence the dedicated blog post.

If you want all the details, go straight to the book, I'll try to be as concise & to-the-point as possible.

The Chasm 101

Not all among us approach the industry innovations (new tools, techniques, frameworks, whole platforms) in the same way - one could name few very different groups:

  1. innovators - always looking for novelty, explorers interested in new capabilities brought by the technology itself
  2. early adopters - visionaries, who see a potentially built product rather than a technology, fixed on getting a competitive advantage (breakthrough) due to early adoption
  3. early majority - pragmatists, eager to use a product that is already proven, recognized in the market, has successful deployments in similar scenarios, IF it brings a significant benefit (new capability / advantage) - I call it "the cookie" & I'm sure I wasn't the one who invented the term :)
  4. late majority - conservatists, who hate so-called discontinuous changes (anything different to gradual update of already used/deployed product)
  5. laggards - skeptics; well - they just don't give an f-word, so pike off with the new, shiny toys of yours

Obviously, introducing of the new tech means addressing the needs, concerns & expectations of all these groups, one by one, in a given order. And here we're encountering our core issue - the transition between groups isn't smooth & fluent. Especially between "early adopters" & "early majority" there's a gaping & dreadful CHASM - far harder to cross than it appears at the first glance, a barrier that has already stopped (& will be stopping) uncountable new tech exhibits from reaching their glory (aka mass-market adoption).

Pinning labels

Does it ring a bell already? Seen that, been there? Good. Let's note down some specifics of Software Development professionals (both individuals & organizations) who belong to particular groups first:

  1. If some tech gets 10x more "attention" in digital media then another one, it doesn't mean that it's used 10x more often (in 10x more projects, companies, etc.) - let's face the fact: blogging, twitting, conference or meetup talks - overwhelming majority of these is usually authored by either "innovators" or "early adopters" (we tend to call them "passionate developers"), but these two groups altogether are far less numerous than the remaining ones separately!

  2. Keep in mind the mentality of two larger groups ("early majority" & "late majority") - both are very risk averse:

  • the former one will always ask for references first ("who is using Ionic 2 for a banking mobile app in >10M client market, with Node.js back-end?")
  • while the latter will pretty much instareject anything that requires new skills, introduces new risks or fiddles with existing processes ("sorry, we're using Oracle 11g & PL/SQL for data persistence here only.").
  1. It may be hard to get if you're an innovator itself, but these people DON'T embrace the change just because it's here, just because it's (or appears) slightly better - they need something more tangible to convince them:
  • so-called "burning platform" (situation that forces the change) - e.g. permanent shortage of PL/I developers on the market, unfavorable licensing model, massive tech debt attributed to technology (btw. it's usually bullshit)
  • "new market" opening - e.g. everyone is currently looking for Data Scientists, even if just very few have a notion of how to apply Data Science (in practice) in their enterprise
  • each "negative testimonial" (fuck-up story, breaking changes whine, famous outage postmortem) is an ice-cold shower for any adoption attempts
  1. "Late majority" is considered a group totally uninterested in dealing with under-the-hood details: that means very high platform maturity, not only in terms of development capabilities, but also deployment pipeline, trouble-shooting, monitoring, anything else related to operations. They want a no-brainer, wrapped package, a homing missile, not "something with a potential" that requires an uncertain time & effort investment.

Don't fall in ...

OK, so let's assume that you agree with these observations & acknowledge the existence of "the Chasm". But should we care? Why is it that important?

We tend to forget that world doesn't look like developer evangelists (or other hype junkies) want us to think it does. Majority of super-cool technologies we get bombarded with each day will end as geeky toys used in 2 & 1/2 of some unfinished Open Source Slack clones ... Many of us are really, really convinced that everyone (but them ...) uses only FP languages, that Java has already given way to Clojure, that no-one sane would use anything else than Elm for front-end web project, that not using Docker is so 80s ...

In fact, even keeping in mind the continuously increasing fragmentation of software development tech ecosystem, majority of these new "shining stars" will never get a significant "market share" - due to reasons described in the book & summarised above by myself. Adoption costs, uncertain risks, unclear future roadmaps (especially for OSS), existing, high-inertia codebase, hardly understandable (for many decision-makers) & barely tangible benefits - these all contribute to widening & deepening the Chasm.

DX (Developer Experience)? It loses in confrontation with brutal reality.

Hence my low enthusiasm towards some recent innovations, i.a.:

  • I've already written about (current state of) .NET Core, let's all hope I'm wrong
  • I'm totally in love with Elixir (& BEAM), but chances for its wide adoption are literally ZERO; anyway, I don't really care as the platform has its own, very specific niche & it will survive there (as Erlang did for past 30 years)
  • I believe in Golang, because it seems to perfectly fill the unfilled gap left by C/C++ (already present & aching for at least 5-7 years): fits the same scenarios, fixes some of predecessors' shortcomings, lures with simplicity (of language & ecosystem); It will take some time (3+ years), but Golang seems a pretty safe bet.
  • I believe in TypeScript, because it has taken a safe evolutionary path - by extending ECMAScript with enhancements that already provide tangible benefits, but can be introduced gradually

Pic: © Alyn - DevianArt

Share this post