The NodeJS Innovation Advantage

Thesis: “when building large scale distributed systems, high performance functional programming languages provide the quickest turnaround from idea to concept; however such advantage disappears as we move from concept to production, and the overall time from idea to production across all programming languages is of the same order of magnitude”.

The NodeJS innovation advantage

I posted this diagram, without justification, yesterday evening, in an attempt to gauge the reactions of the community, in twitter. Thank you to all of you that commented. With the experiment done, let me now provide my thesis and hopefully address most of the feedback so far. I intend to make this post fluid and keep updating as the conversation evolves.

Now, let me qualify the thesis. First, this is a thesis applicable to multiple domains, whether that’s a low-level network switch appliance, a http proxy gateway or a web application. As a consequence, this is not a framework comparison, it’s not about Rails vs Django vs Play vs Express vs …. This is not an argument about dynamic vs statically typed programming languages, although that definitely plays a partial role in the thesis.

Mine is a thesis about the complete team productivity by programming language and across the full product life-cycle from inception to retirement. The thesis is purely based on my observations throughout the years. There is not data to back it up, except anecdotal evidence. In summary, mine is a qualitative statement, not a quantitative one.

If the thesis were true, this would mean that teams using high-performance and functional programming languages can iterate more quickly from idea to concept. Such quick turnaround allows a constant validation of ideas in the code. Because it is quickly possible to see the idea running, we can afford to have more ideas. The quicker we are able to iterate between idea and concept, the more we are innovating.

Such quick turnaround has a real trade-off and a false trade-off.

Moving these concepts to production is difficult. Whether it’s Scheme, or Lisp, or Clojure, or JavaScript, it becomes clear that we are “naked”. Except in “safe but useless” languages, such as Haskell, in most “useful but unsafe” programming languages, the developer has to compensate for the dynamic nature of the language. The developer has to provide the strictness, and to a degree perform the job of the compiler. In statically-typed and imperative programming languages, the compile infrastructure helps the developer ensure the correctness of the code. In dynamically-typed and functional programming languages –by the way, yes these are orthogonal concepts but usually associated–, the developer needs to structure code and provide the necessary checks, assertions, unit tests, regressions tests and modular design. The addition of type hinting and type inference does not change this, it only shifts effort between “before concept” and “after concept”.

High-performance functional programming languages trade strictness for innovation potential. Without the additional investment in checks and tests, these systems are not predictable. The time we gained upfront, we pay later for. I’d argue such trade-off is good, and allows quick iteration to find the right idea.

The second trade-off is about tech debt. The time to production is identical across languages, but because the developer in high-performance functional programming languages had to compensate for the lack of compiler infrastructure and runtime guardrails by adding completeness of tests and checks, the system is easier to maintain and has overall a better architecture. This is almost counter intuitive and I think most people don’t think this way because they move too quickly from concept to production, and don’t implement the necessary strictness. There is a tendency in the developer to move quickly from concept to production, and therefore accruing overall technical debt.

Finally, I believe server-side JavaScript and Google V8 provide such high-performance functional programming language, in the skin of an imperative one, and enable this quick turnaround from idea to concept. This possibly one of the key reasons we are seeing such explosion in adoption. I only hope developers start to realize the trade-off they are doing, and that in order to avoid accrual of technical debt, they better invest in checks and tests before they rush into production.

