Quality Matters

How procrastinating on a side project turned into a rant

(ft. Bernardo de Oliveira)

“We are killing people [with our software]!” — acclaimed Software Architect Robert Martin — which we all know as Uncle Bob — usually says in some of his lectures and presentations. This may sound shocking to the ones oblivious to the amount of low-quality software products that keep the world spinning and that we use everyday. Killing people with code has to do with poorly designed solutions that can, ultimately, cease human lives. And despite the fact that a website like Brazil’s greatest lottery’s might not result in such a fatal outcome, the small piece of code that powers its frontend is enough to scare some poor, unaware developers to death…

This article’s inception comes from a side project by these authors that involves scraping publicly available information from MegaSena’s website, a government-controlled lottery with the biggest prizes in the country. A simple idea, easy to develop with light-weight tools, at least in theory. At the first attempt of crawling, a surprise: there was a redirect-loop preventing data to be retrieved. This behavior seemed odd, so opening the page on a browser and inspecting it with the DevTools seemed like a good way to start investigating. The problems we found were quite easy to find, but somewhat painful to describe. Here are some screenshots that demonstrate the problem(s):

Warning-bloated console, together with console logs from runtime with data, code execution information and random numbers without context

jQuery 1.9.1, an old version with known vulnerabilities that, albeit medium in severity, could be easily remediated

TODOs describing future properties that could come from some API, perhaps

At this point, you, young reader, should really be asking yourself why should a landing page of a service which has millions of users pollute the browser console with gibberish logs and leave TODOs commented out alongside API calls. Bear in mind, again, that this is the biggest lottery in Brazil, controlled by an institution with enough resources to have the best code base possible.

As developers, we know there are barriers that prevent us from delivering the first versions of our code to the clients. The most important of these, the one that should never be broken through, is common sense. Buckle up and prepare for impact; your eyes are about to be hit with the worst implementation of a shuffle I had the displeasure to see:

Shuffle that is not really a shuffle, and would result in disaster if someone tried to scale the code to cover other array sizes without refactoring the function completely

All this makes us sad and a little hopeless. When Uncle Bob tells us about killing people with software, it’s about our responsibilities as professionals that he is talking about. When there are serious consequences due to software we make, will we just say “oopsie, it seems there’s a bug”? How to explain to non-tech people how we do things, and why we do it the way we do?

How many consecutive process failures need to happen in order for code like this to go into production? Which parties can or will be held accountable for the decision chain that brought us here? But more importantly: if this is the quality of the code we can read and tinker with, what sort of monstrosity lurks in the muggy swamps of the backend? And how long will it take before this organization runs into a catastrophic failure because of code that should never have been released?

Whatever the answers are, at least Spotify doesn’t shuffle your playlists like that… Or does it? Anyway, follow these humble developers in case the side-project ever sees the light of day.

Bernardo de Oliveira
(Github) /bernieOllie
(Twitter) @bernieOllie

Jonas Castanheira
(Github) /jonasrc
(Twitter) @JonasCastanhei1