Eric S. Raymond defines “Defect Attractors” as

“a feature which, while possibly not bad in itself, spawns defects in the design or code near it”

(full post here: http://esr.ibiblio.org/?p=8042. It’s worth reading the whole thing). The article discusses defect attractors in the context of low level APIs and language design, but development in ServiceNow has defect attractors too.

The first defect attractor isn’t specific to ServiceNow, but is part of the language we use to extend ServiceNow, JavaScript. JavaScript is a weakly typed language and that makes for huge defect attractors. For example let look at this script:
var g = new GlideRecord(‘incident’);
g.get(‘number’, ‘INC0000001’);
var a = 2;
gs.print(g.number + 2);

Yields this result:
*** Script: INC00000012
Just what you would expect, but 2 is defined as a number. What if the purpose of the code was to add 2 to the record’s number (as opposed to appending a “2”)?
Another JavaScript error attractor in ServiceNow is the tendency of ServiceNow to ignore the ECMAScript standard, but to give credit where it’s due, SerivceNow has done a very good job of bringing the server side scripting more in line with the ECMA standards.

Moving to defect attractors specific to ServiceNow, the first is Business Rule ordering. There is an order you can set to determine when business rules run, but most of the time it just stays at the default of 100. Most of the time this is innocuous. When it’s not, it’s really not. A developer can spend a lot of time trying to tease out the cause of the very inconsistent results that popup when there are conflicting business rules running with the same order set.

The last defect attractor is the inconsistency between the Global Scope API and the Application Scope API. ServiceNow’s own documentation notes this

“Please note: The APIs below are intended for scoped applications and may behave differently in the global scope.”

An honorable mention for defect attracting is date time manipulation.

What are your ServiceNow defect attractors?