Why pessimism is critical to technological success

Hello everyone,

The point I would like to make in this argument is to combat the negative light in which technical leads can appear, when being openly pessimistic. I want to dispel any concepts or perceptions that this is because the person has a negative outlook, wants to block progress, or anything similar; because ultimately that’s not (usually) the case.

Side point: Some “old hat” IT professionals can be negative and resistant to change, usually with years of experience to back it up, sometimes this can be overbearing, this article is specifically related to programming and web development, as opposed to IT infrastructure.

You may not realise it, but you’re pessimistic, too

This isn’t some “glass half full” spiel. When your technical lead is being seemingly resistant to a project or a technology, the likelihood is that they simply cannot promise results. That’s where the pessimism is, however, whether you realise it or not, in some way you share this pessimism, as I am about to demonstrate.

Form Validation (this one is for the techies)

Why do we bother to do any form validation? Because we assume, at some point, the user isn’t going to get it right. Either intentionally/maliciously or accidentally. In this scenario are you assuming your end users are either evil or incompetent?

Testing Cycles

Excluding User Acceptance Testing. Here we are testing for bugs. Does that not mean we’re assuming at least a small piece of oversight or incompetence from our developers? That’s fairly pessimistic too.


It’s not often I’ve come across someone who has deliberately disregarded security. But the nature of considering security concerns by default, means you’re assuming someone out there is going to want to do something malicious to your website/software, right? Fairly pessimistic assumption of the human race (and the bots it creates).

Why your tech lead is being pessimistic

The tech lead has more in depth responsibilities, I’m saying tech lead, but depending on your organisation this might be DevOps or Architecture or Infrastructure. These people must by the very definition of their roles, be pessimistic.

When you sign those contracts, high five the sale, those people go to work. They’re usually committed to an uptime guarantee, a maintenance SLA, and various other contractual obligations. They must be able to deliver (guaranteed) or risk breaching contracts.

A very wise man once said to me “Computers will do exactly as they’re told, no more, no less”, based on that quote (by Jon deVries, if he happens to stumble across this) – we must know precisely what instructions to give the computers/servers in order to make them behave, within a margin of usually 0.1% or 0.01% – else we fall foul of our SLAs.

The considerations, therefore, must cover every eventuality, potentially for a very long time (or the duration of the contract).

So why can’t they just be optimistic?

Well, imagine this scenario

  1. Project manager/salesperson: “Can you make a change to this page?”
  2. Developer: “Sure! Sounds easy, I’ll do it straight on live”
  3. – They hit the wrong button, delete the wrong file, delete and sync the whole directory and kill the whole website, maybe irreversibly –

Optimism = sentences like “It will be alright!”

Sentences like “It will be alright” = complacency

Complacency = downtime

In Summary

Your tech lead, architect, DevOps team, or other technical influencer are not being negative. The pessimism you may experience is an absolutely necessary part of their role, without that pessimism they simply couldn’t possibly be competent at their role.

So be nice to them, they’re likely doing their jobs, rather than being negative, resistant to change, or trying to block sales. They’re humans, dealing with humans, but accountable for the behaviour of computers; which by their nature are not very reasonable.

I'd love to hear your opinion on what I've written. Anecdotes are always welcome.

This site uses Akismet to reduce spam. Learn how your comment data is processed.