Copyright 2017-2018 Jason Ross, All Rights Reserved

Analysis Paralysis
Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

Sometimes, when you or your team are trying to solve a problem, you find that you’re going round in circles and getting nowhere. There is always a reason why every solution is wrong, or you’re worried that if you start working on one solution it’ll turn out to be a dead end. You get into a cycle of thinking more and more about the details, where everything could go wrong, and then you realize you’re overthinking the whole thing. You ask for more information, and if and when it arrives then it too gets analyzed and you find you’re no closer to an answer than before. The whole process just goes on and on, with no apparent end in sight, and no actual results to show for it.

This is “Analysis Paralysis”.

Medway Union Workhouse Before Its Demolition, As Featured On My History Site
Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

In the everyday rush of work and family life it’s easy for personal projects to be neglected. That’s what happened to one of my sites, which hadn’t been updated since I moved it to a new web host in 2010, and was showing its age. I decided it was time to update it, so thought I'd describe the process here.

Treasure Chest. Image courtesy of Roger Kirby, http://www.rgbstock.com/gallery/rkirbycom
Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

Modern systems are fast. Very fast. So why is it that they seem so slow? Controls take too much time to be filled with their contents, web pages take too long to display, documents take ages to retrieve, and applications feel like they have to “think” for a while before they do anything. All running across ridiculously fast networks that somehow seem to run like they’re connected with pieces of damp string. What’s gone wrong?

Image courtesy of Adrian van Leen, rgbstock.com. http://www.rgbstock.com/gallery/TACLUDA
Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

Many developers that I’ve worked with seem to have an almost unhealthy obsession with the idea of “Information Radiators”- wall-mounted screens, coloured lights and displays in the office, showing successful or failing builds and deployments as well as general information about the system.

At first this may seem a little dramatic – isn’t it humiliating to have your failures publicized? Why does anyone else but you care whether your build fails? What benefits does this sort of thing give us?

List of valid, and invalid version numbers.
Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

In Eliminating Failed Deployments – Part 2 – Automate Your Obsession, one of the checks I suggested was:

Ensure all of the binary files have an appropriate version number; “1.0.0.0” is NOT an appropriate version number.

So, WHY isn’t 1.0.0.0, or anything like that, an appropriate version?

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

Conway’s Law states:

"Any organization that designs a system...will inevitably produce a design whose structure is a copy of the organization's communication structure."

It’s often paraphrased as the structure of software developed by an organization reflects the structure of that organization. What if this sort of reflection applies in other areas?

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

A few years ago I was working in The City of London. The company I worked for had a very good development process – continuous integration, unit testing and several test environments before production (the sort of thing described in Eliminating Failed Deployments – Part 1 – Replication! Automation! Complication?). Environment-specific values were automatically inserted into configuration files and deployments were made by staff who weren’t developers.

With all that, you’d expect that deployments went perfectly, but they didn’t. We still had problems that weren’t always enough to warrant rolling back the deployment, but WERE enough to cause delays and the occasional frantic phone calls and debugging sessions.

One particular deployment faltered because the deployment didn’t update some permissions to match the other changes it had made. After you experience problems like this a few times, it’s easy to see how obsession can build up.