Chris MacDonald

Posted on Mar 12 • Edited on Mar 13

Why Analysis Paralysis Is A Developer's Worst Enemy (and how dad jokes are the antidote).

#productivity #development #career #discuss

If you're reading this, then perhaps you - like me - are a developer.

You may be a front-end web developer who's day revolves around bashing your ahead against your desk day-in-day-out, trying to make that burger bar not look like arse on IE6 .

Or perhaps you're a database engineer, trying each and everyway in your head to try and reduce the length of time it takes to join 18 kagillion tables in time for the end user of that data to blink.

Or maybe you're not a developer and you are currently severely regretting your choice to open this article.

But leave not weary reader! For we are all one and the same.

Do you ever get faced with a problem or decision that in the face of it seems so very overwhelming that you think of each and every way that you can solve it? And with each successive idea you have to fix it, you almost immediately knock it down with the absurd mental strength only major anxiety could muster?

"I could try X... but if Y happens and Z happens to A and Q happens to R... X won't work. But then if I do B..."

Sound familiar?

Welcome to Analysis Paralysis

According to Wikipedia (so it must be true!), the definition of analysis paralysis is:

Analysis paralysis (or paralysis by analysis) describes an individual or group process when overanalysing or overthinking a situation can cause forward motion or decision-making to become "paralyzed", meaning that no solution or course of action is decided upon.

This is something I'm sure we all can fall prey to one time or another, especially those of us that are in careers where problem solving is a daily occurrence. Take me for example, I wrote this blog originally for my own site and wrote the original version of it three years since the post before it.

Most of that delay came from analysis paralysis. I tried a good few times before I got to this very post and they mostly had a similar flavour to the generic example I used above! Every time I hit a roadblock in my content I would constantly question the value and quality of it and before I knew it - it was too late and needed to get to work. Nothing to show for the time wasted on worrying about my content and the size of the task in front of me. So how do we confront the intimidating nature of Analysis Paralysis?

My dad has a number of sayings that have stuck with me. Some helpful, some unhelpful. Let me think of a few examples:

Don't sit down with an egg in your back pocket - Not helpful
Never pat a burning dog - Not helpful - and rather upsetting
If you go to bed with an itchy arse, you'll wake up with a smelly finger - Dear god

Most were stinkers but there are a few that have stuck with me (despite some being a being a little macabre).

You Can't Eat An Elephant In One Sitting

Of course I'm not suggesting you grab the stuffing, ram it into Dumbo and serve him with a side of pigs-in-blankets. But if we take it as a metaphor, you can't tackle a massive problem until you've broken it down into small simple steps.

This principle is key in software development, particularly if you have an intimidating complex intricate system with many moving parts to build. To soften the anxiety rising in your laurels, you take each of those component parts, break them into smaller more managable chunks. That way, the mega task "build a website" becomes:

Build header
Build footer
Build hero banner
Write main content
Ship
Profit £££

This is of course an oversimplification of web development, but the beauty of this technique is you can always keep breaking it down. Eventually you'll reach the atomic elements of the problem and then its just a case of solving each small problem and enjoying the satisfaction it brings you.

I hear you saying though:

Chris, what if I have many problems to solve and each are time sensitive? How do I stop panicking long enough to get shit done?

Well, luckily my ol' da' has another pearl of wisdom in the form of a pseudo-proverb.

Deal With The Closest Crocodile To The Canoe First

As common as the bold croc' is in Scotland and I have no idea where he got this from - probably Crocodile Dundee or something - it is actually quite a good way to look at the issue of many problems. To continue the metaphor rhetoric, if there are many problems you can't tackle them all at once; talented though you are I'm sure.

You need to break the high-level problems into three categories:

Urgent and important
Important
Things that can get in the bin

Once you've done this, we only need to really deal with pressing things first and break these problems down as we've done before, before doing the same for the tasks in other categories.

So we've broken things down into more manageable chunks, we've prioritised what needs to be done now and what can be done later. Even once you've broken a huge problem down into many chunks, the list can sometimes seem even more daunting. You've gone from one seemingly sizable task into forty two small tasks that after breaking it down seems even larger than once thought.

Fail to plan, plan to fail

A dad classic. However also an important lesson. You have this list of tasks, you probably (now having thought about them) can now estimate how long it would take you. I would at most round this up to the nearest hour. With the tasks and their estimates you now have what I would call your backlog.

At this point I'd either write this list out on a notepad or my preferred solution would be to use Trello, a free kanban board tool which you can get for pretty much every device. You don't have to use Trello and can recreate it with post-its on a wall, but I prefer it all to live on the internet.

Other more powerful tools such as Notion are also useful but more complex to learn and may be something you should move onto once you've got a simpler system in place (learning that beast is a whole other ballgame).

Kanban boards were first developed by a chap at Toyota in the 1940s, which had been created to improve efficiency and productivity in their manufacturing line. Probably because the workforce were panicking over the size of the tasks before them (see point one). The basics of the system is like so:

You have a backlog: a list of all work that is to be completed at some point in the future.
You have a To-do list: things to be done in the planned section of time (in software dev we call this a sprint).
You have an In-progress list: tasks we are working on at this moment in time.
Finally you have a Done list: tasks that have been completed and we plan not to revisit them.

Kanban is very prevalent in the software industry these days, which probably why I have a preference for it. When you start your first slice of time of work (for example from this moment to a week from now), we look at the amount of time we have in that week to do work. If I only have two hours a day over that week that gives me 14 hours.

This perhaps being optimistic as it assumes we will be working every minute of those two hours per day and not in fact dicking around completing Buzzfeed quizzes and ending up in dark Youtube rabbit holes. To keep the example simple, lets assume we use all of those 14 hours.

If this is, say, a hobby project to build your own website I have two hours of free-time I can work on this per day. See below for an example backlog:

Style header (desktop) - 1 hour
Style header (mobile) - 2 hours
Style footer (desktop) - 1 hour
Style footer (mobile) - 1 hour

So we can see my backlog is a total of 5 hours. I'd then move all of these tasks (as they are all less than the 14 hours I have this week). If there were more, we'd move 14 hours worth of tasks over to "To-do" and the rest would stay in backlog until the next block of time. If it were me I would take the approach of doing the biggest and tasks that will cause the most hassle first - remember the closest crocodiles?

As we pick up tasks, we move the cards representing the tasks into the "In-progress" column and once completed we move them into the "Done" column. That's it - simple as that!

With each passing sprint, we'll see that backlog begins to disappear until everything now lives in the "Done" column and you're tasks are completed. Finito!

So there we have it, we broke our "task elephant" into smaller digestible chunks, we organised them into from most critical to most trivial and we then created a way to plan that all the work gets done in the time available. Hope these tips/tricks can help you as much as they helped me - this article wouldn't exist without them! Let me know in the comments what you thought. So I'll now leave you with the single worst dad joke I've heard:

Did you hear about the guy who’s left side was cut off? He’s all right now.

Thank you for reading! Please suggest your best tips at staving off analysis paralysis in the comments below.

Top comments (6)

stevewills • Mar 15

Absolutely resonate with this! Analysis paralysis can be a real productivity killer in development. And who knew dad jokes could be the antidote? Looking forward to reading more about this Fsginspections interesting perspective.