43 Comments

  • January 28, 2012 - 10:10 pm | Permalink

    A critical NodeJS advantage is to allow a quick turnaround from idea to concept, and only then require hardening work. http://t.co/1sXcIuz5

  • January 28, 2012 - 11:41 pm | Permalink

    Exactly right. http://t.co/GQFpL6lt

  • January 28, 2012 - 11:45 pm | Permalink

    This is an interesting point that’s probably true about Node.JS (vs. Java) http://t.co/cIJj9coa /via @jamesgolick

  • January 28, 2012 - 11:47 pm | Permalink

    ericflo: This is an interesting point that’s probably true about Node.JS (vs. Java) http://t.co/StXwSJaj /via @jamesgolick

  • January 28, 2012 - 11:55 pm | Permalink
  • January 29, 2012 - 2:49 am | Permalink

    Say “XYZ is the best” an you’re a troll. Post a graph without axis labels, based on no real data, and it is convincing! http://t.co/u95dwjJn

  • January 29, 2012 - 2:55 am | Permalink

    Say “XYZ is the best” an you’re a troll. Post a graph without axis labels, based on no real data, and it is convincing! http://t.co/StXwSJaj

  • January 29, 2012 - 4:43 am | Permalink

    I’ve lived each one of these paths and completely agree ->The NodeJS Innovation Advantage http://t.co/1HnvrHHk via @zite

  • January 29, 2012 - 7:05 am | Permalink
  • January 29, 2012 - 7:30 am | Permalink
  • January 29, 2012 - 7:41 am | Permalink

    node.js rocks! @nodejs: http://t.co/tRGPJL7O

  • January 29, 2012 - 7:55 am | Permalink

    How many flaws in this diagram? The NodeJS Innovation Advantage http://t.co/XBghPoxc Evangelism is good – but not incorrectness /via @talios

  • January 29, 2012 - 8:53 am | Permalink

    “The Node.js Innovation Advantage” – http://t.co/qg1xOfzq

  • January 29, 2012 - 9:19 am | Permalink

    the node.js innovation advantage – http://t.co/ZE3znPTr v @nodejs

  • January 29, 2012 - 9:30 am | Permalink

    The NodeJS Innovation Advantage http://t.co/GxKbsw1S

    nodejs

  • January 29, 2012 - 12:05 pm | Permalink

    The NodeJS Innovation Advantage http://t.co/PhOXUBgc via @zite

  • January 29, 2012 - 2:00 pm | Permalink

    The NodeJS Innovation Advantage http://t.co/VnLTqOT1 via @zite

  • January 29, 2012 - 3:22 pm | Permalink

    The NodeJS Innovation Advantage http://t.co/Kb4a8mfZ

  • January 29, 2012 - 3:24 pm | Permalink

    The NodeJS Innovation Advantage http://t.co/RdkPGZTg via @zite

  • January 29, 2012 - 4:56 pm | Permalink

    Even on a mature lang, hardening innovative off-the-beaten-path solutions takes as much time – http://t.co/sYtjVXGr

  • January 29, 2012 - 5:01 pm | Permalink

    Even on a mature lang, hardening innovative off-the-beaten-path solutions takes as much time – http://t.co/ASxlPHGx http://t.co/QYmpVNeT

  • January 29, 2012 - 5:48 pm | Permalink

    Making an argument for NodeJS as instrument of innovation (now with text) – http://t.co/1sXcIuz5

  • January 29, 2012 - 5:51 pm | Permalink

    Making an argument for NodeJS as instrument of innovation (now with text) – http://t.co/ASxlPHGx http://t.co/rigrV0dn

  • January 29, 2012 - 11:27 pm | Permalink

    http://t.co/s1oehNyk – The nodejs Innovation Advantage

  • January 30, 2012 - 12:02 am | Permalink

    The Node.js innovation advantage – http://t.co/FKzrmnCq

  • January 30, 2012 - 2:31 am | Permalink

    RT @olympum: Making an argument for NodeJS as instrument of innovation (now with text) – http://t.co/1sXcIuz5

  • January 30, 2012 - 5:50 am | Permalink

    RT @Outsideris: The NodeJS Innovation Advantage http://t.co/Kb4a8mfZ

  • Pingback: The Node.JS Innovation Advantage | javascript.js | Scoop.it

  • January 30, 2012 - 8:58 am | Permalink
  • January 30, 2012 - 1:30 pm | Permalink

    The NodeJS Innovation Advantage http://t.co/96ekWJRY #nodejs

  • Pingback: The Node.JS Innovation Advantage | e-commerce et e-marketing for absolute beginners | Scoop.it

  • January 30, 2012 - 6:13 pm | Permalink

    http://t.co/6YH2RbpB — The NodeJS Innovation Advantage — olympum

  • January 31, 2012 - 4:01 am | Permalink

    It would be useful to consider an alternative goal, where “production ready” is replaced by “market validated”. Quite often the larger amount of time is spent in validating a product in the market and making the required changes as a part of that process, well after the production-ready stage.

    Its hard to discuss broad conclusions like the one above in absence of specific contexts. At least in my experience, it is much easier (and quicker) to get to production ready stage with python than with java. Thus also leading to a quicker market validation. If these languages such as python were not able to take us faster both to production-ready and market validated stage, I don’t know if they would be used as much.

    Much of the discussed debates and tradeoffs focus on the stages thereafter.

    And yes, Python is a dynamically typed, strongly typed language. (Not weakly typed language). I suspect the same to be true of Ruby as well.

  • February 1, 2012 - 1:37 pm | Permalink

    THE NODEJS INNOVATION ADVANTAGE: http://t.co/TvLZo1Ji

  • February 1, 2012 - 1:37 pm | Permalink

    THE NODEJS INNOVATION ADVANTAGE: http://t.co/1ZosVanp

  • February 1, 2012 - 6:38 pm | Permalink
  • February 1, 2012 - 8:08 pm | Permalink

    Innovation & impact of node.js-great blog by olympum http://t.co/UIgG0fwU

  • February 3, 2012 - 3:49 pm | Permalink

    Strong-type and weak-type, and span from development to production. // Olympum: The NodeJS Innovation Advantage http://t.co/SA1BfZNh

  • February 6, 2012 - 3:36 pm | Permalink

    The #NodeJS Innovation Advantage http://t.co/LbkxOZfM

  • February 16, 2012 - 1:22 am | Permalink

    RT @NodeJsCommunity: 「The NodeJS Innovation Advantage」 http://t.co/dfTwcay8 #reader http://t.co/ieEWZJCG

  • February 26, 2012 - 6:07 am | Permalink

    The NodeJS Innovation Advantage [vs e.g. Java: prototype quickly, ensure correctness later+deeper] @olympum http://t.co/riMyeu2m ^ar

  • pantyjack
    March 10, 2012 - 11:53 pm | Permalink

    The argument for the strongly-typed-python is rushed. The just ’cause primitives types operators are not python functions, if i send a message to an object does not raise a type error. So, is bullshit.

  • March 30, 2012 - 8:15 pm | Permalink

    When I look at this graph (which I do intuitively agree with, again from my own long & painful experiences), what I see is at your “production ready” point, the green line is shallow, and the purple line is steep.

    The question I see is, Where do versions 1.1, 1.5, and 2.0 appear on the graph?

  • Comments are closed.