Editorial: FUD – Fear, uncertainty and doubt

Previously, I considered how difficult it can be to allow creative ideas to flow in an attempt to encourage each of you to be brave and find potential articles to write up. You may be unsurprised to learn I have failed to heed my own advice and have in fact found yet another excuse for not writing an editorial. More than a lack of ideas or source of inspiration can freeze people up or make them behave in odd ways. This will require some context, so bear with me.

As I am sure you are aware, debates have raged for ages [e.g. Stack Exchange ] concerning whether programming counts as a science or as an engineering discipline. It is possible to do a degree in either computer science, with an emphasis on data structures and algorithms, or in computer engineering, with an emphasis on the hardware – networks, multimedia, or circuit boards. Both may involve an element of programming, yet this is not the whole story. Some of the academic computing disciplines stray into philosophy along the road. Many early experiments (does that make it a science?) touched on the realm of Artificial Intelligence. They asked big questions like the Voight-Kampff machine, perhaps more correctly referred to as the Turing Test [ Turing ]. Having recently seen a review of The Imitation Game film about Turing where a reviewer remarked the Turing Test was like the Voight-Kampff test from the film Blade Runner, I need to be more discerning about which reviewers I listen to [thanks to this team for being better informed]. I digress. My bachelor’s degree is in Mathematics and Philosophy, and is actually a Bachelor of Arts degree. My philosophy supervisor was heavily involved in research with the computing department, reputedly getting to play against the Deep Blue chess computer [ Deep Blue ], and I did a module in Pascal programming. Does this mean computing, or programming, can be regarded as philosophy? An article in Scientific American [ Wartik ] considers this question. First, we are reminded scientific methodology requires repeatable experiments, developing theories that match observation. “ In science, a theory fails if it doesn’t predict observation. In CS theory, there is no observation. ” [ op cit ] Wartik then explores similarities with mathematics, which is yet another viewpoint held by some, but concludes much computer science cannot be formalised enough to be a branch of mathematics. He remarks that to the ancient Greeks, mathematics and philosophy were almost indistinguishable, and while they have diverged to an extent now, computer people do tend to fall into different camps of ‘philosophical view-points’. Even if you can’t decide which is right you can think about what you are doing and why.

What impact does deciding if you are doing science, engineering, mathematics, or even philosophy have on your day to day coding? Certainly it can be sensible to step back and sketch out the complexity of an algorithm, or think for a moment about the right data structure. It can be clever to devise or engineer a system using a mixture of science, mathematics, APIs and frameworks. Though this is part of what we do, it doesn’t seem to be the norm. Working with legacy code, or even looking back at code you wrote years ago can reveal the Dunning-Kruger effect in action [ Dunning Kruger ]. It seems that at times incompetent people lack awareness of their own incompetence and call into question the genuine ability in others. They would frequently be over-optimistic about their own performance in various tests, though could give more accurate assessment of their test performance after training, while not necessarily doing any better. Even armed with an approximately realistic idea of one’s own ability, fear, uncertainty and doubt – FUD – can take hold. Though the term is a tactic used in sales and marketing, or even politics [ FUD ], the elements can grip a team or a lone coder. For example, if you try to introduce an open-source solution into a project, will you immediately be asked “Who will fix it if we find bugs?” If your government claims another has weapons of mass destruction, are you more likely to support a war effort? There are countless examples of the deliberate or unintended spread of misinformation bringing about an effect. Though many of the sales-focussed FUD has been deliberate, programmers find themselves being subject to it, and even propagating it. On many occasions, I have seen situations where running programs in a complicated, fragile environment leads to various instructions about what to restart in which order. On further enquiry it often seems the first person happened to do this, and it worked. Even if it makes no sense, for example to restart a service that isn’t involved it is hard to resist the temptation to just do what you’re told. Fear. What if it then gets even more broken? Uncertainty. This makes no sense, but perhaps they know better than me. Doubt. I doubt it’s required, but I doubt my own powers of reasoning now.

This FUD can spread beyond attempting to get some software working, to how it is actually written. Without an understanding of an API or the language people do unnecessary things, including but not limited to calling Dispose inside a using block in C# or checking this isn’t null. Such can be described as Superstitious Code [ c2 ], and has various causes:

Code written by some kind of Bad Programmer, or really exhausted adventurous programmer.

• ignorance of the language, libraries, system in use
• imaginary assumptions guiding the programming task
• fear of hidden bugs or of doing something wrong

yields Superstitious Code.

