July 19, 2016
From nczonline.net, with love.

Explicit Over Implicit

Hi everyone,

Last week I read an article about a software bug that cost Citigroup $7 million. The bug had been in existence for 15 years and was only recently discovered. The problem? Certain valid transactions were being treated as if they were test data and were therefore omitted from records requested by the United States Security and Exchange Commission (SEC). The SEC is responsible for overseeing the financial sector in the United States and regularly requests information about transactions from financial institutions. The SEC fined Citigroup $7 million for the error.

But what was the actual error? Each financial transaction has an associated branch code identifying the unit of Citigroup that handled the transaction. Initially, branch codes were always numeric, apparently in the range 0-99. Any branch code with three digits (actually, three characters) was considered to be test data and omitted from official transaction reports. For instance, the number 100 was considered an invalid branch code and was treated as test data because legitimate transactions must have a valid branch code.

Unfortunately, the way Citigroup assigned branch codes changed after the system was created. In 1998, they started introducing three-character alphanumeric branch codes, such as 10B, to better reflect the company's growing business. Unfortunately, the system saw valid codes like 10B as test data because they were made up of three characters and omitted transactions with these branch codes from the official transaction lists sent to the SEC.

There are several lessons to be learned from this situation, but the most important is the value of favoring explicit solutions rather than implicit ones. There is nothing about a three-character code that signals "this is test data," so it's no wonder that no one realized this would be a problem until years later. The programmers chose an implicit signal (a third character) over an explicit signal and created a lot of trouble along the way. Had they used an explicit signal, such as including the word "test" in the code, or even adding another field that indicated test data, they could have avoided future problems. Expecting anyone to realize that a third character, any third character, indicated test data is completely unrealistic because there is no logical relationship between the signal and the meaning.

This is a mistake I've seen repeated in several of my jobs, and one that people were making frequently on the web, confusing feature detection for browser detection. You will never run into problems when you choose an explicit signal over an implicit signal. Implicit signals require historical knowledge (why the decision was made) whereas explicit signals are self-contained and don't require any information about the code's creation. You'll do yourself and your colleagues a great service by avoiding implicit signals wherever possible.

Be well.

-N
Enjoy the newsletter? Leave a tip or become a patron.

Recommended Links

Is the Internet being ruined? (podcast, 48 mins)
While the Internet has been thought of as the ultimate open platform, you may be noticing that it's increasingly coming under the control of a small number of large companies. Google, Facebook, Apple, and others are slowly building giant presences that keep users in the company-controlled corner of the Internet. This podcast explores what is happening and why it's worrisome. Coupled with some historical perspective on how the Internet came to be, this podcast is a must-listen exploration of the Internet today.

Links vs. Buttons in Modern Web Applications (article)
There are many considerations in the age old debate of when you should use a link instead of a button. The goal is to provide the most accessible (and semantically correct) markup for the use case, but it's not always so easy. This article digs into various use cases to determine when it's best to use a link and when it's best to use a button.

Mixins Considered Harmful (article)
Mixins have been a popular pattern in JavaScript for a while, and have reached some level of popularity in React as a result. Now, however, the React team is finding that mixins can be problematic as a project scales, and is recommending that you avoid mixins. The article explores the problems they've encountered and suggested solutions. While this post is specific to React, the overall takeaways are valid regardless of the library or framework you're using.

Moment of Zen

"Having endless opportunities at our hands is great, blindly obsessing over the stack and not putting people in the forefront never is."
- Karolina Szczur, The Web Isn't Uniform

Recommended Book

I recently started learning Ruby on Rails, as it's one of the few popular web application technologies that I have no experience with. After soliciting book recommendations from Rails developers, I finally decided to buy Ruby on Rails Tutorial. This one book was recommended the most to me, and I can understand why. The book starts out by throwing you right into creating a simple Ruby on Rails application without explaining too much of the "why" -- the author wants you writing code as quickly as possible and circles back to the "why" later on. In this way, you get and running quickly, learning more about why the things you did actually worked as you get deeper into the book. Along the way, you are guided through even more complex examples that exercise the many aspects of Ruby on Rails. While the third edition focuses on Ruby on Rails 4.2, there is an online version that is for Ruby on Rails 5. The third and fourth editions can be read for free online, though I personally prefer a physical book for learning (and also for compensating the author).

Recently on NCZOnline

ES6 module loading: More complicated than you think
One of the most long-awaited features of ECMAScript 6 is the formal definition of modules as part of the language. For years, JavaScript developers have struggled with organizing their code and needing to decide between alternate ad-hoc module formats like RequireJS, AMD, and CommonJS. Formally defining modules as part of JavaScript will eliminate a lot...

Mimicking npm script in Node.js
I'm a big fan of npm scripts[1] and have been using them in all of my projects instead of a standalone build system. The feature I like the most from npm scripts is the ability to run command line executables that are installed in your project's node_modules/.bin directory. That allows you to, for example, install...

Reflections on ESLint's success
It's hard for me to believe, but I first conceived and created ESLint[1] in June 2013 and first announced it's availability in July 2013[2]. As frequent readers might recall, the primary goal of ESLint was to create a linter with rules that could be loaded at runtime. I had seen some problems in our JavaScript...

Books I've Written

Feedback

Love this newsletter? Hate it? Have suggestions for how to make it better? When you subscribe to the newsletter, you can just reply to send in feedback.

Ready to subscribe?

Join over 2,000 others and subscribe to get the newsletter delivered to your inbox every other Tuesday. 
If you enjoy this newsletter and would like to support my work (including the newsletter, my blog, my books, and ESLint), please consider becoming a patron. I provide a lot of free content and your support allows me to spend more time doing so, and there are great rewards for patrons.
Copyright © 2016 Nicholas C. Zakas, All rights reserved.


unsubscribe from this list    update subscription preferences