Familiarity biases and delay in adoption of coding techniques

Javier Arroyo · ‎01-16-2020

This article is mostly thoughts on the state of code in ServiceNow. It comes as response to working in the platform since aspen, and despite having witnessed uncountable lines of code from all corners of the ServiceNow space, having watched too many videos and read too many articles about coding best practices... we need to move away from the status quo. This platform is far too capable for its code to remain 10 years in the past.

I use the term familiarity bias to mean: when existing knowledge prevents the adoption of practices that are consider more opt than those a person practices. In terms of ServiceNow, this is visible in the coding techniques that are promoted within its ecosystem.

The JavaScript engine used by the platform was updated to ECMAScript Rhino V 1.7 R5 back in 2016 with the Helsinki Release. The documentation states some of the benefits as being:

You can use modern library code, such as lodash.js and moment.js.
Your script will follow standard ECMAScript5 behavior.

Of higher importance is the last bullet point. It states that scripts will follow ECMAScript5 behavior. This means that code written in JS5 style will behave as dictated by the standard. Functionality introduced in JS5 made huge strides moving the language forward, it propelled it into becoming the most important programming language period. But, if that is the case, why is it often mocked, vilified by classically trained programmers? Is it because they are expecting the language to behave to their familiarity? It can only make sense if it's like other languages?

Anywho, I'm most interested in why ServiceNow developers continue to program in ES3 style to the extent of rejecting patterns native to ECMAScript5 behavior? Why is it preferred to use outdated patterns and styles over known and proven JS5 functionality? This is where I shift focus to Gatekeepers. Gatekeepers are persons of influence who dominate dissemination of information within their areas of expertise.

These players tend to prevent adoption of emerging techniques, more times than not because experience has taught them cause and effect. They use that knowledge to deter contemporaries from adhering to newer practices. This behavior was witnessed when programming paradigms changed from Procedural to Imperative (OO). Procedural influencers valiantly fought imperative styles, until, sadly, they retired from programming; which is also the conflict being experienced as imperative programmers fight against support of declarative programming; the shift that is underway in programming languages.

ES5/JS5 with new functionality such as modules, closures, scoping, etc bid goodbye to the very practices still used in the ServiceNow space; and are adamantly promoted by our Gatekeepers. In ServiceNow familiarity bias goes even further. The claim is that ES5 standards cannot be used because the platform might change, so developers should use best practices and still program in ES3 style. This sounds counter to the statement by the platform that your script will follow standard ECMAScript5 behavior.

The stronghold of familiarity bias is so entrenched that it is used by highly skilled developers to promote mediocrity as a valid pragmatic approach to coding. It is often heard that is best to code in ways junior developers understand, that others simply won't understand our code. This sounds like ServiceNow programmers don't care about their craft and it is justifiable not to learn our craft because the platform might change.

Unmentioned is that JavaScript assures (with 100 percent assurance) that code written in version 1 will be supported in all future versions. This means that for ServiceNow JS5 written code to stop working, ServiceNow will have to stop adoption of JavaScript itself. Or create/bastardize the Rhino engine in such a form that its developers would have to learn a hybrid of JavaScript to work in the platform.

Recently, I was in a meeting with a 12 year SNow Senior Level Programmer who has been doing code reviews for nearly as long. As the conversation progressed and code samples were shared, it became obvious that while his knowledge of JavaScript inner workings were somewhat okay, his programming techniques were outdated by some 9 years. My code samples were cheating, not true JS, a tricky way of means to an end. That the language simply didn't support what I was doing. That I shouldn't resort to tricks and stay with OOTB syntax.

var something = function something () {

  function privateMethod () {}

  return {
       publicMethod: function publicMethod(){}
  }
}

should really be in real javascript. Otherwise I was cheating

var something = function something () {

  return {
       publicMethod: function publicMethod(){}
       _privateMethod: function _privateMethod() {}
  }
}

The argument was that the JavaScript community, all of it, uses underscore to inform of privacy. That my cheated privacy ran the risk of not being supported in future upgrades, that it was simply not used outside programmers that don't care about maintenance programmers who have to maintain the code.

The practice of using an underscore to *annotate* privacy in JS stopped with the release of JS5 in 2009, over 10 years ago. There were some stragglers in the JS community that used it to nearly ES6; those, however, are the same group for which JS is blamed as not having developers who care about their craft. It's a knock that the language has had for the ease in which anyone can pick it up and write something.

Why then, is it advised in our platform, that an underscore is the accepted technique in the JS community? Gatekeepers in my opinion. Why is prototype: { some methods} the upgrade-proof for script includes? Why will curried functions lose support? Why will a wrapper on the GlideRecord break yet, monkey patching won't?

Is it, then, of any use that there is plethora of patterns in JS5 that can be used in the backend? Just as there is an entire programming paradigm if developers fight new knowledge off with years of familiarity bias? why is there then, a call for an upgrade to ES6+? Is it to limit code to the use promises? fat arrows? spread operators? Will all else then be un-upgradable? Will pragmatism be a key ally to ignore the capabilities of ES6 as we have ES5?

As ServiceNow coders there should be a concentrated effort to learn coding, to move into the past-future of JS ES5 and adopt its functionality. This requires abandoning defunct ES3 practices in favor of ES5.

Do use modules or functions in script includes; use curried and high order functions; take advantage of partial application, of closures, of building objects through factories to drastically decrease downstream changes, use declarative programming techniques for function composition, tryCatch, null checks, and reader friendlier code, wrap boilerplate code as you wish. It will all work and continue to work.

As a collective, there should be an effort to be the best we can be. As programmers we should be taken as seriously as those JS programmers outside the platform. Stop looking at dated OOTB scripts, listening to Gatekeepers disseminate ES3 or classical programming advice, learn JS5 well enough to make a difference.

Kalaiarasan Pus · ‎01-17-2020

I like many others learnt Javascript once I started working on the platform. So I personally have gaps in my knowledge as highlighted but always open to learning stuff 🙂

I started replacing my IF statements to objects after reading your other post - https://community.servicenow.com/community?id=community_article&sys_id=581aa6d7dba393002be0a851ca961....