Other variants include cargo cult programming, or voodoo chicken programming. Many people get caught talking to their computer either as they code, or try to make something run, using geek shibboleths [ Shibboleth ] – words either only pronounceable by those in the IT crowd or used as a stream of now meaningless symbols that people say at specific points, the etymology now lost in time. In all cases an almost religious habit is driving the behaviour rather than knowledge. It is worth noting that the very word ‘religion’ possibly stems from the idea of regulation – going through something again and again, though could also be from ligare , meaning bind or connect. For the Romans, relgio was about knowledge of the rites relating to both private and public life, and had nothing to do with faith. Programming can involve a mixture of both. That said, regulations and habit can be good. Knowing some SOLID principles, using version control, or being able to spot a code smell early on and nip it in the bud isn’t science or engineering. It may be peppered with some fear about what may happen if ignored, but not uncertainty or doubt. However, some cultish programming stances are foolish. You may be subject to strict coding standards, which were put in place with good reason, but find code reviewers are sticking to the letter, rather than the spirit of the law. Some superstitious practices are grounded in a modicum of sense. Avoid ‘airport checkins’ i.e. committing code to a shared coded based just before jetting off on a two week holiday. If it builds on the build machine, but not yours, consider rebuilding locally. I am sure you can think of other examples. People also consider environmental settings. I don’t just mean checking how long your PATH variable has become in case something important falls off the end. It is wise to use a font size large enough that you can spot the difference between a colon and a semicolon. (This only wasted half an hour, nonetheless…) Sometimes the tests do only work with a network cable plugged in. (Shame, I hear you cry.) The environmental superstitions can go too far though. I have heard talk of the need to be wearing one’s lucky underpants before going near certain code modules. As a woman, I’m never clear what to make of that, though I do claim to have a lucky hat. It’s made entirely of tin foil.

Religion and superstition can only take you so far. Sensible heuristics can guide you in the right direction, or help you stay on the path, avoiding dragons and other monsters. At times, this is not enough. If confronted with a big red button, saying ‘Do not press’ those of a less superstitious bent will find it almost impossible not to take a scientific approach or some brand of contumacy and hit the button to find out what happens. This leads us to a realm of real magic of Hacker’s Folklore [ Real magic ]. The tale tells us of a switch, connected by a single wire with two positions ‘Magic’ and ‘More magic’, defying the basic beliefs regarding electrical circuits. It was in the position ‘More magic’, and curiosity and a stubborn belief in sense drove people to switch it to just ‘Magic’, being certain it could not affect the computer. Which subsequently crashed. This story was not believed, but a repeat experiment led to the same outcome. More magic was clearly required.

Where does all this talk of FUD leave us? Perhaps we should embrace the unknown from time to time. If you are petrified by fear, consider walking into the dark with a friend, either by pair programming or finding a good code reviewer. Consider just making baby-steps and testing as you go. If you are unsettled by uncertainty, see what happens. If you can’t be sure of how long something will take to complete, give bounds not an exact answer. If you don’t know if the stock prices will go up or down, guestimate a probability of each and build a stochastic model. If you’re not sure what happens if you delete some Boolean flags, try a scratch refactoring [ Feathers ]. Change the bits you don’t like the look of and see what the compiler and tests say. Or in the absence of either, try it then roll back, just to get a better understanding of the code. Are you dithering over doubt? Just do it, and again, assuming you have version control, you can roll back. Admittedly xcopying to a prod server is a different matter, so perhaps talk to someone first. Ideally try to set up a safe environment where you can try things first. Again, if it’s the config, which you then need to change completely to run on another environment, this might not work out. Trying things first and assuming the experiment is repeatable is almost like science, after all.

All told, it is easy to be persuaded into approaching a problem in a specific way. Always bounce all the services, ‘Just In Case’. Never use exceptions because they always slow things down, allegedly. Always be ‘rigidly agile’. Or never use open source. Or always write an in-house version. We all know to “Never say ‘Never’” though. FUD may have made me dust off my rusty hat, and make further excuses for a lack of editorial, but it is worth considering what’s driving you and why you are doing things in a certain way. Being un-sure is the start of many fruitful journeys to greater learning and lots of fun. There is nothing wrong with continuing to ask “Why?” no matter how old you are, and just because someone speaks with authority doesn’t mean they know what they are talking about.

One of the painful things about our time
is that those who feel certainty are stupid,
and those with any imagination and understanding
are filled with doubt and indecision.
~ Bertrand Russell, The Triumph of Stupidity

References

[c2] http://c2.com/cgi/wiki?SuperstitiousCode

[Deep Blue] http://www.theguardian.com/uk/the-northerner/2012/may/14/alan-turing-gary-kasparov-computer

[Dunning Kruger] http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

[Feathers] Working Effectively with Legacy Code Michael Feather Prentice Hall 2004

[FUD] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt

[Real magic] http://www.catb.org/jargon/html/magic-story.html

[Shibboleth] http://en.wikipedia.org/wiki/Shibboleth

[Stack Exchange] http://programmers.stackexchange.com/questions/18886/what-discipline-does-computer-science-belong-to

[Turing] http://en.wikipedia.org/wiki/Turing_test

[Wartik] ‘I’m not a real scientist, and that’s okay.’ Guest Blog, Scientific American , Nov 2010 http://blogs.scientificamerican.com/guest-blog/2010/11/12/im-not-a-real-scientist-and-thats-okay/